From pcn-bounces@ietf.org Wed Oct 1 22:31:39 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83F43A6A1A; Wed, 1 Oct 2008 22:31:39 -0700 (PDT) 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 A390B3A6A1A for ; Wed, 1 Oct 2008 22:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oq1pGmp8kHx for ; Wed, 1 Oct 2008 22:31:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9B5C03A6803 for ; Wed, 1 Oct 2008 22:31:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 658B3212B3; Thu, 2 Oct 2008 07:31:49 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-96-48e45cc56ca2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4FF54206BC; Thu, 2 Oct 2008 07:31:49 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 07:31:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 07:31:45 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0508627E5C@esealmw109.eemea.ericsson.se> In-Reply-To: <20080930160001.4776A28C0F0@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt Thread-Index: AckjFfhuRPHaWPOHTWeUoJxAvcV1xABNwY9A References: <20080930160001.4776A28C0F0@core3.amsl.com> From: "Ingemar Johansson S" To: , X-OriginalArrivalTime: 02 Oct 2008 05:31:47.0978 (UTC) FILETIME=[2A245EA0:01C92450] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] I-D Action:draft-ietf-pcn-baseline-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Some comments on the draft: Typos: Section 3: thatn -> than Appendix C: shoudl -> should (2 occurences) Other: Section 4.1: "increasingly short supply", could be a lack of understanding of the english language from my side. Even though I (believe I) understand the phrase I suspect that it may be confusing. Anyway please dismiss this protest if you like. Appendix C: Bullets 3 and 4: I am not quite sure that I get the difference between 3 and 4 when I read the text alone: I guess that in 3) the decision (admission control and termination) is done (in PCN-ingress/egress-nodes) based on the ratio between NM and PM while in 4) a dedicated PCN codepoint (AM or TM) is set in the PCN-interior-nodes based on load, quueue length et.c. Is this interpretation correct ? Regards Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: den 30 september 2008 18:00 > To: i-d-announce@ietf.org > Cc: pcn@ietf.org > Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.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 : Baseline Encoding and Transport of > Pre-Congestion Information > Author(s) : T. Moncaster, et al. > Filename : draft-ietf-pcn-baseline-encoding-00.txt > Pages : 12 > Date : 2008-09-30 > > Pre-congestion notification (PCN) provides information to > support admission control and flow termination in order to > protect the Quality of Service of inelastic flows. It does > this by marking packets when traffic load on a link is > approaching or has exceeded a threshold below the physical > link rate. This document specifies how such marks are to be > encoded into the IP header. The baseline encoding described > here provides for only two PCN encoding states. > It is designed to be easily extensible to provide more > encoding states but such schemes will be described in other documents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-en > coding-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 03:59:53 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FFE3A6C9E; Thu, 2 Oct 2008 03:59:53 -0700 (PDT) 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 DF7BB28C122 for ; Thu, 2 Oct 2008 03:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, J_CHICKENPOX_21=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 W5YDX1tTiVo4 for ; Thu, 2 Oct 2008 03:59:52 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id CA15D3A6C7E for ; Thu, 2 Oct 2008 03:59:51 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 12:00:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 12:00:07 +0100 Message-ID: In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0508627E5C@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt Thread-Index: AckjFfhuRPHaWPOHTWeUoJxAvcV1xABNwY9AAAwn7NA= References: <20080930160001.4776A28C0F0@core3.amsl.com> <026F8EEDAD2C4342A993203088C1FC0508627E5C@esealmw109.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 02 Oct 2008 11:00:09.0971 (UTC) FILETIME=[0971EC30:01C9247E] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-baseline-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, Thanks for the comments. I will incorporate them in the next version which will hopefully be published shortly. Regarding Appendix C bullets 3 & 4. These are trying to do two things - specify the action needed if you want to mark a packet (set it to PM) and clarify what happens if an unexpected codepoint is seen (treat it as NM). This second bit is perhaps not needed as it is reasonable to expect operators to ensure they don't misconfigured networks... Toby -----Original Message----- From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] Sent: 02 October 2008 06:32 To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org Subject: RE: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt Hi Some comments on the draft: Typos: Section 3: thatn -> than Appendix C: shoudl -> should (2 occurences) Other: Section 4.1: "increasingly short supply", could be a lack of understanding of the english language from my side. Even though I (believe I) understand the phrase I suspect that it may be confusing. Anyway please dismiss this protest if you like. Appendix C: Bullets 3 and 4: I am not quite sure that I get the difference between 3 and 4 when I read the text alone: I guess that in 3) the decision (admission control and termination) is done (in PCN-ingress/egress-nodes) based on the ratio between NM and PM while in 4) a dedicated PCN codepoint (AM or TM) is set in the PCN-interior-nodes based on load, quueue length et.c. Is this interpretation correct ? Regards Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: den 30 september 2008 18:00 > To: i-d-announce@ietf.org > Cc: pcn@ietf.org > Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.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 : Baseline Encoding and Transport of > Pre-Congestion Information > Author(s) : T. Moncaster, et al. > Filename : draft-ietf-pcn-baseline-encoding-00.txt > Pages : 12 > Date : 2008-09-30 > > Pre-congestion notification (PCN) provides information to > support admission control and flow termination in order to > protect the Quality of Service of inelastic flows. It does > this by marking packets when traffic load on a link is > approaching or has exceeded a threshold below the physical > link rate. This document specifies how such marks are to be > encoded into the IP header. The baseline encoding described > here provides for only two PCN encoding states. > It is designed to be easily extensible to provide more > encoding states but such schemes will be described in other documents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-en > coding-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 05:17:16 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504F33A6B51; Thu, 2 Oct 2008 05:17:16 -0700 (PDT) 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 8F3A03A6933 for ; Thu, 2 Oct 2008 05:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0yZTSGN52Gw for ; Thu, 2 Oct 2008 05:17:14 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 546C33A6B51 for ; Thu, 2 Oct 2008 05:17:13 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D1142198D96; Thu, 2 Oct 2008 14:16:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C4576198D79; Thu, 2 Oct 2008 14:16:50 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A9154198D77; Thu, 2 Oct 2008 14:16:50 +0200 (CEST) Message-ID: <48E4BB53.9020809@informatik.uni-wuerzburg.de> Date: Thu, 02 Oct 2008 14:15:15 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA304@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA304@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, I still have concerns regarding the nomenclature in the current version of the architecture draft. Take Figure 1 on page 10. The terms PCN-threshold-rate and PCN-excess-rate are meaningful only in the CL deployment scenario where the reference rate for the threshold marker is the PCN-threshold-rate and the reference rate for the excess marker is the PCN-excess-rate. This is different for the SM deployment scenario where the reference rate of the excess marker must be set to the PCN-threshold-rate. How funny is that? No, it's not funny - this is confusing and makes further explanations cumbersome and prone to misunderstandings. I think that this is a bug that should be corrected before publication as these terms help to describe the core idea of PCN. Using the term admissible rate instead of PCN-threshold-rate and supportable rate instead of PCN-excess-rate decouples PCN rate thresholds from marking mechanisms. They express the meanings of these thresholds within the PCN concept which are denoted on the right side in Figure 1 and allow a much clearer presentation of the concept. I hope my reasoning is clear. This document is not a working document for a closed group where nomenclature has no importance as long as everybody knows that we mean pears if we say apples - it's a reference for others to learn about PCN and, therefore, technical terms should be precise and easy to remember. Regards, Michael philip.eardley@bt.com wrote: > { > { There are some known edits that have to be made before we can submit > to > { the > { IESG: > { > { - Correct references to Internet Drafts to indicate "Work in Progress" > { - Fix formatting errors detected by ID-nits > > I just fixed these (I think) in > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt > The only changes from 06 to -07 are to re-format some of the references > in order to fix the above 2 points. > > Phil > > Ps to see the -05 to -06 diffs: > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- > architecture-06-from-05.diff.html > or from http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 05:20:25 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB463A6C6F; Thu, 2 Oct 2008 05:20:25 -0700 (PDT) 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 955133A6B51 for ; Thu, 2 Oct 2008 05:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Xb18DXW4vN for ; Thu, 2 Oct 2008 05:20:24 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 62F7F3A6970 for ; Thu, 2 Oct 2008 05:20:24 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5F457198E71; Thu, 2 Oct 2008 14:20:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 50A62198DE3; Thu, 2 Oct 2008 14:20:14 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 31BCD198E70; Thu, 2 Oct 2008 14:20:14 +0200 (CEST) Message-ID: <48E4BC1E.1020205@informatik.uni-wuerzburg.de> Date: Thu, 02 Oct 2008 14:18:38 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA304@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA304@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, the following reference has changed. Old: [Menth] "PCN-Based Resilient Network Admission Control: The Impact of a Single Bit"", Technical Report , 2007, . New: [Menth] "Threshold Configuration and Routing Optimization for PCN-Based Resilient Admission Control", Technical Report , 2007, . Regards, Michael philip.eardley@bt.com wrote: > { > { There are some known edits that have to be made before we can submit > to > { the > { IESG: > { > { - Correct references to Internet Drafts to indicate "Work in Progress" > { - Fix formatting errors detected by ID-nits > > I just fixed these (I think) in > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt > The only changes from 06 to -07 are to re-format some of the references > in order to fix the above 2 points. > > Phil > > Ps to see the -05 to -06 diffs: > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- > architecture-06-from-05.diff.html > or from http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 05:45:08 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498FD3A6CC1; Thu, 2 Oct 2008 05:45:08 -0700 (PDT) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3E9BA28C1A5; Thu, 2 Oct 2008 05: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: <20081002124503.3E9BA28C1A5@core3.amsl.com> Date: Thu, 2 Oct 2008 05:45:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --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 : Marking behaviour of PCN-nodes Author(s) : P. Eardley Filename : draft-ietf-pcn-marking-behaviour-00.txt Pages : 22 Date : 2008-10-02 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 first configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of a second configured rate.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-marking-behaviour-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-02053525.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --NextPart-- From pcn-bounces@ietf.org Thu Oct 2 05:56:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A3028C10A; Thu, 2 Oct 2008 05:56:00 -0700 (PDT) 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 1BB8F3A6847 for ; Thu, 2 Oct 2008 05:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPXoezqM6h2O for ; Thu, 2 Oct 2008 05:55:58 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id D9EAE3A6AC5 for ; Thu, 2 Oct 2008 05:55:57 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id F0576198E6E; Thu, 2 Oct 2008 14:55:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E4ED1198E67; Thu, 2 Oct 2008 14:55:55 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CA193198E51; Thu, 2 Oct 2008 14:55:55 +0200 (CEST) Message-ID: <48E4C47B.40901@informatik.uni-wuerzburg.de> Date: Thu, 02 Oct 2008 14:54:19 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <4A916DBC72536E419A0BD955EDECEDEC03DAA304@E03MVB1-UKBR.domain1.systemhost.net> <48E4BC1E.1020205@informatik.uni-wuerzburg.de> In-Reply-To: <48E4BC1E.1020205@informatik.uni-wuerzburg.de> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Sorry, the correct link is http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf Regards, Michael Michael Menth wrote: > Hi Phil, > > the following reference has changed. > > Old: > > [Menth] "PCN-Based Resilient Network Admission Control: The Impact > of a Single Bit"", Technical Report , 2007, www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ > Menth07-PCN-Config.pdf>. > > New: > > [Menth] "Threshold Configuration and Routing Optimization for > PCN-Based Resilient Admission Control", Technical Report > , 2007, > Menth08-PCN-Config.pdf>. > > Regards, > > Michael > > philip.eardley@bt.com wrote: >> { { There are some known edits that have to be made before we can submit >> to >> { the >> { IESG: >> { { - Correct references to Internet Drafts to indicate "Work in >> Progress" >> { - Fix formatting errors detected by ID-nits >> >> I just fixed these (I think) in >> http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt >> The only changes from 06 to -07 are to re-format some of the references >> in order to fix the above 2 points. >> Phil >> >> Ps to see the -05 to -06 diffs: >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- >> architecture-06-from-05.diff.html or from >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 06:16:46 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723A328C1BB; Thu, 2 Oct 2008 06:16:46 -0700 (PDT) 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 5EC303A6CD3 for ; Thu, 2 Oct 2008 06:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.454, 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 WUgbWKZGdJPT for ; Thu, 2 Oct 2008 06:16:44 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 7B89A3A6CCD for ; Thu, 2 Oct 2008 06:16:43 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 14:16:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 14:16:45 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA31F@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48E4BB53.9020809@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckkiMIwwmqchQvLT8OmrBbNmV+0mAACAmSQ From: To: X-OriginalArrivalTime: 02 Oct 2008 13:16:46.0650 (UTC) FILETIME=[1F0BE1A0:01C92491] Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 02 October 2008 13:15 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil, { { I still have concerns regarding the nomenclature in the current version { of the architecture draft. { { Take Figure 1 on page 10. The terms PCN-threshold-rate and { PCN-excess-rate are meaningful only in the CL deployment scenario where { the reference rate for the threshold marker is the PCN-threshold-rate { and the reference rate for the excess marker is the PCN-excess-rate. { This is different for the SM deployment scenario where the reference { rate of the excess marker must be set to the PCN-threshold-rate. This is not correct. The rate of the excess marker is set to the PCN-excess-rate. Fig 2 shows, for the Single Marking deployment scenario, how this relates to admission /termination Best wishes Phil How { funny is that? No, it's not funny - this is confusing and makes further { explanations cumbersome and prone to misunderstandings. I think that { this is a bug that should be corrected before publication as these terms { help to describe the core idea of PCN. Using the term admissible rate { instead of PCN-threshold-rate and supportable rate instead of { PCN-excess-rate decouples PCN rate thresholds from marking mechanisms. { They express the meanings of these thresholds within the PCN concept { which are denoted on the right side in Figure 1 and allow a much clearer { presentation of the concept. { { I hope my reasoning is clear. This document is not a working document { for a closed group where nomenclature has no importance as long as { everybody knows that we mean pears if we say apples - it's a reference { for others to learn about PCN and, therefore, technical terms should be { precise and easy to remember. { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > { { > { There are some known edits that have to be made before we can submit { > to { > { the { > { IESG: { > { { > { - Correct references to Internet Drafts to indicate "Work in Progress" { > { - Fix formatting errors detected by ID-nits { > { > I just fixed these (I think) in { > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt { > The only changes from 06 to -07 are to re-format some of the references { > in order to fix the above 2 points. { > { > Phil { > { > Ps to see the -05 to -06 diffs: { > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- { > architecture-06-from-05.diff.html { > or from http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 06:20:49 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4BE3A6960; Thu, 2 Oct 2008 06:20:49 -0700 (PDT) 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 583E73A6960 for ; Thu, 2 Oct 2008 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AWL=0.302, 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 4gncg8l8DaWX for ; Thu, 2 Oct 2008 06:20:46 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 09FA23A6887 for ; Thu, 2 Oct 2008 06:20:45 -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); Thu, 2 Oct 2008 14:19:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 14:19:00 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA320@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48E4C47B.40901@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: Ackkjj2Sv4ckgd4ST/qE+o3Lxe4QOQAAwU9Q From: To: X-OriginalArrivalTime: 02 Oct 2008 13:19:01.0514 (UTC) FILETIME=[6F6E7EA0:01C92491] Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org At the moment there are references to both [Menth] and [Menth08]. So the [Menth] ones can all be replaced by [Menth08]? - just checking! Thanks phil { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 02 October 2008 13:54 { To: menth@informatik.uni-wuerzburg.de { Cc: Eardley,PL,Philip,CXR9 R; pcn { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Sorry, the correct link is { { http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf { { Regards, { { Michael { { Michael Menth wrote: { > Hi Phil, { > { > the following reference has changed. { > { > Old: { > { > [Menth] "PCN-Based Resilient Network Admission Control: The Impact { > of a Single Bit"", Technical Report , 2007, www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ { > Menth07-PCN-Config.pdf>. { > { > New: { > { > [Menth] "Threshold Configuration and Routing Optimization for { > PCN-Based Resilient Admission Control", Technical Report { > , 2007, { > Menth08-PCN-Config.pdf>. { > { > Regards, { > { > Michael { > { > philip.eardley@bt.com wrote: { >> { { There are some known edits that have to be made before we can { submit { >> to { >> { the { >> { IESG: { >> { { - Correct references to Internet Drafts to indicate "Work in { >> Progress" { >> { - Fix formatting errors detected by ID-nits { >> { >> I just fixed these (I think) in { >> http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt { >> The only changes from 06 to -07 are to re-format some of the references { >> in order to fix the above 2 points. { >> Phil { >> { >> Ps to see the -05 to -06 diffs: { >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf- { pcn- { >> architecture-06-from-05.diff.html or from { >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ { >> _______________________________________________ { >> PCN mailing list { >> PCN@ietf.org { >> https://www.ietf.org/mailman/listinfo/pcn { >> { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 06:28:43 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF6C3A6CCB; Thu, 2 Oct 2008 06:28:43 -0700 (PDT) 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 333B73A697D for ; Thu, 2 Oct 2008 06:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbW+8-erwKZG for ; Thu, 2 Oct 2008 06:28:41 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id C3DC03A6912 for ; Thu, 2 Oct 2008 06:28:40 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 05FDD198E5B; Thu, 2 Oct 2008 15:28:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E9BF5198DA1; Thu, 2 Oct 2008 15:28:05 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CAEF6A06CA; Thu, 2 Oct 2008 15:28:05 +0200 (CEST) Message-ID: <48E4CC05.7080509@informatik.uni-wuerzburg.de> Date: Thu, 02 Oct 2008 15:26:29 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA31F@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA31F@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, sorry, I was confused. You are right. I overlooked that this intrinsic contradiction is resolved by redefining the term "PCN-threshold-rate" in Figure 1 into "PCN-excess-rate" in Figure 2. Thus, the semantic of the term "PCN-threshold-rate" depends on the deployment scenario, right? Again, this is very confusing an I recommend to introduce the two terms "admissible rate" and "supportable rate" in addition. They are independent of the deployment scenario and allow the explanation of PCN without having a particular deployment scenario in mind. Regards, Michael philip.eardley@bt.com wrote: > { -----Original Message----- > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { Sent: 02 October 2008 13:15 > { To: Eardley,PL,Philip,CXR9 R > { Cc: pcn@ietf.org > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture > { > { Hi Phil, > { > { I still have concerns regarding the nomenclature in the current > version > { of the architecture draft. > { > { Take Figure 1 on page 10. The terms PCN-threshold-rate and > { PCN-excess-rate are meaningful only in the CL deployment scenario > where > { the reference rate for the threshold marker is the PCN-threshold-rate > { and the reference rate for the excess marker is the PCN-excess-rate. > { This is different for the SM deployment scenario where the reference > { rate of the excess marker must be set to the PCN-threshold-rate. > > This is not correct. The rate of the excess marker is set to the > PCN-excess-rate. Fig 2 shows, for the Single Marking deployment > scenario, how this relates to admission /termination > > Best wishes > Phil > > > > How > { funny is that? No, it's not funny - this is confusing and makes > further > { explanations cumbersome and prone to misunderstandings. I think that > { this is a bug that should be corrected before publication as these > terms > { help to describe the core idea of PCN. Using the term admissible rate > { instead of PCN-threshold-rate and supportable rate instead of > { PCN-excess-rate decouples PCN rate thresholds from marking mechanisms. > { They express the meanings of these thresholds within the PCN concept > { which are denoted on the right side in Figure 1 and allow a much > clearer > { presentation of the concept. > { > { I hope my reasoning is clear. This document is not a working document > { for a closed group where nomenclature has no importance as long as > { everybody knows that we mean pears if we say apples - it's a reference > { for others to learn about PCN and, therefore, technical terms should > be > { precise and easy to remember. > { > { Regards, > { > { Michael > { > { philip.eardley@bt.com wrote: > { > { > { > { There are some known edits that have to be made before we can > submit > { > to > { > { the > { > { IESG: > { > { > { > { - Correct references to Internet Drafts to indicate "Work in > Progress" > { > { - Fix formatting errors detected by ID-nits > { > > { > I just fixed these (I think) in > { > > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt > { > The only changes from 06 to -07 are to re-format some of the > references > { > in order to fix the above 2 points. > { > > { > Phil > { > > { > Ps to see the -05 to -06 diffs: > { > > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- > { > architecture-06-from-05.diff.html > { > or from http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ > { > _______________________________________________ > { > PCN mailing list > { > PCN@ietf.org > { > https://www.ietf.org/mailman/listinfo/pcn > { > > { > { -- > { Dr. Michael Menth, Assistant Professor > { University of Wuerzburg, Institute of Computer Science > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { mailto:menth@informatik.uni-wuerzburg.de > { http://www3.informatik.uni-wuerzburg.de/research/ngn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 06:47:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D45A3A677D; Thu, 2 Oct 2008 06:47:02 -0700 (PDT) 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 078533A659B for ; Thu, 2 Oct 2008 06:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBYFCwXWQbW9 for ; Thu, 2 Oct 2008 06:47:00 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id B179E3A677D for ; Thu, 2 Oct 2008 06:46:59 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 6E3D6198E69; Thu, 2 Oct 2008 15:46:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 62290198E68; Thu, 2 Oct 2008 15:46:40 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3170D198E5E; Thu, 2 Oct 2008 15:46:40 +0200 (CEST) Message-ID: <48E4D060.3000103@informatik.uni-wuerzburg.de> Date: Thu, 02 Oct 2008 15:45:04 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA320@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA320@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, good that you ask. Your citation [Menth08] relates to our joint overview paper with the collection of AC and FT mechanisms and [Menth] relates to the paper about threshold configuration. To avoid confusion, it might be better to use [PCN-Overview] instead of [Menth08] and [PCN-Config] instead of [Menth]. [Menth08] or [PCN-Overview] M. Menth et al.: "PCN-Based Admission Control and Flow Termination", 2008, http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Overview.pdf [Menth] or [PCN-Config] M. Menth and M. Hartmann: "Threshold Configuration and Routing Optimization for PCN-Based Resilient Admission Control", 2008, http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf Regards, Michael philip.eardley@bt.com wrote: > At the moment there are references to both [Menth] and [Menth08]. > So the [Menth] ones can all be replaced by [Menth08]? > - just checking! > Thanks > phil > > { -----Original Message----- > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { Sent: 02 October 2008 13:54 > { To: menth@informatik.uni-wuerzburg.de > { Cc: Eardley,PL,Philip,CXR9 R; pcn > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture > { > { Sorry, the correct link is > { > { http://www3.informatik.uni- > { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf > { > { Regards, > { > { Michael > { > { Michael Menth wrote: > { > Hi Phil, > { > > { > the following reference has changed. > { > > { > Old: > { > > { > [Menth] "PCN-Based Resilient Network Admission Control: The > Impact > { > of a Single Bit"", Technical Report , 2007, { > > www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ > { > Menth07-PCN-Config.pdf>. > { > > { > New: > { > > { > [Menth] "Threshold Configuration and Routing Optimization for > { > PCN-Based Resilient Admission Control", Technical > Report > { > , 2007, > { > { > Menth08-PCN-Config.pdf>. > { > > { > Regards, > { > > { > Michael > { > > { > philip.eardley@bt.com wrote: > { >> { { There are some known edits that have to be made before we can > { submit > { >> to > { >> { the > { >> { IESG: > { >> { { - Correct references to Internet Drafts to indicate "Work in > { >> Progress" > { >> { - Fix formatting errors detected by ID-nits > { >> > { >> I just fixed these (I think) in > { >> > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt > { >> The only changes from 06 to -07 are to re-format some of the > references > { >> in order to fix the above 2 points. > { >> Phil > { >> > { >> Ps to see the -05 to -06 diffs: > { >> > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf- > { pcn- > { >> architecture-06-from-05.diff.html or from > { >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ > { >> _______________________________________________ > { >> PCN mailing list > { >> PCN@ietf.org > { >> https://www.ietf.org/mailman/listinfo/pcn > { >> > { > > { > { -- > { Dr. Michael Menth, Assistant Professor > { University of Wuerzburg, Institute of Computer Science > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { mailto:menth@informatik.uni-wuerzburg.de > { http://www3.informatik.uni-wuerzburg.de/research/ngn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 06:53:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F42003A6C54; Thu, 2 Oct 2008 06:53:51 -0700 (PDT) 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 632E73A6C54 for ; Thu, 2 Oct 2008 06:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.410, 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 GTiRZf5dbvqH for ; Thu, 2 Oct 2008 06:53:49 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 3004E3A6784 for ; Thu, 2 Oct 2008 06:53:49 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 14:53:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 14:53:27 +0100 Message-ID: In-Reply-To: <48E4D060.3000103@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckklXIHhli2cBuJTliH+vuuyrEdIQAAIJtw References: <4A916DBC72536E419A0BD955EDECEDEC03DAA320@E03MVB1-UKBR.domain1.systemhost.net> <48E4D060.3000103@informatik.uni-wuerzburg.de> From: To: X-OriginalArrivalTime: 02 Oct 2008 13:53:22.0994 (UTC) FILETIME=[3C2B6120:01C92496] Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, While we are on the subject of references in the architecture document you need to update them to reflect the two new WG IDs (marking and baseline encoding). Also do you mean to have the circular reference to your own architecture doc under its old draft-eardley name? Toby -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: 02 October 2008 14:45 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture Hi Phil, good that you ask. Your citation [Menth08] relates to our joint overview paper with the collection of AC and FT mechanisms and [Menth] relates to the paper about threshold configuration. To avoid confusion, it might be better to use [PCN-Overview] instead of [Menth08] and [PCN-Config] instead of [Menth]. [Menth08] or [PCN-Overview] M. Menth et al.: "PCN-Based Admission Control and Flow Termination", 2008, http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth08-PCN-Overview.pdf [Menth] or [PCN-Config] M. Menth and M. Hartmann: "Threshold Configuration and Routing Optimization for PCN-Based Resilient Admission Control", 2008, http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth08-PCN-Config.pdf Regards, Michael philip.eardley@bt.com wrote: > At the moment there are references to both [Menth] and [Menth08]. > So the [Menth] ones can all be replaced by [Menth08]? > - just checking! > Thanks > phil > > { -----Original Message----- > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { Sent: 02 October 2008 13:54 > { To: menth@informatik.uni-wuerzburg.de > { Cc: Eardley,PL,Philip,CXR9 R; pcn > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture > { > { Sorry, the correct link is > { > { http://www3.informatik.uni- > { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf > { > { Regards, > { > { Michael > { > { Michael Menth wrote: > { > Hi Phil, > { > > { > the following reference has changed. > { > > { > Old: > { > > { > [Menth] "PCN-Based Resilient Network Admission Control: The > Impact > { > of a Single Bit"", Technical Report , 2007, { > > www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ > { > Menth07-PCN-Config.pdf>. > { > > { > New: > { > > { > [Menth] "Threshold Configuration and Routing Optimization for > { > PCN-Based Resilient Admission Control", Technical > Report > { > , 2007, > { > { > Menth08-PCN-Config.pdf>. > { > > { > Regards, > { > > { > Michael > { > > { > philip.eardley@bt.com wrote: > { >> { { There are some known edits that have to be made before we can > { submit > { >> to > { >> { the > { >> { IESG: > { >> { { - Correct references to Internet Drafts to indicate "Work in > { >> Progress" > { >> { - Fix formatting errors detected by ID-nits > { >> > { >> I just fixed these (I think) in > { >> > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt > { >> The only changes from 06 to -07 are to re-format some of the > references > { >> in order to fix the above 2 points. > { >> Phil > { >> > { >> Ps to see the -05 to -06 diffs: > { >> > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf- > { pcn- > { >> architecture-06-from-05.diff.html or from > { >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ > { >> _______________________________________________ > { >> PCN mailing list > { >> PCN@ietf.org > { >> https://www.ietf.org/mailman/listinfo/pcn > { >> > { > > { > { -- > { Dr. Michael Menth, Assistant Professor > { University of Wuerzburg, Institute of Computer Science > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { mailto:menth@informatik.uni-wuerzburg.de > { http://www3.informatik.uni-wuerzburg.de/research/ngn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 06:56:10 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E173A6CC2; Thu, 2 Oct 2008 06:56:10 -0700 (PDT) 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 949223A6CC2 for ; Thu, 2 Oct 2008 06:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=0.227, 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 R9EI28ZzWoW6 for ; Thu, 2 Oct 2008 06:56:08 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B019B3A67E4 for ; Thu, 2 Oct 2008 06:55:08 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 14:54:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 14:54:32 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA322@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48E4CC05.7080509@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckkkrV5OO+jzP+hSUWHftdhVQ2tmwAATppw From: To: X-OriginalArrivalTime: 02 Oct 2008 13:54:32.0869 (UTC) FILETIME=[65D17550:01C92496] Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 02 October 2008 14:26 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil, { { sorry, I was confused. You are right. I overlooked that this intrinsic { contradiction is resolved by redefining the term "PCN-threshold-rate" in { Figure 1 into "PCN-excess-rate" in Figure 2. Thus, the semantic of the { term "PCN-threshold-rate" depends on the deployment scenario, right? it isnt redefined; it isnt an intrinsic contradiction. It's consistent. different deployment scenarios uses PCN marking differently - this concept is independent of the terminology. { Again, this is very confusing an I recommend to introduce the two terms { "admissible rate" and "supportable rate" in addition. They are { independent of the deployment scenario and allow the explanation of PCN { without having a particular deployment scenario in mind. Having extra terminology is a possibility. I took the view that each term that is defined is an extra thing for the reader to understand. It also requires some mapping between the admissible /supportable rates and excess/threshold rates. Personally I think this likely to be more confusing. But if there is a clamour in support of this being added, I could add it. (Michael, I take your vote in favour as read!) Phil/ { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > { -----Original Message----- { > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > { Sent: 02 October 2008 13:15 { > { To: Eardley,PL,Philip,CXR9 R { > { Cc: pcn@ietf.org { > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { > { { > { Hi Phil, { > { { > { I still have concerns regarding the nomenclature in the current { > version { > { of the architecture draft. { > { { > { Take Figure 1 on page 10. The terms PCN-threshold-rate and { > { PCN-excess-rate are meaningful only in the CL deployment scenario { > where { > { the reference rate for the threshold marker is the PCN-threshold-rate { > { and the reference rate for the excess marker is the PCN-excess-rate. { > { This is different for the SM deployment scenario where the reference { > { rate of the excess marker must be set to the PCN-threshold-rate. { > { > This is not correct. The rate of the excess marker is set to the { > PCN-excess-rate. Fig 2 shows, for the Single Marking deployment { > scenario, how this relates to admission /termination { > { > Best wishes { > Phil { > { > { > { > How { > { funny is that? No, it's not funny - this is confusing and makes { > further { > { explanations cumbersome and prone to misunderstandings. I think that { > { this is a bug that should be corrected before publication as these { > terms { > { help to describe the core idea of PCN. Using the term admissible rate { > { instead of PCN-threshold-rate and supportable rate instead of { > { PCN-excess-rate decouples PCN rate thresholds from marking mechanisms. { > { They express the meanings of these thresholds within the PCN concept { > { which are denoted on the right side in Figure 1 and allow a much { > clearer { > { presentation of the concept. { > { { > { I hope my reasoning is clear. This document is not a working document { > { for a closed group where nomenclature has no importance as long as { > { everybody knows that we mean pears if we say apples - it's a reference { > { for others to learn about PCN and, therefore, technical terms should { > be { > { precise and easy to remember. { > { { > { Regards, { > { { > { Michael { > { { > { philip.eardley@bt.com wrote: { > { > { { > { > { There are some known edits that have to be made before we can { > submit { > { > to { > { > { the { > { > { IESG: { > { > { { > { > { - Correct references to Internet Drafts to indicate "Work in { > Progress" { > { > { - Fix formatting errors detected by ID-nits { > { > { > { > I just fixed these (I think) in { > { > { > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt { > { > The only changes from 06 to -07 are to re-format some of the { > references { > { > in order to fix the above 2 points. { > { > { > { > Phil { > { > { > { > Ps to see the -05 to -06 diffs: { > { > { > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- { > { > architecture-06-from-05.diff.html { > { > or from http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ { > { > _______________________________________________ { > { > PCN mailing list { > { > PCN@ietf.org { > { > https://www.ietf.org/mailman/listinfo/pcn { > { > { > { { > { -- { > { Dr. Michael Menth, Assistant Professor { > { University of Wuerzburg, Institute of Computer Science { > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > { mailto:menth@informatik.uni-wuerzburg.de { > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 06:58:05 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D53528C1D1; Thu, 2 Oct 2008 06:58:05 -0700 (PDT) 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 0968528C1CA for ; Thu, 2 Oct 2008 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-0.119, 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 4DA1XnJu9SBc for ; Thu, 2 Oct 2008 06:58:03 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 9DE4728C10F for ; Thu, 2 Oct 2008 06:58:02 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 14:58:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 14:58:05 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA323@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckklXIHhli2cBuJTliH+vuuyrEdIQAAIJtwAAApcWA= From: To: X-OriginalArrivalTime: 02 Oct 2008 13:58:05.0753 (UTC) FILETIME=[E4B4FA90:01C92496] Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { -----Original Message----- { From: Moncaster,T,Toby,CXR9 R { Sent: 02 October 2008 14:53 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: RE: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Phil, { { While we are on the subject of references in the architecture document you { need to update them to reflect the two new WG IDs (marking and baseline { encoding). True - thanks! Also do you mean to have the circular reference to your own { architecture doc under its old draft-eardley name? yes. Once it mentions the EWMA averaging idea that is only in draft-eardley & once it's in the Acks where pointing to the people who were authors of that doc. phil { { Toby { { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Michael Menth { Sent: 02 October 2008 14:45 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil, { { good that you ask. Your citation [Menth08] relates to our joint overview { paper with the collection of AC and FT mechanisms and [Menth] relates to { the paper about threshold configuration. To avoid confusion, it might be { better to use [PCN-Overview] instead of [Menth08] and [PCN-Config] { instead of [Menth]. { { [Menth08] or [PCN-Overview] M. Menth et al.: "PCN-Based Admission { Control and Flow Termination", 2008, { http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Overview.pdf { { [Menth] or [PCN-Config] M. Menth and M. Hartmann: "Threshold { Configuration and Routing Optimization for PCN-Based Resilient Admission { Control", 2008, { http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > At the moment there are references to both [Menth] and [Menth08]. { > So the [Menth] ones can all be replaced by [Menth08]? { > - just checking! { > Thanks { > phil { > { > { -----Original Message----- { > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > { Sent: 02 October 2008 13:54 { > { To: menth@informatik.uni-wuerzburg.de { > { Cc: Eardley,PL,Philip,CXR9 R; pcn { > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { > { { > { Sorry, the correct link is { > { { > { http://www3.informatik.uni- { > { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf { > { { > { Regards, { > { { > { Michael { > { { > { Michael Menth wrote: { > { > Hi Phil, { > { > { > { > the following reference has changed. { > { > { > { > Old: { > { > { > { > [Menth] "PCN-Based Resilient Network Admission Control: The { > Impact { > { > of a Single Bit"", Technical Report , 2007, { > { > www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ { > { > Menth07-PCN-Config.pdf>. { > { > { > { > New: { > { > { > { > [Menth] "Threshold Configuration and Routing Optimization for { > { > PCN-Based Resilient Admission Control", Technical { > Report { > { > , 2007, { > { > { > Menth08-PCN-Config.pdf>. { > { > { > { > Regards, { > { > { > { > Michael { > { > { > { > philip.eardley@bt.com wrote: { > { >> { { There are some known edits that have to be made before we can { > { submit { > { >> to { > { >> { the { > { >> { IESG: { > { >> { { - Correct references to Internet Drafts to indicate "Work in { > { >> Progress" { > { >> { - Fix formatting errors detected by ID-nits { > { >> { > { >> I just fixed these (I think) in { > { >> { > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt { > { >> The only changes from 06 to -07 are to re-format some of the { > references { > { >> in order to fix the above 2 points. { > { >> Phil { > { >> { > { >> Ps to see the -05 to -06 diffs: { > { >> { > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf- { > { pcn- { > { >> architecture-06-from-05.diff.html or from { > { >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ { > { >> _______________________________________________ { > { >> PCN mailing list { > { >> PCN@ietf.org { > { >> https://www.ietf.org/mailman/listinfo/pcn { > { >> { > { > { > { { > { -- { > { Dr. Michael Menth, Assistant Professor { > { University of Wuerzburg, Institute of Computer Science { > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > { mailto:menth@informatik.uni-wuerzburg.de { > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn { { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 07:03:31 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9313A6CCA; Thu, 2 Oct 2008 07:03:31 -0700 (PDT) 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 D97513A685B for ; Thu, 2 Oct 2008 07:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.201, 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 eMEEeRH8MVrV for ; Thu, 2 Oct 2008 07:03:28 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 87E633A6A0C for ; Thu, 2 Oct 2008 07:03:28 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 15:03:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 15:03:35 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA324@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48E4D060.3000103@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckklU+gAlVWHuiXRDWwE0XZN8kIGQAAcimg From: To: X-OriginalArrivalTime: 02 Oct 2008 14:03:36.0341 (UTC) FILETIME=[A9C0B450:01C92497] Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Thanks for the update. I think I prefer to keep ref as [author name], for consistency with the others. I just checked & I think I have each of the refs to the appropriate one of your docs. But if you think any of the current refs to [menth] in fact should be to [menth08] or vice-versa, please shout! phil { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 02 October 2008 14:45 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil, { { good that you ask. Your citation [Menth08] relates to our joint overview { paper with the collection of AC and FT mechanisms and [Menth] relates to { the paper about threshold configuration. To avoid confusion, it might be { better to use [PCN-Overview] instead of [Menth08] and [PCN-Config] { instead of [Menth]. { { [Menth08] or [PCN-Overview] M. Menth et al.: "PCN-Based Admission { Control and Flow Termination", 2008, { http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Overview.pdf { { [Menth] or [PCN-Config] M. Menth and M. Hartmann: "Threshold { Configuration and Routing Optimization for PCN-Based Resilient Admission { Control", 2008, { http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > At the moment there are references to both [Menth] and [Menth08]. { > So the [Menth] ones can all be replaced by [Menth08]? { > - just checking! { > Thanks { > phil { > { > { -----Original Message----- { > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > { Sent: 02 October 2008 13:54 { > { To: menth@informatik.uni-wuerzburg.de { > { Cc: Eardley,PL,Philip,CXR9 R; pcn { > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { > { { > { Sorry, the correct link is { > { { > { http://www3.informatik.uni- { > { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Config.pdf { > { { > { Regards, { > { { > { Michael { > { { > { Michael Menth wrote: { > { > Hi Phil, { > { > { > { > the following reference has changed. { > { > { > { > Old: { > { > { > { > [Menth] "PCN-Based Resilient Network Admission Control: The { > Impact { > { > of a Single Bit"", Technical Report , 2007, { > { > www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ { > { > Menth07-PCN-Config.pdf>. { > { > { > { > New: { > { > { > { > [Menth] "Threshold Configuration and Routing Optimization for { > { > PCN-Based Resilient Admission Control", Technical { > Report { > { > , 2007, { > { > { > Menth08-PCN-Config.pdf>. { > { > { > { > Regards, { > { > { > { > Michael { > { > { > { > philip.eardley@bt.com wrote: { > { >> { { There are some known edits that have to be made before we can { > { submit { > { >> to { > { >> { the { > { >> { IESG: { > { >> { { - Correct references to Internet Drafts to indicate "Work in { > { >> Progress" { > { >> { - Fix formatting errors detected by ID-nits { > { >> { > { >> I just fixed these (I think) in { > { >> { > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt { > { >> The only changes from 06 to -07 are to re-format some of the { > references { > { >> in order to fix the above 2 points. { > { >> Phil { > { >> { > { >> Ps to see the -05 to -06 diffs: { > { >> { > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf- { > { pcn- { > { >> architecture-06-from-05.diff.html or from { > { >> http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ { > { >> _______________________________________________ { > { >> PCN mailing list { > { >> PCN@ietf.org { > { >> https://www.ietf.org/mailman/listinfo/pcn { > { >> { > { > { > { { > { -- { > { Dr. Michael Menth, Assistant Professor { > { University of Wuerzburg, Institute of Computer Science { > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > { mailto:menth@informatik.uni-wuerzburg.de { > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 07:06:40 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EA83A67E4; Thu, 2 Oct 2008 07:06:40 -0700 (PDT) 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 002AB3A67E4 for ; Thu, 2 Oct 2008 07:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=0.308, 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 o0awRG+UWGB2 for ; Thu, 2 Oct 2008 07:06:34 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7B8CD3A659B for ; Thu, 2 Oct 2008 07:06:34 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 15:06:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 15:06:08 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA322@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckkkrV5OO+jzP+hSUWHftdhVQ2tmwAATppwAADsVcA= References: <48E4CC05.7080509@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA322@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 02 Oct 2008 14:06:00.0650 (UTC) FILETIME=[FFC482A0:01C92497] Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I think we should leave terminology as it is. Otherwise we will just get locked into a circular debate and end up with a more confusing document as Phil points out below. Yes, there are good arguments for using Michael's terminology in terms of accuracy but they make the job of describing the ACTUAL system more difficult and thus risk people getting things wrong. Given we seem to be focussing in on a small subset of the possible solutions I think "restrictive" terminology (eg that with extra semantics within the terms) is no bad thing... Toby -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 02 October 2008 14:55 To: menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 02 October 2008 14:26 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil, { { sorry, I was confused. You are right. I overlooked that this intrinsic { contradiction is resolved by redefining the term "PCN-threshold-rate" in { Figure 1 into "PCN-excess-rate" in Figure 2. Thus, the semantic of the { term "PCN-threshold-rate" depends on the deployment scenario, right? it isnt redefined; it isnt an intrinsic contradiction. It's consistent. different deployment scenarios uses PCN marking differently - this concept is independent of the terminology. { Again, this is very confusing an I recommend to introduce the two terms { "admissible rate" and "supportable rate" in addition. They are { independent of the deployment scenario and allow the explanation of PCN { without having a particular deployment scenario in mind. Having extra terminology is a possibility. I took the view that each term that is defined is an extra thing for the reader to understand. It also requires some mapping between the admissible /supportable rates and excess/threshold rates. Personally I think this likely to be more confusing. But if there is a clamour in support of this being added, I could add it. (Michael, I take your vote in favour as read!) Phil/ { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > { -----Original Message----- { > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > { Sent: 02 October 2008 13:15 { > { To: Eardley,PL,Philip,CXR9 R { > { Cc: pcn@ietf.org { > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { > { { > { Hi Phil, { > { { > { I still have concerns regarding the nomenclature in the current { > version { > { of the architecture draft. { > { { > { Take Figure 1 on page 10. The terms PCN-threshold-rate and { > { PCN-excess-rate are meaningful only in the CL deployment scenario { > where { > { the reference rate for the threshold marker is the PCN-threshold-rate { > { and the reference rate for the excess marker is the PCN-excess-rate. { > { This is different for the SM deployment scenario where the reference { > { rate of the excess marker must be set to the PCN-threshold-rate. { > { > This is not correct. The rate of the excess marker is set to the { > PCN-excess-rate. Fig 2 shows, for the Single Marking deployment { > scenario, how this relates to admission /termination { > { > Best wishes { > Phil { > { > { > { > How { > { funny is that? No, it's not funny - this is confusing and makes { > further { > { explanations cumbersome and prone to misunderstandings. I think that { > { this is a bug that should be corrected before publication as these { > terms { > { help to describe the core idea of PCN. Using the term admissible rate { > { instead of PCN-threshold-rate and supportable rate instead of { > { PCN-excess-rate decouples PCN rate thresholds from marking mechanisms. { > { They express the meanings of these thresholds within the PCN concept { > { which are denoted on the right side in Figure 1 and allow a much { > clearer { > { presentation of the concept. { > { { > { I hope my reasoning is clear. This document is not a working document { > { for a closed group where nomenclature has no importance as long as { > { everybody knows that we mean pears if we say apples - it's a reference { > { for others to learn about PCN and, therefore, technical terms should { > be { > { precise and easy to remember. { > { { > { Regards, { > { { > { Michael { > { { > { philip.eardley@bt.com wrote: { > { > { { > { > { There are some known edits that have to be made before we can { > submit { > { > to { > { > { the { > { > { IESG: { > { > { { > { > { - Correct references to Internet Drafts to indicate "Work in { > Progress" { > { > { - Fix formatting errors detected by ID-nits { > { > { > { > I just fixed these (I think) in { > { > { > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt { > { > The only changes from 06 to -07 are to re-format some of the { > references { > { > in order to fix the above 2 points. { > { > { > { > Phil { > { > { > { > Ps to see the -05 to -06 diffs: { > { > { > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- { > { > architecture-06-from-05.diff.html { > { > or from http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ { > { > _______________________________________________ { > { > PCN mailing list { > { > PCN@ietf.org { > { > https://www.ietf.org/mailman/listinfo/pcn { > { > { > { { > { -- { > { Dr. Michael Menth, Assistant Professor { > { University of Wuerzburg, Institute of Computer Science { > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > { mailto:menth@informatik.uni-wuerzburg.de { > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 07:29:35 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E79F3A6CCD; Thu, 2 Oct 2008 07:29:35 -0700 (PDT) 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 332F93A6CC7 for ; Thu, 2 Oct 2008 07:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=0.472, 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 oM8XxSONQE56 for ; Thu, 2 Oct 2008 07:29:30 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E4F843A6CC5 for ; Thu, 2 Oct 2008 07:29:29 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 15:29:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 15:29:19 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA328@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20081002124503.3E9BA28C1A5@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt Thread-Index: AckkjMkUnbcv2miUS8Cia7j8xso4rAAC8a7A From: To: X-OriginalArrivalTime: 02 Oct 2008 14:29:20.0101 (UTC) FILETIME=[41E7C950:01C9249B] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, This is the update to the marking behaviour draft, which (I think) includes all the discussion we had on the list and in Dublin about the previous version (draft-eardley-pan-marking-behaviour-01) Summary of changes: o Removed material concerning per domain behaviour and PCN-boundary- node operation (temporarily archived to Appendix C) it was agreed that this draft should be just about the 'per-hop' behaviour. We need a draft about the per-domain behaviour. This will be very short, eg saying that all nodes in the PCN-domain have to be configured to do the same type of marking, the same choice about encoding states, do policing at the ingress-node etc. ietf-pcn-baseline-encoding Appendix B also indicates some things that the PCN-boundary-nodes need to do. I (& Toby) don't have time to write this per-domain behaviour draft (hoping for volunteer(s)!) There's also the Info edge behaviour draft or drafts. Some of the material in Appendix C might be useful for that. o Removed mention of downgrading as an option for per-hop traffic conditioning. In fact, downgrading is no longer allowed because S 2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a non PCN-packet". o Traffic conditioning is now a MAY. Since in general flow termination (not traffic conditioning) is PCN's method for handling problems of too much traffic. I think I got the conclusion on this right, but would appreciate people checking. I think a MAY captures best our conclusion (rather than a SHOULD or not talking about it all) o Metered-packets: competing-non-PCN-packets now MAY be metered. Since it is recommended that the operator doesn't allow any competing-non-PCN-traffic, and (if there is) there are potentially other ways of coping. This was the discussion with Christian recently about Section 6.5 of the architecture draft. In the previous draft, it was a MUST to meter these competing-non-PCN-packets. This seems onerous when we also recommend that there is no such traffic. o No changes (outside traffic conditioning & metering of competing- non-PCN-traffic) to the Normative sections of the draft. o Appendix B.1 added about competing-non-PCN-traffic. Recommended that there is no such traffic, but guidance given if there is. Sorry this has taken me longer than expected to get out. I'll do another rev before Minneapolis. I believe (or at least hope!) that it'll then be ready for last call/ Best wishes phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Internet-Drafts@ietf.org { Sent: 02 October 2008 13:45 { To: i-d-announce@ietf.org { Cc: pcn@ietf.org { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.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-00.txt { Pages : 22 { Date : 2008-10-02 { { 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 first { configured rate. Excess traffic marking marks a proportion of PCN- { packets, such that the amount marked equals the traffic rate in { excess of a second configured rate.Requirements Language { { The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", { "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this { document are to be interpreted as described in RFC 2119 [RFC2119]. { { A URL for this Internet-Draft is: { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour- { 00.txt { { Internet-Drafts are also available by anonymous FTP at: { ftp://ftp.ietf.org/internet-drafts/ { { Below is the data which will enable a MIME compliant mail reader { implementation to automatically retrieve the ASCII version of the { Internet-Draft. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 07:58:49 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C331F3A69CD; Thu, 2 Oct 2008 07:58:49 -0700 (PDT) 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 823623A69CD for ; Thu, 2 Oct 2008 07:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 BsB-NXcn-cQv for ; Thu, 2 Oct 2008 07:58:47 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id C75633A6881 for ; Thu, 2 Oct 2008 07:58:47 -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 1KlPcn-00072X-1n for pcn@ietf.org; Thu, 02 Oct 2008 10:57:53 -0400 MIME-Version: 1.0 Date: Thu, 02 Oct 2008 10:57:52 -0400 From: To: pcn@ietf.org Message-ID: <757c4a1079b168f8832dcbb3b4257520@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] Updated working group milestones X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org FYI The PCN working group milestones have been updated. See: http://www.ietf.org/html.charters/pcn-charter.html Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 09:23:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239FA28C1FC; Thu, 2 Oct 2008 09:23:02 -0700 (PDT) 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 BAB3B28C1F4 for ; Thu, 2 Oct 2008 09:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 iy16fn17d9h4 for ; Thu, 2 Oct 2008 09:22:59 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7C68A28C1D2 for ; Thu, 2 Oct 2008 09:22:59 -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); Thu, 2 Oct 2008 17:22:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 17:22:45 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA32A@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20081001170320.E114.26AD349@ntt-at.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckjoM0QNrLIHHaPRNOWy+qJV4z2gQBCXu9g From: To: , X-OriginalArrivalTime: 02 Oct 2008 16:22:46.0426 (UTC) FILETIME=[1ACA8FA0:01C924AB] Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Daisuke, I think it's very reasonable to add "(others might be possible)" to S6.3, the same as in S6.1 & 6.2. You're right that an operator might decide to do something we haven't thought about. Thanks Phil/ { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { daisuke.satoh@ntt-at.co.jp { Sent: 01 October 2008 09:36 { To: pcn@ietf.org { Subject: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil, { { { Thank you for accepting my following comment. "Others might be possible" { is added in both 6.1 and 6.2. { Does it mean that a new algorithm using the baseline encoding, which { realize both admission control and flow termination, is acceptable? { I would like to confirm it because there is no "Other might be possible" { in 6.3. { { { { A new algorithm may use excess-traffic-marking for PCN-threshold-rate and { threshold-marking for PCN-excess-rate. Actually, Single Marking use { excess-traffic-marking for PCN-threshold-rate. It is unclear that the { architecture draft excludes such algorithms. In my opinion, they should { not be excluded. { { { { Best regards, { Daisuke { { { { { -----Original Message----- { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { { daisuke.satoh@ntt-at.co.jp { { Sent: 14 August 2008 11:33 { { To: pcn@ietf.org { { Subject: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { { { Hi all, { { { { { { I have been interested in PCN WG and I have joined PCN WG since { { IETF69(Chicago). { { { { I have reviewed the architecture draft and have a comment on Sec 6.3. { { The third option (both admission control and flow termination) almost { { describes the single marking algorithm itself. This description seems { to { { exclude a future new algorithm and to limit a solution. In my opinion, { a { { new algorithm should not be excluded. Actually, a new algorithm idea { was { { presented in Dublin by Roudiger Geib. { { { { { { { { I propose that the third option is modified as follows, { { o both admission cotrol and flow termination: Either excess-traffic- { { marking { { algorithm or threshold-marking algorithm writes PCN-marks. As an { example { { of excess-traffic-marking case (Figure 2), [I-D. { { charney-pcn-single-marking] describes how both admission control and { { flow termination can be triggered and also gives some of the pros and { { cons of this approarch. The main downside is that admission control is { { less accurate. { { { { { { { { { { Best regards, { { Daisuke SATOH { { { { { { { { { { --- { Date: Mon, 29 Sep 2008 12:49:05 -0400 { From: { Subject: [PCN] Second Last Call for draft-ietf-pcn-architecture { To: pcn@ietf.org { Message-ID: <864b1db62edbb6688022b71b9421de85@petri-meat.com> { Content-Type: text/plain; charset="UTF-8" { { We will be running a brief (~1 week) last call on { draft-ietf-pcn-architecture-06. This last call will end on Tuesday { October { 7. Please send comments ASAP. { { Diffs between -06 and -05 can be viewed at: { { http://tools.ietf.org/rfcdiff { { Use the following URLs to reference -05 and -06: { { http://tools.ietf.org/id/draft-ietf-pcn-architecture-05.txt { http://tools.ietf.org/id/draft-ietf-pcn-architecture-06.txt { { There are some known edits that have to be made before we can submit to { the { IESG: { { - Correct references to Internet Drafts to indicate "Work in Progress" { - Fix formatting errors detected by ID-nits { { { Regards, { { // Steve { { { { -- { Daisuke Satoh { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 2 09:27:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1423A6A0C; Thu, 2 Oct 2008 09:27:20 -0700 (PDT) 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 B9E7F3A6A0C for ; Thu, 2 Oct 2008 09:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKws-0fRiDsh for ; Thu, 2 Oct 2008 09:27:17 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 1CE593A67A8 for ; Thu, 2 Oct 2008 09:27:16 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9480B198E5F; Thu, 2 Oct 2008 18:02:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 88550198E5B; Thu, 2 Oct 2008 18:02:15 +0200 (CEST) Received: from [92.229.220.92] (g229220092.adsl.alicedsl.de [92.229.220.92]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1F5F6A05C7; Thu, 2 Oct 2008 18:02:15 +0200 (CEST) Message-ID: <48E4F029.6080204@informatik.uni-wuerzburg.de> Date: Thu, 02 Oct 2008 18:00:41 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <48E4CC05.7080509@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA322@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, toby.moncaster@bt.com wrote: > I think we should leave terminology as it is. Otherwise we will just get > locked into a circular debate and end up with a more confusing document > as Phil points out below. That is not true at all. Having concise nomenclature makes documents shorter. You can explain the core idea of PCN-based AC and FT for all PCN independently of any deployment scenario: PCN traffic < admissible rate -> admit new flows admissible rate < PCN traffic < supportable rate -> block new flows supportable rate < PCN traffic -> block new flows and terminate some admitted flows No case analysis is required that depends on the deployment scenario and the risk that people get something wrong is greatly reduced. > Yes, there are good arguments for using > Michael's terminology in terms of accuracy but they make the job of > describing the ACTUAL system more difficult and thus risk people getting > things wrong. > Currently, the reference rate for the excess marker is given the name "PCN-excess-rate" and the reference rate for the threshold marker is given the name "PCN-threshold-rate". From my perspective, these terms are not necessary, but they do not harm. They help to describe the three particular deployment scenarios in a very simple way, but only if the general threshold names are available: CL,3sm: PCN-threshold-rate= admissible rate, PCN-excess-rate= supportable rate SM: PCN-excess-rate= admissible rate > Given we seem to be focussing in on a small subset of the possible > solutions I think "restrictive" terminology (eg that with extra > semantics within the terms) is no bad thing... > The small subset of possible solutions contains CL and SM and there you have the problem already. Regards, Michael > Toby > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 02 October 2008 14:55 > To: menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture > > > > { -----Original Message----- > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { Sent: 02 October 2008 14:26 > { To: Eardley,PL,Philip,CXR9 R > { Cc: pcn@ietf.org > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture > { > { Hi Phil, > { > { sorry, I was confused. You are right. I overlooked that this intrinsic > { contradiction is resolved by redefining the term "PCN-threshold-rate" > in > { Figure 1 into "PCN-excess-rate" in Figure 2. Thus, the semantic of the > { term "PCN-threshold-rate" depends on the deployment scenario, right? > > it isnt redefined; it isnt an intrinsic contradiction. It's consistent. > different deployment scenarios uses PCN marking differently - this > concept is independent of the terminology. > > { Again, this is very confusing an I recommend to introduce the two > terms > { "admissible rate" and "supportable rate" in addition. They are > { independent of the deployment scenario and allow the explanation of > PCN > { without having a particular deployment scenario in mind. > > Having extra terminology is a possibility. I took the view that each > term that is defined is an extra thing for the reader to understand. It > also requires some mapping between the admissible /supportable rates and > excess/threshold rates. Personally I think this likely to be more > confusing. But if there is a clamour in support of this being added, I > could add it. (Michael, I take your vote in favour as read!) > > Phil/ > > { > { Regards, > { > { Michael > { > { philip.eardley@bt.com wrote: > { > { -----Original Message----- > { > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { > { Sent: 02 October 2008 13:15 > { > { To: Eardley,PL,Philip,CXR9 R > { > { Cc: pcn@ietf.org > { > { Subject: Re: [PCN] Second Last Call for > draft-ietf-pcn-architecture > { > { > { > { Hi Phil, > { > { > { > { I still have concerns regarding the nomenclature in the current > { > version > { > { of the architecture draft. > { > { > { > { Take Figure 1 on page 10. The terms PCN-threshold-rate and > { > { PCN-excess-rate are meaningful only in the CL deployment scenario > { > where > { > { the reference rate for the threshold marker is the > PCN-threshold-rate > { > { and the reference rate for the excess marker is the > PCN-excess-rate. > { > { This is different for the SM deployment scenario where the > reference > { > { rate of the excess marker must be set to the PCN-threshold-rate. > { > > { > This is not correct. The rate of the excess marker is set to the > { > PCN-excess-rate. Fig 2 shows, for the Single Marking deployment > { > scenario, how this relates to admission /termination > { > > { > Best wishes > { > Phil > { > > { > > { > > { > How > { > { funny is that? No, it's not funny - this is confusing and makes > { > further > { > { explanations cumbersome and prone to misunderstandings. I think > that > { > { this is a bug that should be corrected before publication as these > { > terms > { > { help to describe the core idea of PCN. Using the term admissible > rate > { > { instead of PCN-threshold-rate and supportable rate instead of > { > { PCN-excess-rate decouples PCN rate thresholds from marking > mechanisms. > { > { They express the meanings of these thresholds within the PCN > concept > { > { which are denoted on the right side in Figure 1 and allow a much > { > clearer > { > { presentation of the concept. > { > { > { > { I hope my reasoning is clear. This document is not a working > document > { > { for a closed group where nomenclature has no importance as long as > { > { everybody knows that we mean pears if we say apples - it's a > reference > { > { for others to learn about PCN and, therefore, technical terms > should > { > be > { > { precise and easy to remember. > { > { > { > { Regards, > { > { > { > { Michael > { > { > { > { philip.eardley@bt.com wrote: > { > { > { > { > { > { There are some known edits that have to be made before we can > { > submit > { > { > to > { > { > { the > { > { > { IESG: > { > { > { > { > { > { - Correct references to Internet Drafts to indicate "Work in > { > Progress" > { > { > { - Fix formatting errors detected by ID-nits > { > { > > { > { > I just fixed these (I think) in > { > { > > { > > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt > { > { > The only changes from 06 to -07 are to re-format some of the > { > references > { > { > in order to fix the above 2 points. > { > { > > { > { > Phil > { > { > > { > { > Ps to see the -05 to -06 diffs: > { > { > > { > > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- > { > { > architecture-06-from-05.diff.html > { > { > or from > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ > { > { > _______________________________________________ > { > { > PCN mailing list > { > { > PCN@ietf.org > { > { > https://www.ietf.org/mailman/listinfo/pcn > { > { > > { > { > { > { -- > { > { Dr. Michael Menth, Assistant Professor > { > { University of Wuerzburg, Institute of Computer Science > { > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { > { mailto:menth@informatik.uni-wuerzburg.de > { > { http://www3.informatik.uni-wuerzburg.de/research/ngn > { > > { > { -- > { Dr. Michael Menth, Assistant Professor > { University of Wuerzburg, Institute of Computer Science > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { mailto:menth@informatik.uni-wuerzburg.de > { http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 3 02:23:09 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96503A6966; Fri, 3 Oct 2008 02:23:09 -0700 (PDT) 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 C1DE23A689D for ; Fri, 3 Oct 2008 02:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.41 X-Spam-Level: *** X-Spam-Status: No, score=3.41 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+XpctjYzAvg for ; Fri, 3 Oct 2008 02:23:06 -0700 (PDT) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id B913D3A6966 for ; Fri, 3 Oct 2008 02:23:02 -0700 (PDT) Received: (qmail 9680 invoked by alias); 3 Oct 2008 09:23:30 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 3 Oct 2008 09:23:30 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m939NSOM018167 for ; Fri, 3 Oct 2008 18:23:29 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m939NTYx026746 for ; Fri, 3 Oct 2008 18:23:29 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: from [192.168.21.66] (ip21-066.tec.ntt-at.co.jp [192.168.21.66]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 6161653F61; Fri, 3 Oct 2008 18:23:29 +0900 (JST) Date: Fri, 03 Oct 2008 18:23:18 +0900 From: =?ISO-2022-JP?B?GyRCOjRGIyEhQmdKZRsoQg==?= To: Message-Id: <20081003175716.D806.26AD349@ntt-at.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] Subject: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil and Michael, Thank Phil for accepting my recent comment. I agree with Michael about PCN-excess-rate and PCN-threshold-rate because some new algorithms may use PCN-excess-rate that is less than PCN-threshold-rate and others may use double PCN-excess-rates or double PCN-threshold-rates. In my opinion, all the possiblity should not be excluded. Moreover, they are confusing as Michael pointed out. Best regards, Daisuke { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 02 October 2008 14:26 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil, { { sorry, I was confused. You are right. I overlooked that this intrinsic { contradiction is resolved by redefining the term "PCN-threshold-rate" in { Figure 1 into "PCN-excess-rate" in Figure 2. Thus, the semantic of the { term "PCN-threshold-rate" depends on the deployment scenario, right? it isnt redefined; it isnt an intrinsic contradiction. It's consistent. different deployment scenarios uses PCN marking differently - this concept is independent of the terminology. { Again, this is very confusing an I recommend to introduce the two terms { "admissible rate" and "supportable rate" in addition. They are { independent of the deployment scenario and allow the explanation of PCN { without having a particular deployment scenario in mind. Having extra terminology is a possibility. I took the view that each term that is defined is an extra thing for the reader to understand. It also requires some mapping between the admissible /supportable rates and excess/threshold rates. Personally I think this likely to be more confusing. But if there is a clamour in support of this being added, I could add it. (Michael, I take your vote in favour as read!) Phil/ { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > { -----Original Message----- { > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > { Sent: 02 October 2008 13:15 { > { To: Eardley,PL,Philip,CXR9 R { > { Cc: pcn@ietf.org { > { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { > { { > { Hi Phil, { > { { > { I still have concerns regarding the nomenclature in the current { > version { > { of the architecture draft. { > { { > { Take Figure 1 on page 10. The terms PCN-threshold-rate and { > { PCN-excess-rate are meaningful only in the CL deployment scenario { > where { > { the reference rate for the threshold marker is the PCN-threshold-rate { > { and the reference rate for the excess marker is the PCN-excess-rate. { > { This is different for the SM deployment scenario where the reference { > { rate of the excess marker must be set to the PCN-threshold-rate. { > { > This is not correct. The rate of the excess marker is set to the { > PCN-excess-rate. Fig 2 shows, for the Single Marking deployment { > scenario, how this relates to admission /termination { > { > Best wishes { > Phil { > { > { > { > How { > { funny is that? No, it's not funny - this is confusing and makes { > further { > { explanations cumbersome and prone to misunderstandings. I think that { > { this is a bug that should be corrected before publication as these { > terms { > { help to describe the core idea of PCN. Using the term admissible rate { > { instead of PCN-threshold-rate and supportable rate instead of { > { PCN-excess-rate decouples PCN rate thresholds from marking mechanisms. { > { They express the meanings of these thresholds within the PCN concept { > { which are denoted on the right side in Figure 1 and allow a much { > clearer { > { presentation of the concept. { > { { > { I hope my reasoning is clear. This document is not a working document { > { for a closed group where nomenclature has no importance as long as { > { everybody knows that we mean pears if we say apples - it's a reference { > { for others to learn about PCN and, therefore, technical terms should { > be { > { precise and easy to remember. { > { { > { Regards, { > { { > { Michael { > { { > { philip.eardley@bt.com wrote: { > { > { { > { > { There are some known edits that have to be made before we can { > submit { > { > to { > { > { the { > { > { IESG: { > { > { { > { > { - Correct references to Internet Drafts to indicate "Work in { > Progress" { > { > { - Fix formatting errors detected by ID-nits { > { > { > { > I just fixed these (I think) in { > { > { > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-07.txt { > { > The only changes from 06 to -07 are to re-format some of the { > references { > { > in order to fix the above 2 points. { > { > { > { > Phil { > { > { > { > Ps to see the -05 to -06 diffs: { > { > { > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn- { > { > architecture-06-from-05.diff.html { > { > or from http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/ { > { > _______________________________________________ { > { > PCN mailing list { > { > PCN@ietf.org { > { > https://www.ietf.org/mailman/listinfo/pcn { > { > { > { { > { -- { > { Dr. Michael Menth, Assistant Professor { > { University of Wuerzburg, Institute of Computer Science { > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > { mailto:menth@informatik.uni-wuerzburg.de { > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 3 03:03:43 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE8328C0D6; Fri, 3 Oct 2008 03:03:43 -0700 (PDT) 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 449D23A6AD8 for ; Fri, 3 Oct 2008 03:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx6cYfg3ZIsC for ; Fri, 3 Oct 2008 03:03:40 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 9F9EF3A69DA for ; Fri, 3 Oct 2008 03:03:39 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 26CACA06D2; Fri, 3 Oct 2008 12:03:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1ABFFA06CD; Fri, 3 Oct 2008 12:03:24 +0200 (CEST) Received: from [92.227.25.48] (g227025048.adsl.alicedsl.de [92.227.25.48]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id BEE86198E4E; Fri, 3 Oct 2008 12:03:23 +0200 (CEST) Message-ID: <48E5ED8E.8010606@informatik.uni-wuerzburg.de> Date: Fri, 03 Oct 2008 12:01:50 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: =?UTF-8?B?5L2Q6Jek44CA5aSn6LyU?= References: <20081003175716.D806.26AD349@ntt-at.co.jp> In-Reply-To: <20081003175716.D806.26AD349@ntt-at.co.jp> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org RGVhciBEYWlzdWtlLAoKdGhlIGtleSBmZWF0dXJlIG9mIHRocmVzaG9sZCBtYXJraW5nIGlzIHRo YXQgaXQgbWFya3MgYWxsIHBhY2tldHMgd2hlbiBhIApjZXJ0YWluIHJhdGUgaXMgZXhjZWVkZWQu IFRoZXJlZm9yZSwgSSBsaWtlIHRoZSB0ZXJtICJleGhhdXN0aXZlIAptYXJraW5nIiBiZXR0ZXIg dGhhbiAidGhyZXNob2xkIG1hcmtpbmciIGFzIGl0IHRlbGxzIHlvdSB3aGF0IGl0IGRvZXMuIApN b3Jlb3ZlciwgYWxnb3JpdGhtcyBmb3IgZXhjZXNzIG1hcmtpbmcgYWxzbyB1c2UgdGhyZXNob2xk cyBhbmQgCmV4aGF1c3RpdmUgbWFya2luZyBjYW4gYWxzbyBhY2hpZXZlZCBieSByYW1wIG1hcmtp bmcsIG5vdCBvbmx5IGJ5IAp0aHJlc2hvbGQgbWFya2luZyB3aG9zZSBpbXBsZW1lbnRhdGlvbiB1 c2VzIGEgdGhyZXNob2xkLiBUaGlzIGlzIGFub3RoZXIgCm5vbWVuY2xhdHVyZSBpc3N1ZSB3aGlj aCBJIHRoaW5rIG5lZWRzIGltcHJvdmVtZW50LCBidXQgaXQgaXMgbm90IGFzIAppbXBvcnRhbnQg YXMgdGhlIGludHJvZHVjdGlvbiBvZiB0aGUgdGVybXMgYWRtaXNzaWJsZSBhbmQgc3VwcG9ydGFi bGUgcmF0ZS4KCldoYXQgSSBhY3R1YWxseSB3YW50IHRvIHNheSBpcyB0aGUgZm9sbG93aW5nLiBX aGVuIHRoZSByZWZlcmVuY2UgcmF0ZSAKZm9yIGV4aGF1c3RpdmUgbWFya2luZyAoUENOLXRocmVz aG9sZC1yYXRlKSBpcyBzZXQgdG8gdGhlIHN1cHBvcnRhYmxlIApyYXRlLCBlaXRoZXIgYWxsIHBh Y2tldHMgYXJlIG1hcmtlZCAoUENOIHJhdGUgPiBzdXBwb3J0YWJsZSByYXRlKSBvciAKbm9uZSAo UENOIHJhdGUgPCBzdXBwb3J0YWJsZSByYXRlKS4gVGh1cywgaXQgY2xlYXJseSBpbmRpY2F0ZXMg d2hldGhlciAKdGhlIFBDTiByYXRlIG9uIGEgbGluayBoYXMgZXhjZWVkZWQgdGhlIHN1cHBvcnRh YmxlIHJhdGUgb3Igbm90LiAKSG93ZXZlciwgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGluZmVyIGFu IGVzdGltYXRlIGZvciB0aGUgdHJhZmZpYyByYXRlIAp0aGF0IGV4Y2VlZHMgdGhlIHN1cHBvcnRh YmxlIHJhdGUuIFRoZXJlZm9yZSwgZXhoYXVzdGl2ZSBtYXJraW5nIGlzIGZyb20gCm15IHBlcnNw ZWN0aXZlIG5vdCB2ZXJ5IGhlbHBmdWwgZm9yIGZsb3cgdGVybWluYXRpb24gZm9yIHdoaWNoIHRo ZSAKc3VwcG9ydGFibGUgcmF0ZSB0aHJlc2hvbGQgaXMgcmVsZXZhbnQuIEJ1dCBJIGRvbid0IHRo aW5rIGVpdGhlciB0aGF0IGl0IApuZWVkcyB0byBiZSBwcm9oaWJpdGVkIDstKQoKS2luZCByZWdh cmRzLAoKICAgIE1pY2hhZWwKCgrkvZDol6TjgIDlpKfovJQgd3JvdGU6Cj4gSGkgUGhpbCBhbmQg TWljaGFlbCwKPgo+IFRoYW5rIFBoaWwgZm9yIGFjY2VwdGluZyBteSByZWNlbnQgY29tbWVudC4K Pgo+IEkgYWdyZWUgd2l0aCBNaWNoYWVsIGFib3V0IFBDTi1leGNlc3MtcmF0ZSBhbmQgUENOLXRo cmVzaG9sZC1yYXRlCj4gYmVjYXVzZSBzb21lIG5ldyBhbGdvcml0aG1zIG1heSB1c2UgUENOLWV4 Y2Vzcy1yYXRlIHRoYXQgaXMgbGVzcyB0aGFuCj4gUENOLXRocmVzaG9sZC1yYXRlIGFuZCBvdGhl cnMgbWF5IHVzZSBkb3VibGUgUENOLWV4Y2Vzcy1yYXRlcyBvciBkb3VibGUKPiBQQ04tdGhyZXNo b2xkLXJhdGVzLiBJbiBteSBvcGluaW9uLCBhbGwgdGhlIHBvc3NpYmxpdHkgc2hvdWxkIG5vdCBi ZQo+IGV4Y2x1ZGVkLiBNb3Jlb3ZlciwgdGhleSBhcmUgY29uZnVzaW5nIGFzIE1pY2hhZWwgcG9p bnRlZCBvdXQuCj4KPiBCZXN0IHJlZ2FyZHMsCj4gRGFpc3VrZQo+Cj4KPgo+Cj4geyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQo+IHsgRnJvbTogTWljaGFlbCBNZW50aCBbbWFpbHRvOm1lbnRo QGluZm9ybWF0aWsudW5pLXd1ZXJ6YnVyZy5kZV0KPiB7IFNlbnQ6IDAyIE9jdG9iZXIgMjAwOCAx NDoyNgo+IHsgVG86IEVhcmRsZXksUEwsUGhpbGlwLENYUjkgUgo+IHsgQ2M6IHBjbkBpZXRmLm9y Zwo+IHsgU3ViamVjdDogUmU6IFtQQ05dIFNlY29uZCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYt cGNuLWFyY2hpdGVjdHVyZQo+IHsgCj4geyBIaSBQaGlsLAo+IHsgCj4geyBzb3JyeSwgSSB3YXMg Y29uZnVzZWQuIFlvdSBhcmUgcmlnaHQuIEkgb3Zlcmxvb2tlZCB0aGF0IHRoaXMgaW50cmluc2lj Cj4geyBjb250cmFkaWN0aW9uIGlzIHJlc29sdmVkIGJ5IHJlZGVmaW5pbmcgdGhlIHRlcm0gIlBD Ti10aHJlc2hvbGQtcmF0ZSIKPiBpbgo+IHsgRmlndXJlIDEgaW50byAiUENOLWV4Y2Vzcy1yYXRl IiBpbiBGaWd1cmUgMi4gVGh1cywgdGhlIHNlbWFudGljIG9mIHRoZQo+IHsgdGVybSAiUENOLXRo cmVzaG9sZC1yYXRlIiBkZXBlbmRzIG9uIHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvLCByaWdodD8K Pgo+IGl0IGlzbnQgcmVkZWZpbmVkOyBpdCBpc250IGFuIGludHJpbnNpYyBjb250cmFkaWN0aW9u LiBJdCdzIGNvbnNpc3RlbnQuCj4gZGlmZmVyZW50IGRlcGxveW1lbnQgc2NlbmFyaW9zIHVzZXMg UENOIG1hcmtpbmcgZGlmZmVyZW50bHkgLSB0aGlzCj4gY29uY2VwdCBpcyBpbmRlcGVuZGVudCBv ZiB0aGUgdGVybWlub2xvZ3kuIAo+Cj4geyBBZ2FpbiwgdGhpcyBpcyB2ZXJ5IGNvbmZ1c2luZyBh biBJIHJlY29tbWVuZCB0byBpbnRyb2R1Y2UgdGhlIHR3bwo+IHRlcm1zCj4geyAiYWRtaXNzaWJs ZSByYXRlIiBhbmQgInN1cHBvcnRhYmxlIHJhdGUiIGluIGFkZGl0aW9uLiBUaGV5IGFyZQo+IHsg aW5kZXBlbmRlbnQgb2YgdGhlIGRlcGxveW1lbnQgc2NlbmFyaW8gYW5kIGFsbG93IHRoZSBleHBs YW5hdGlvbiBvZgo+IFBDTgo+IHsgd2l0aG91dCBoYXZpbmcgYSBwYXJ0aWN1bGFyIGRlcGxveW1l bnQgc2NlbmFyaW8gaW4gbWluZC4KPgo+IEhhdmluZyBleHRyYSB0ZXJtaW5vbG9neSBpcyBhIHBv c3NpYmlsaXR5LiBJIHRvb2sgdGhlIHZpZXcgdGhhdCBlYWNoCj4gdGVybSB0aGF0IGlzIGRlZmlu ZWQgaXMgYW4gZXh0cmEgdGhpbmcgZm9yIHRoZSByZWFkZXIgdG8gdW5kZXJzdGFuZC4gSXQKPiBh bHNvIHJlcXVpcmVzIHNvbWUgbWFwcGluZyBiZXR3ZWVuIHRoZSBhZG1pc3NpYmxlIC9zdXBwb3J0 YWJsZSByYXRlcyBhbmQKPiBleGNlc3MvdGhyZXNob2xkIHJhdGVzLiBQZXJzb25hbGx5IEkgdGhp bmsgdGhpcyBsaWtlbHkgdG8gYmUgbW9yZQo+IGNvbmZ1c2luZy4gQnV0IGlmIHRoZXJlIGlzIGEg Y2xhbW91ciBpbiBzdXBwb3J0IG9mIHRoaXMgYmVpbmcgYWRkZWQsIEkKPiBjb3VsZCBhZGQgaXQu IChNaWNoYWVsLCBJIHRha2UgeW91ciB2b3RlIGluIGZhdm91ciBhcyByZWFkISkKPgo+IFBoaWwv Cj4KPiB7IAo+IHsgUmVnYXJkcywKPiB7IAo+IHsgICAgIE1pY2hhZWwKPiB7IAo+IHsgcGhpbGlw LmVhcmRsZXlAYnQuY29tIHdyb3RlOgo+IHsgPiB7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t Cj4geyA+IHsgRnJvbTogTWljaGFlbCBNZW50aCBbbWFpbHRvOm1lbnRoQGluZm9ybWF0aWsudW5p LXd1ZXJ6YnVyZy5kZV0KPiB7ID4geyBTZW50OiAwMiBPY3RvYmVyIDIwMDggMTM6MTUKPiB7ID4g eyBUbzogRWFyZGxleSxQTCxQaGlsaXAsQ1hSOSBSCj4geyA+IHsgQ2M6IHBjbkBpZXRmLm9yZwo+ IHsgPiB7IFN1YmplY3Q6IFJlOiBbUENOXSBTZWNvbmQgTGFzdCBDYWxsIGZvcgo+IGRyYWZ0LWll dGYtcGNuLWFyY2hpdGVjdHVyZQo+IHsgPiB7Cj4geyA+IHsgSGkgUGhpbCwKPiB7ID4gewo+IHsg PiB7IEkgc3RpbGwgaGF2ZSBjb25jZXJucyByZWdhcmRpbmcgdGhlIG5vbWVuY2xhdHVyZSBpbiB0 aGUgY3VycmVudAo+IHsgPiB2ZXJzaW9uCj4geyA+IHsgb2YgdGhlIGFyY2hpdGVjdHVyZSBkcmFm dC4KPiB7ID4gewo+IHsgPiB7IFRha2UgRmlndXJlIDEgb24gcGFnZSAxMC4gVGhlIHRlcm1zIFBD Ti10aHJlc2hvbGQtcmF0ZSBhbmQKPiB7ID4geyBQQ04tZXhjZXNzLXJhdGUgYXJlIG1lYW5pbmdm dWwgb25seSBpbiB0aGUgQ0wgZGVwbG95bWVudCBzY2VuYXJpbwo+IHsgPiB3aGVyZQo+IHsgPiB7 IHRoZSByZWZlcmVuY2UgcmF0ZSBmb3IgdGhlIHRocmVzaG9sZCBtYXJrZXIgaXMgdGhlCj4gUENO LXRocmVzaG9sZC1yYXRlCj4geyA+IHsgYW5kIHRoZSByZWZlcmVuY2UgcmF0ZSBmb3IgdGhlIGV4 Y2VzcyBtYXJrZXIgaXMgdGhlCj4gUENOLWV4Y2Vzcy1yYXRlLgo+IHsgPiB7IFRoaXMgaXMgZGlm ZmVyZW50IGZvciB0aGUgU00gZGVwbG95bWVudCBzY2VuYXJpbyB3aGVyZSB0aGUKPiByZWZlcmVu Y2UKPiB7ID4geyByYXRlIG9mIHRoZSBleGNlc3MgbWFya2VyIG11c3QgYmUgc2V0IHRvIHRoZSBQ Q04tdGhyZXNob2xkLXJhdGUuCj4geyA+Cj4geyA+IFRoaXMgaXMgbm90IGNvcnJlY3QuIFRoZSBy YXRlIG9mIHRoZSBleGNlc3MgbWFya2VyIGlzIHNldCB0byB0aGUKPiB7ID4gUENOLWV4Y2Vzcy1y YXRlLiBGaWcgMiBzaG93cywgZm9yIHRoZSBTaW5nbGUgTWFya2luZyBkZXBsb3ltZW50Cj4geyA+ IHNjZW5hcmlvLCBob3cgdGhpcyByZWxhdGVzIHRvIGFkbWlzc2lvbiAvdGVybWluYXRpb24KPiB7 ID4KPiB7ID4gQmVzdCB3aXNoZXMKPiB7ID4gUGhpbAo+IHsgPgo+IHsgPgo+IHsgPgo+IHsgPiBI b3cKPiB7ID4geyBmdW5ueSBpcyB0aGF0PyBObywgaXQncyBub3QgZnVubnkgLSB0aGlzIGlzIGNv bmZ1c2luZyBhbmQgbWFrZXMKPiB7ID4gZnVydGhlcgo+IHsgPiB7IGV4cGxhbmF0aW9ucyBjdW1i ZXJzb21lIGFuZCBwcm9uZSB0byBtaXN1bmRlcnN0YW5kaW5ncy4gSSB0aGluawo+IHRoYXQKPiB7 ID4geyB0aGlzIGlzIGEgYnVnIHRoYXQgc2hvdWxkIGJlIGNvcnJlY3RlZCBiZWZvcmUgcHVibGlj YXRpb24gYXMgdGhlc2UKPiB7ID4gdGVybXMKPiB7ID4geyBoZWxwIHRvIGRlc2NyaWJlIHRoZSBj b3JlIGlkZWEgb2YgUENOLiBVc2luZyB0aGUgdGVybSBhZG1pc3NpYmxlCj4gcmF0ZQo+IHsgPiB7 IGluc3RlYWQgb2YgUENOLXRocmVzaG9sZC1yYXRlIGFuZCBzdXBwb3J0YWJsZSByYXRlIGluc3Rl YWQgb2YKPiB7ID4geyBQQ04tZXhjZXNzLXJhdGUgZGVjb3VwbGVzIFBDTiByYXRlIHRocmVzaG9s ZHMgZnJvbSBtYXJraW5nCj4gbWVjaGFuaXNtcy4KPiB7ID4geyBUaGV5IGV4cHJlc3MgdGhlIG1l YW5pbmdzIG9mIHRoZXNlIHRocmVzaG9sZHMgd2l0aGluIHRoZSBQQ04KPiBjb25jZXB0Cj4geyA+ IHsgd2hpY2ggYXJlIGRlbm90ZWQgb24gdGhlIHJpZ2h0IHNpZGUgaW4gRmlndXJlIDEgYW5kIGFs bG93IGEgbXVjaAo+IHsgPiBjbGVhcmVyCj4geyA+IHsgcHJlc2VudGF0aW9uIG9mIHRoZSBjb25j ZXB0Lgo+IHsgPiB7Cj4geyA+IHsgSSBob3BlIG15IHJlYXNvbmluZyBpcyBjbGVhci4gVGhpcyBk b2N1bWVudCBpcyBub3QgYSB3b3JraW5nCj4gZG9jdW1lbnQKPiB7ID4geyBmb3IgYSBjbG9zZWQg Z3JvdXAgd2hlcmUgbm9tZW5jbGF0dXJlIGhhcyBubyBpbXBvcnRhbmNlIGFzIGxvbmcgYXMKPiB7 ID4geyBldmVyeWJvZHkga25vd3MgdGhhdCB3ZSBtZWFuIHBlYXJzIGlmIHdlIHNheSBhcHBsZXMg LSBpdCdzIGEKPiByZWZlcmVuY2UKPiB7ID4geyBmb3Igb3RoZXJzIHRvIGxlYXJuIGFib3V0IFBD TiBhbmQsIHRoZXJlZm9yZSwgdGVjaG5pY2FsIHRlcm1zCj4gc2hvdWxkCj4geyA+IGJlCj4geyA+ IHsgcHJlY2lzZSBhbmQgZWFzeSB0byByZW1lbWJlci4KPiB7ID4gewo+IHsgPiB7IFJlZ2FyZHMs Cj4geyA+IHsKPiB7ID4geyAgICAgTWljaGFlbAo+IHsgPiB7Cj4geyA+IHsgcGhpbGlwLmVhcmRs ZXlAYnQuY29tIHdyb3RlOgo+IHsgPiB7ID4gewo+IHsgPiB7ID4geyBUaGVyZSBhcmUgc29tZSBr bm93biBlZGl0cyB0aGF0IGhhdmUgdG8gYmUgbWFkZSBiZWZvcmUgd2UgY2FuCj4geyA+IHN1Ym1p dAo+IHsgPiB7ID4gdG8KPiB7ID4geyA+IHsgdGhlCj4geyA+IHsgPiB7IElFU0c6Cj4geyA+IHsg PiB7Cj4geyA+IHsgPiB7IC0gQ29ycmVjdCByZWZlcmVuY2VzIHRvIEludGVybmV0IERyYWZ0cyB0 byBpbmRpY2F0ZSAiV29yayBpbgo+IHsgPiBQcm9ncmVzcyIKPiB7ID4geyA+IHsgLSBGaXggZm9y bWF0dGluZyBlcnJvcnMgZGV0ZWN0ZWQgYnkgSUQtbml0cwo+IHsgPiB7ID4KPiB7ID4geyA+IEkg anVzdCBmaXhlZCB0aGVzZSAoSSB0aGluaykgaW4KPiB7ID4geyA+Cj4geyA+Cj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wY24tYXJjaGl0ZWN0dXJlLTA3 LnR4dAo+IHsgPiB7ID4gVGhlIG9ubHkgY2hhbmdlcyBmcm9tIDA2IHRvIC0wNyBhcmUgdG8gcmUt Zm9ybWF0IHNvbWUgb2YgdGhlCj4geyA+IHJlZmVyZW5jZXMKPiB7ID4geyA+IGluIG9yZGVyIHRv IGZpeCB0aGUgYWJvdmUgMiBwb2ludHMuCj4geyA+IHsgPgo+IHsgPiB7ID4gUGhpbAo+IHsgPiB7 ID4KPiB7ID4geyA+IFBzIHRvIHNlZSB0aGUgLTA1IHRvIC0wNiBkaWZmczoKPiB7ID4geyA+Cj4g eyA+Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3Bjbi9kcmFmdC1pZXRmLXBjbi1hcmNoaXRl Y3R1cmUvZHJhZnQtaWV0Zi1wY24tCj4geyA+IHsgPiBhcmNoaXRlY3R1cmUtMDYtZnJvbS0wNS5k aWZmLmh0bWwKPiB7ID4geyA+IG9yIGZyb20KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcGNu L2RyYWZ0LWlldGYtcGNuLWFyY2hpdGVjdHVyZS8KPiB7ID4geyA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4geyA+IHsgPiBQQ04gbWFpbGluZyBsaXN0 Cj4geyA+IHsgPiBQQ05AaWV0Zi5vcmcKPiB7ID4geyA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGNuCj4geyA+IHsgPgo+IHsgPiB7Cj4geyA+IHsgLS0KPiB7ID4geyBE ci4gTWljaGFlbCBNZW50aCwgQXNzaXN0YW50IFByb2Zlc3Nvcgo+IHsgPiB7IFVuaXZlcnNpdHkg b2YgV3VlcnpidXJnLCBJbnN0aXR1dGUgb2YgQ29tcHV0ZXIgU2NpZW5jZQo+IHsgPiB7IEFtIEh1 YmxhbmQsIEQtOTcwNzQgV3VlcnpidXJnLCBHZXJtYW55LCByb29tIEIyMDYKPiB7ID4geyBwaG9u ZTogKCs0OSktOTMxLzg4OC02NjQ0LCBmYXg6ICgrNDkpLTkzMS84ODgtNjYzMgo+IHsgPiB7IG1h aWx0bzptZW50aEBpbmZvcm1hdGlrLnVuaS13dWVyemJ1cmcuZGUKPiB7ID4geyBodHRwOi8vd3d3 My5pbmZvcm1hdGlrLnVuaS13dWVyemJ1cmcuZGUvcmVzZWFyY2gvbmduCj4geyA+Cj4geyAKPiB7 IC0tCj4geyBEci4gTWljaGFlbCBNZW50aCwgQXNzaXN0YW50IFByb2Zlc3Nvcgo+IHsgVW5pdmVy c2l0eSBvZiBXdWVyemJ1cmcsIEluc3RpdHV0ZSBvZiBDb21wdXRlciBTY2llbmNlCj4geyBBbSBI dWJsYW5kLCBELTk3MDc0IFd1ZXJ6YnVyZywgR2VybWFueSwgcm9vbSBCMjA2Cj4geyBwaG9uZTog KCs0OSktOTMxLzg4OC02NjQ0LCBmYXg6ICgrNDkpLTkzMS84ODgtNjYzMgo+IHsgbWFpbHRvOm1l bnRoQGluZm9ybWF0aWsudW5pLXd1ZXJ6YnVyZy5kZQo+IHsgaHR0cDovL3d3dzMuaW5mb3JtYXRp ay51bmktd3VlcnpidXJnLmRlL3Jlc2VhcmNoL25nbgo+Cj4KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFBDTiBtYWlsaW5nIGxpc3QKPiBQQ05AaWV0 Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bjbgo+ICAgCgot LSAKRHIuIE1pY2hhZWwgTWVudGgsIEFzc2lzdGFudCBQcm9mZXNzb3IKVW5pdmVyc2l0eSBvZiBX dWVyemJ1cmcsIEluc3RpdHV0ZSBvZiBDb21wdXRlciBTY2llbmNlCkFtIEh1YmxhbmQsIEQtOTcw NzQgV3VlcnpidXJnLCBHZXJtYW55LCByb29tIEIyMDYKcGhvbmU6ICgrNDkpLTkzMS84ODgtNjY0 NCwgZmF4OiAoKzQ5KS05MzEvODg4LTY2MzIKbWFpbHRvOm1lbnRoQGluZm9ybWF0aWsudW5pLXd1 ZXJ6YnVyZy5kZQpodHRwOi8vd3d3My5pbmZvcm1hdGlrLnVuaS13dWVyemJ1cmcuZGUvcmVzZWFy Y2gvbmduCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpQ Q04gbWFpbGluZyBsaXN0ClBDTkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Bjbgo= From pcn-bounces@ietf.org Fri Oct 3 03:34:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B367F3A6B64; Fri, 3 Oct 2008 03:34:44 -0700 (PDT) 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 0037A3A6B64 for ; Fri, 3 Oct 2008 03:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNIfLsBzgdJU for ; Fri, 3 Oct 2008 03:34:43 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 10A183A6ABF for ; Fri, 3 Oct 2008 03:34:43 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8500J56S2CUV@szxga01-in.huawei.com> for pcn@ietf.org; Fri, 03 Oct 2008 18:35:00 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8500542S2CS5@szxga01-in.huawei.com> for pcn@ietf.org; Fri, 03 Oct 2008 18:35:00 +0800 (CST) Received: from [192.168.0.103] ([116.24.119.63]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K85009UQS2B14@szxml02-in.huawei.com>; Fri, 03 Oct 2008 18:35:00 +0800 (CST) Date: Fri, 03 Oct 2008 18:34:59 +0800 From: Tina TSOU In-reply-to: <757c4a1079b168f8832dcbb3b4257520@petri-meat.com> To: slblake@petri-meat.com Message-id: <32C75A06-3469-4F70-9E52-C72ECB6A9847@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.926) References: <757c4a1079b168f8832dcbb3b4257520@petri-meat.com> Cc: pcn@ietf.org Subject: Re: [PCN] Updated working group milestones X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050843044==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============0050843044== Content-type: multipart/alternative; boundary="Boundary_(ID_xwiyh9dvstf8sPnvE91f8A)" --Boundary_(ID_xwiyh9dvstf8sPnvE91f8A) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi Steve, Should " (pre-congestion)" in "All PCN mechanisms, including transport and encoding of (pre-congestion) information, are required to cleanly integrate with existing architectures and protocols such as DiffServ and ECN. " be "(pre-) congestion"? B. R. Tina On Oct 2, 2008, at 10:57 PM, slblake@petri-meat.com wrote: > FYI > > The PCN working group milestones have been updated. See: > > http://www.ietf.org/html.charters/pcn-charter.html > > > Regards, > > // Steve > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn --Boundary_(ID_xwiyh9dvstf8sPnvE91f8A) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi Steve,
Should " (pre-congestion)" in "All PCN mechanisms, including transport and encoding 
of (pre-congestion) information, are required to cleanly integrate 
with existing architectures and protocols such as DiffServ and ECN. " be "(pre-) congestion"?

B. R.
Tina



On Oct 2, 2008, at 10:57 PM, slblake@petri-meat.com wrote:

FYI

The PCN working group milestones have been updated.  See:

 http://www.ietf.org/html.charters/pcn-charter.html


Regards,
// ____________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn

--Boundary_(ID_xwiyh9dvstf8sPnvE91f8A)-- --===============0050843044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0050843044==-- From pcn-bounces@ietf.org Fri Oct 3 04:11:16 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B743A68C0; Fri, 3 Oct 2008 04:11:16 -0700 (PDT) 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 45D013A68C0 for ; Fri, 3 Oct 2008 04:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9OTheYTK30k for ; Fri, 3 Oct 2008 04:11:14 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E4C4C3A6778 for ; Fri, 3 Oct 2008 04:11:13 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8500ANRTQF5Y@szxga03-in.huawei.com> for pcn@ietf.org; Fri, 03 Oct 2008 19:11:03 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K85007LTTQF7B@szxga03-in.huawei.com> for pcn@ietf.org; Fri, 03 Oct 2008 19:11:03 +0800 (CST) Received: from [192.168.0.103] ([116.24.119.63]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K85009SITQE14@szxml02-in.huawei.com>; Fri, 03 Oct 2008 19:11:03 +0800 (CST) Date: Fri, 03 Oct 2008 19:11:02 +0800 From: Tina TSOU In-reply-to: <4A916DBC72536E419A0BD955EDECEDEC03DAA328@E03MVB1-UKBR.domain1.systemhost.net> To: philip.eardley@bt.com Message-id: <531DE44C-A82E-42D2-BE48-9DF73796F4E2@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.926) References: <4A916DBC72536E419A0BD955EDECEDEC03DAA328@E03MVB1-UKBR.domain1.systemhost.net> Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, By what kind of policy the flow termination is performed? Which flow belonging which user will be terminated? Is it implementation dependent? B. R. Tina On Oct 2, 2008, at 10:29 PM, philip.eardley@bt.com wrote: > Hi, > This is the update to the marking behaviour draft, which (I think) > includes all the discussion we had on the list and in Dublin about the > previous version (draft-eardley-pan-marking-behaviour-01) > > Summary of changes: > > o Removed material concerning per domain behaviour and PCN- > boundary- > node operation (temporarily archived to Appendix C) > it was agreed that this draft should be just about the 'per-hop' > behaviour. > > We need a draft about the per-domain behaviour. This will be very > short, > eg saying that all nodes in the PCN-domain have to be configured to do > the same type of marking, the same choice about encoding states, do > policing at the ingress-node etc. ietf-pcn-baseline-encoding > Appendix B > also indicates some things that the PCN-boundary-nodes need to do. > I (& Toby) don't have time to write this per-domain behaviour draft > (hoping for volunteer(s)!) > > There's also the Info edge behaviour draft or drafts. Some of the > material in Appendix C might be useful for that. > > > o Removed mention of downgrading as an option for per-hop traffic > conditioning. In fact, downgrading is no longer allowed > because S > 2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a > non PCN-packet". > > o Traffic conditioning is now a MAY. Since in general flow > termination (not traffic conditioning) is PCN's method for > handling problems of too much traffic. > I think I got the conclusion on this right, but would appreciate > people > checking. I think a MAY captures best our conclusion (rather than a > SHOULD or not talking about it all) > > o Metered-packets: competing-non-PCN-packets now MAY be metered. > Since it is recommended that the operator doesn't allow any > competing-non-PCN-traffic, and (if there is) there are > potentially > other ways of coping. > This was the discussion with Christian recently about Section 6.5 of > the > architecture draft. > In the previous draft, it was a MUST to meter these > competing-non-PCN-packets. This seems onerous when we also recommend > that there is no such traffic. > > o No changes (outside traffic conditioning & metering of competing- > non-PCN-traffic) to the Normative sections of the draft. > > o Appendix B.1 added about competing-non-PCN-traffic. Recommended > that there is no such traffic, but guidance given if there is. > > > Sorry this has taken me longer than expected to get out. > > I'll do another rev before Minneapolis. I believe (or at least hope!) > that it'll then be ready for last call/ > > Best wishes > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > { Internet-Drafts@ietf.org > { Sent: 02 October 2008 13:45 > { To: i-d-announce@ietf.org > { Cc: pcn@ietf.org > { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.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-00.txt > { Pages : 22 > { Date : 2008-10-02 > { > { 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 > first > { configured rate. Excess traffic marking marks a proportion of PCN- > { packets, such that the amount marked equals the traffic rate in > { excess of a second configured rate.Requirements Language > { > { The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > { "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > { document are to be interpreted as described in RFC 2119 [RFC2119]. > { > { A URL for this Internet-Draft is: > { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking- > behaviour- > { 00.txt > { > { Internet-Drafts are also available by anonymous FTP at: > { ftp://ftp.ietf.org/internet-drafts/ > { > { Below is the data which will enable a MIME compliant mail reader > { implementation to automatically retrieve the ASCII version of the > { Internet-Draft. > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 7 00:02:54 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D57E3A6928; Tue, 7 Oct 2008 00:02:54 -0700 (PDT) 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 D99EF3A6928 for ; Tue, 7 Oct 2008 00:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, 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 saWuWNLpr9ii for ; Tue, 7 Oct 2008 00:02:52 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 884C33A6800 for ; Tue, 7 Oct 2008 00:02:51 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Tue, 7 Oct 2008 09:03:27 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 09:03:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 09:03:26 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01D6D9FF@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <864b1db62edbb6688022b71b9421de85@petri-meat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture thread-index: AckiU1ucz/vZWTPjQwm1WoMfgblmVgF9IAsQ References: <864b1db62edbb6688022b71b9421de85@petri-meat.com> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 07 Oct 2008 07:03:26.0878 (UTC) FILETIME=[CBCEABE0:01C9284A] Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steve, I support pcn-architecture-06 as is. My personal take on the terminology is that it is not wrong as is. Apart from that, having a stable terminology increases readbility of documents significantly. If it comes to the "rate and threshold terminology", PCN architecture changed terminology almost with every second draft in the past (I don't blame Phil for this). I'm not really interested in having to read contemporary architecture versions to understand any line in contemporary drafts and presentations of the PCN WG. It is further not nice to draft a document or a presentation and then change wording all the time as a new architecture version is published. I also was unhappy about Joe Babiarz presentation in Dublin, not because of the contents, but because of the terminology not folllowing the architecture draft. The presentation was hard to understand on the spot then and I need to spend extra time to learn individual author to WG terminology translations. As every author can claim the right to have his preferred terminology and my time is limited, I'll spend less time on reading drafts which are demanding already because of the applied individual terminology. Others having little time may do so too. I don't see the WG benefitting from this endless terminology debate and would like to come to an end now. Regards, Rudiger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of slblake@petri-meat.com Sent: Monday, September 29, 2008 6:49 PM To: pcn@ietf.org Subject: [PCN] Second Last Call for draft-ietf-pcn-architecture We will be running a brief (~1 week) last call on draft-ietf-pcn-architecture-06. This last call will end on Tuesday October 7. Please send comments ASAP. Diffs between -06 and -05 can be viewed at: http://tools.ietf.org/rfcdiff Use the following URLs to reference -05 and -06: http://tools.ietf.org/id/draft-ietf-pcn-architecture-05.txt http://tools.ietf.org/id/draft-ietf-pcn-architecture-06.txt There are some known edits that have to be made before we can submit to the IESG: - Correct references to Internet Drafts to indicate "Work in Progress" - Fix formatting errors detected by ID-nits Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 13 08:33:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BA23A69AF; Mon, 13 Oct 2008 08:33:48 -0700 (PDT) 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 66E743A68AE for ; Mon, 13 Oct 2008 08:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.061, 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 AMoPi1lhrFzv for ; Mon, 13 Oct 2008 08:33:46 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id DBB763A69AF for ; Mon, 13 Oct 2008 08:33:45 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 16:34:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 16:34:01 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA33F@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <531DE44C-A82E-42D2-BE48-9DF73796F4E2@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt Thread-Index: AcklSLy2zGnyTKOcThGM8pP1eMCekwH/9Mgg From: To: X-OriginalArrivalTime: 13 Oct 2008 15:34:02.0209 (UTC) FILETIME=[1E5DB510:01C92D49] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Tina I think this is down to the operator of the PCN-domain to decide (so I guess it is "implementation dependent"). Anyway, it doesn't seem appropriate to standardise such policy decisions. Thanks phil { -----Original Message----- { From: Tina TSOU [mailto:tena@huawei.com] { Sent: 03 October 2008 12:11 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt { { Hi, { By what kind of policy the flow termination is performed? Which flow { belonging which user will be terminated? Is it implementation dependent? { { { B. R. { Tina { { { { On Oct 2, 2008, at 10:29 PM, philip.eardley@bt.com wrote: { { > Hi, { > This is the update to the marking behaviour draft, which (I think) { > includes all the discussion we had on the list and in Dublin about the { > previous version (draft-eardley-pan-marking-behaviour-01) { > { > Summary of changes: { > { > o Removed material concerning per domain behaviour and PCN- { > boundary- { > node operation (temporarily archived to Appendix C) { > it was agreed that this draft should be just about the 'per-hop' { > behaviour. { > { > We need a draft about the per-domain behaviour. This will be very { > short, { > eg saying that all nodes in the PCN-domain have to be configured to do { > the same type of marking, the same choice about encoding states, do { > policing at the ingress-node etc. ietf-pcn-baseline-encoding { > Appendix B { > also indicates some things that the PCN-boundary-nodes need to do. { > I (& Toby) don't have time to write this per-domain behaviour draft { > (hoping for volunteer(s)!) { > { > There's also the Info edge behaviour draft or drafts. Some of the { > material in Appendix C might be useful for that. { > { > { > o Removed mention of downgrading as an option for per-hop traffic { > conditioning. In fact, downgrading is no longer allowed { > because S { > 2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a { > non PCN-packet". { > { > o Traffic conditioning is now a MAY. Since in general flow { > termination (not traffic conditioning) is PCN's method for { > handling problems of too much traffic. { > I think I got the conclusion on this right, but would appreciate { > people { > checking. I think a MAY captures best our conclusion (rather than a { > SHOULD or not talking about it all) { > { > o Metered-packets: competing-non-PCN-packets now MAY be metered. { > Since it is recommended that the operator doesn't allow any { > competing-non-PCN-traffic, and (if there is) there are { > potentially { > other ways of coping. { > This was the discussion with Christian recently about Section 6.5 of { > the { > architecture draft. { > In the previous draft, it was a MUST to meter these { > competing-non-PCN-packets. This seems onerous when we also recommend { > that there is no such traffic. { > { > o No changes (outside traffic conditioning & metering of competing- { > non-PCN-traffic) to the Normative sections of the draft. { > { > o Appendix B.1 added about competing-non-PCN-traffic. Recommended { > that there is no such traffic, but guidance given if there is. { > { > { > Sorry this has taken me longer than expected to get out. { > { > I'll do another rev before Minneapolis. I believe (or at least hope!) { > that it'll then be ready for last call/ { > { > Best wishes { > phil { > { > { -----Original Message----- { > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf { > Of { > { Internet-Drafts@ietf.org { > { Sent: 02 October 2008 13:45 { > { To: i-d-announce@ietf.org { > { Cc: pcn@ietf.org { > { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.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-00.txt { > { Pages : 22 { > { Date : 2008-10-02 { > { { > { 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 { > first { > { configured rate. Excess traffic marking marks a proportion of PCN- { > { packets, such that the amount marked equals the traffic rate in { > { excess of a second configured rate.Requirements Language { > { { > { The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", { > { "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this { > { document are to be interpreted as described in RFC 2119 [RFC2119]. { > { { > { A URL for this Internet-Draft is: { > { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking- { > behaviour- { > { 00.txt { > { { > { Internet-Drafts are also available by anonymous FTP at: { > { ftp://ftp.ietf.org/internet-drafts/ { > { { > { Below is the data which will enable a MIME compliant mail reader { > { implementation to automatically retrieve the ASCII version of the { > { Internet-Draft. { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 14 03:41:25 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798013A6A8D; Tue, 14 Oct 2008 03:41:25 -0700 (PDT) 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 AEBA23A6A8D for ; Tue, 14 Oct 2008 03:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_21=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 qg9qX5qDNhS4 for ; Tue, 14 Oct 2008 03:41:23 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 500523A6A50 for ; Tue, 14 Oct 2008 03:41:23 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 11:41:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 11:41:38 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA351@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt Thread-Index: AckjFfhuRPHaWPOHTWeUoJxAvcV1xABNwY9AAAwn7NACWk2M8A== From: To: , , X-OriginalArrivalTime: 14 Oct 2008 10:41:39.0327 (UTC) FILETIME=[706818F0:01C92DE9] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-baseline-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Toby Some comments 1. I think there should be a section about how the baseline encoding restricts the EXPTAL encoding extensions. I think these restrictions are the following MUSTs: - 1 dscp or two defined as a pair - 00 is not-PCN - 11 is (some kind of) PCN-marking - 11 mustn't be changed by interior node. Basically the restrictions explain what we mean by "extension to baseline" rather than a whole new encoding. They hopefully mean that migration requirements are eased, ie if a pcn-domain is using the baseline and upgrades to extension, it isn't too disastrous if some nodes are still using baseline. I think this is a reasonable requirement. 2. it might be nice to have a picture of encoding transitions in (or near) Appendix B.1. just to make it graphic. Some people I think have asked for a transitions pic, and it makes more sense to me to include this in the encoding draft than in the marking draft. Drawing a transitions pic for the baseline encoding should be easy; maybe could include one for extensions as well, although this is slightly trickier. I think the pics could be informative, and the text normative if necessary 3. other suggestions:- Intro: Changes section should refer to WG -00 Terminology PCN-capable or PCN-enabled? 4.1 Refer to the codepoint as 11 (it's only CE in 3168) Add some rationale for NM =10 rather than 01 (or say, "it makes no odds, but a choice has to be made") 8. Conclusions mention about end-to-end ECN support. This should appear earlier eg S5 Appendixes: At start of each say whether normative or informative App B: Rephrase as active tense (A PCN-interior-node MUST...) The PCN-egress one - re-phrase as a "MUST unless.." (rather than a "SHOULD.. only exception) B.1: Downgrading is no longer mentioned in marking behaviour draft A few other typos /suggestions I'll give to you on paper Thanks Phil/ { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { toby.moncaster@bt.com { Sent: 02 October 2008 12:00 { To: ingemar.s.johansson@ericsson.com; pcn@ietf.org { Subject: Re: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt { { Hi Ingemar, { { Thanks for the comments. I will incorporate them in the next version { which will hopefully be published shortly. { { Regarding Appendix C bullets 3 & 4. These are trying to do two things - { specify the action needed if you want to mark a packet (set it to PM) { and clarify what happens if an unexpected codepoint is seen (treat it as { NM). This second bit is perhaps not needed as it is reasonable to expect { operators to ensure they don't misconfigured networks... { { Toby { { -----Original Message----- { From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] { Sent: 02 October 2008 06:32 { To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org { Subject: RE: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt { { Hi { { Some comments on the draft: { Typos: { Section 3: thatn -> than { Appendix C: shoudl -> should (2 occurences) { { Other: { Section 4.1: "increasingly short supply", could be a lack of { understanding of the english language from my side. Even though I { (believe I) understand the phrase I suspect that it may be confusing. { Anyway please dismiss this protest if you like. { { Appendix C: Bullets 3 and 4: I am not quite sure that I get the { difference between 3 and 4 when I read the text alone: I guess that in { 3) the decision (admission control and termination) is done (in { PCN-ingress/egress-nodes) based on the ratio between NM and PM while in { 4) a dedicated PCN codepoint (AM or TM) is set in the PCN-interior-nodes { based on load, quueue length et.c. Is this interpretation correct ? { { Regards { Ingemar { { { > -----Original Message----- { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { > Behalf Of Internet-Drafts@ietf.org { > Sent: den 30 september 2008 18:00 { > To: i-d-announce@ietf.org { > Cc: pcn@ietf.org { > Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.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 : Baseline Encoding and Transport of { > Pre-Congestion Information { > Author(s) : T. Moncaster, et al. { > Filename : draft-ietf-pcn-baseline-encoding-00.txt { > Pages : 12 { > Date : 2008-09-30 { > { > Pre-congestion notification (PCN) provides information to { > support admission control and flow termination in order to { > protect the Quality of Service of inelastic flows. It does { > this by marking packets when traffic load on a link is { > approaching or has exceeded a threshold below the physical { > link rate. This document specifies how such marks are to be { > encoded into the IP header. The baseline encoding described { > here provides for only two PCN encoding states. { > It is designed to be easily extensible to provide more { > encoding states but such schemes will be described in other documents. { > { > A URL for this Internet-Draft is: { > http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-en { > coding-00.txt { > { > Internet-Drafts are also available by anonymous FTP at: { > ftp://ftp.ietf.org/internet-drafts/ { > { > Below is the data which will enable a MIME compliant mail { > reader implementation to automatically retrieve the ASCII { > version of the Internet-Draft. { > { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 14 05:35:31 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A568D3A6B14; Tue, 14 Oct 2008 05:35:31 -0700 (PDT) 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 8D2A93A6B14 for ; Tue, 14 Oct 2008 05:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 QqYchRxuVDaw for ; Tue, 14 Oct 2008 05:35:29 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id E7C363A6849 for ; Tue, 14 Oct 2008 05:35:28 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Kpj7r-00005s-Jo for pcn@ietf.org; Tue, 14 Oct 2008 08:35:47 -0400 From: Steven Blake To: pcn@ietf.org In-Reply-To: <864b1db62edbb6688022b71b9421de85@petri-meat.com> References: <864b1db62edbb6688022b71b9421de85@petri-meat.com> Date: Tue, 14 Oct 2008 08:35:48 -0400 Message-Id: <1223987748.10191.13.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org By my reading of the last call comments, the only remaining issue where we have some disagreement is surrounding the terminology proposed by Michael Menth. Does everyone agree that this is the last remaining issue? If so, could we close on that this week? Please send your commments to the list ASAP. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 14 05:38:37 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EEB3A683C; Tue, 14 Oct 2008 05:38:37 -0700 (PDT) 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 6194F3A683C for ; Tue, 14 Oct 2008 05:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 oUV7DSBowVoO for ; Tue, 14 Oct 2008 05:38:33 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 518B63A6826 for ; Tue, 14 Oct 2008 05:38:33 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjAn-0000wj-QU for pcn@ietf.org; Tue, 14 Oct 2008 08:38:49 -0400 From: Steven Blake To: pcn In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA328@E03MVB1-UKBR.domain1.systemhost.net> References: <4A916DBC72536E419A0BD955EDECEDEC03DAA328@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 14 Oct 2008 08:38:50 -0400 Message-Id: <1223987930.10191.16.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org We want to advance this document quickly. Please come to Minneapolis with comments prepared. Or better yet, send them to the list ASAP. On Thu, 2008-10-02 at 15:29 +0100, philip.eardley@bt.com wrote: > Hi, > This is the update to the marking behaviour draft, which (I think) > includes all the discussion we had on the list and in Dublin about the > previous version (draft-eardley-pan-marking-behaviour-01) > > Summary of changes: > > o Removed material concerning per domain behaviour and PCN-boundary- > node operation (temporarily archived to Appendix C) > it was agreed that this draft should be just about the 'per-hop' > behaviour. > > We need a draft about the per-domain behaviour. This will be very short, > eg saying that all nodes in the PCN-domain have to be configured to do > the same type of marking, the same choice about encoding states, do > policing at the ingress-node etc. ietf-pcn-baseline-encoding Appendix B > also indicates some things that the PCN-boundary-nodes need to do. > I (& Toby) don't have time to write this per-domain behaviour draft > (hoping for volunteer(s)!) > > There's also the Info edge behaviour draft or drafts. Some of the > material in Appendix C might be useful for that. > > > o Removed mention of downgrading as an option for per-hop traffic > conditioning. In fact, downgrading is no longer allowed because S > 2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a > non PCN-packet". > > o Traffic conditioning is now a MAY. Since in general flow > termination (not traffic conditioning) is PCN's method for > handling problems of too much traffic. > I think I got the conclusion on this right, but would appreciate people > checking. I think a MAY captures best our conclusion (rather than a > SHOULD or not talking about it all) > > o Metered-packets: competing-non-PCN-packets now MAY be metered. > Since it is recommended that the operator doesn't allow any > competing-non-PCN-traffic, and (if there is) there are potentially > other ways of coping. > This was the discussion with Christian recently about Section 6.5 of the > architecture draft. > In the previous draft, it was a MUST to meter these > competing-non-PCN-packets. This seems onerous when we also recommend > that there is no such traffic. > > o No changes (outside traffic conditioning & metering of competing- > non-PCN-traffic) to the Normative sections of the draft. > > o Appendix B.1 added about competing-non-PCN-traffic. Recommended > that there is no such traffic, but guidance given if there is. > > > Sorry this has taken me longer than expected to get out. > > I'll do another rev before Minneapolis. I believe (or at least hope!) > that it'll then be ready for last call/ > > Best wishes > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { Internet-Drafts@ietf.org > { Sent: 02 October 2008 13:45 > { To: i-d-announce@ietf.org > { Cc: pcn@ietf.org > { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.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-00.txt > { Pages : 22 > { Date : 2008-10-02 > { > { 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 first > { configured rate. Excess traffic marking marks a proportion of PCN- > { packets, such that the amount marked equals the traffic rate in > { excess of a second configured rate.Requirements Language > { > { The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > { "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > { document are to be interpreted as described in RFC 2119 [RFC2119]. > { > { A URL for this Internet-Draft is: > { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour- > { 00.txt > { > { Internet-Drafts are also available by anonymous FTP at: > { ftp://ftp.ietf.org/internet-drafts/ > { > { Below is the data which will enable a MIME compliant mail reader > { implementation to automatically retrieve the ASCII version of the > { Internet-Draft. > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 14 05:40:27 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7360628C1A2; Tue, 14 Oct 2008 05:40:27 -0700 (PDT) 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 7670528C0CF for ; Tue, 14 Oct 2008 05:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL5nG9bBcE6S for ; Tue, 14 Oct 2008 05:40:25 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 730F23A6826 for ; Tue, 14 Oct 2008 05:40:25 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpjCX-0001Bt-5A for pcn@ietf.org; Tue, 14 Oct 2008 08:40:37 -0400 From: Steven Blake To: pcn In-Reply-To: References: Date: Tue, 14 Oct 2008 08:40:37 -0400 Message-Id: <1223988037.10191.19.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: Re: [PCN] FW: New Version Notification for draft-ietf-pcn-baseline-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org We want to advance this document quickly also. My hope is that we can last call both this and draft-ietf-pcn-marking-behavior right after the Minneapolis meeting. Please send comments to the list ASAP. On Tue, 2008-09-30 at 17:01 +0100, toby.moncaster@bt.com wrote: > Here is the 00 version of the WG document. Apologies - I just realised I didn't include the change of filename as one of the changes from earlier versions... I will post a revision correcting this very soon along with any minor corrections that come up in the meantime... > > Please could people take some time to read this and get any comments to me quickly. My hope is to get this to a state where it can go to WGLC by the next IETF meeting... > > Toby > > ____________________________________________________________________ > Toby Moncaster, Networks Research Centre, BT > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 30 September 2008 16:57 > 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-00 > > > A new version of I-D, draft-ietf-pcn-baseline-encoding-00.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. > > Filename: draft-ietf-pcn-baseline-encoding > Revision: 00 > Title: Baseline Encoding and Transport of Pre-Congestion Information > Creation_date: 2008-09-30 > WG ID: pcn > Number_of_pages: 12 > > Abstract: > Pre-congestion notification (PCN) provides information to support > admission control and flow termination in order to protect the > Quality of Service of inelastic flows. It does this by marking > packets when traffic load on a link is approaching or has exceeded a > threshold below the physical link rate. This document specifies how > such marks are to be encoded into the IP header. The baseline > encoding described here provides for only two PCN encoding states. > It is designed to be easily extensible to provide more encoding > states but such schemes will be described in other documents. > > > > The IETF Secretariat. > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 14 05:50:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A5328C1B1; Tue, 14 Oct 2008 05:50:00 -0700 (PDT) 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 9F49828C1AE for ; Tue, 14 Oct 2008 05:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 VexBy-fGtpHd for ; Tue, 14 Oct 2008 05:49:58 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 92FBB3A696A for ; Tue, 14 Oct 2008 05:49:58 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 13:49:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 13:49:07 +0100 Message-ID: In-Reply-To: <1223988037.10191.19.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notificationfor draft-ietf-pcn-baseline-encoding-00 Thread-Index: Ackt+kWBjHnhOdFGQN2I3fngr9nWOAAAOE/w References: <1223988037.10191.19.camel@tachyon> From: To: , X-OriginalArrivalTime: 14 Oct 2008 12:49:14.0590 (UTC) FILETIME=[434C87E0:01C92DFB] Subject: Re: [PCN] FW: New Version Notificationfor draft-ietf-pcn-baseline-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org A new version of this addressing the comments that have been raised on and off list will be published later today... Toby -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steven Blake Sent: 14 October 2008 13:41 To: pcn Subject: Re: [PCN] FW: New Version Notificationfor draft-ietf-pcn-baseline-encoding-00 We want to advance this document quickly also. My hope is that we can last call both this and draft-ietf-pcn-marking-behavior right after the Minneapolis meeting. Please send comments to the list ASAP. On Tue, 2008-09-30 at 17:01 +0100, toby.moncaster@bt.com wrote: > Here is the 00 version of the WG document. Apologies - I just realised I didn't include the change of filename as one of the changes from earlier versions... I will post a revision correcting this very soon along with any minor corrections that come up in the meantime... > > Please could people take some time to read this and get any comments to me quickly. My hope is to get this to a state where it can go to WGLC by the next IETF meeting... > > Toby > > ____________________________________________________________________ > Toby Moncaster, Networks Research Centre, BT > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 30 September 2008 16:57 > 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-00 > > > A new version of I-D, draft-ietf-pcn-baseline-encoding-00.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. > > Filename: draft-ietf-pcn-baseline-encoding > Revision: 00 > Title: Baseline Encoding and Transport of Pre-Congestion Information > Creation_date: 2008-09-30 > WG ID: pcn > Number_of_pages: 12 > > Abstract: > Pre-congestion notification (PCN) provides information to support > admission control and flow termination in order to protect the > Quality of Service of inelastic flows. It does this by marking > packets when traffic load on a link is approaching or has exceeded a > threshold below the physical link rate. This document specifies how > such marks are to be encoded into the IP header. The baseline > encoding described here provides for only two PCN encoding states. > It is designed to be easily extensible to provide more encoding > states but such schemes will be described in other documents. > > > > The IETF Secretariat. > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 14 07:45:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B173A6C19; Tue, 14 Oct 2008 07:45:02 -0700 (PDT) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 758303A6C0A; Tue, 14 Oct 2008 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: <20081014144501.758303A6C0A@core3.amsl.com> Date: Tue, 14 Oct 2008 07:45:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-01.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --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-01.txt Pages : 12 Date : 2008-10-14 Pre-congestion notification (PCN) provides information to support admission control and flow termination in order to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for only two PCN encoding states. It is designed to be easily extended to provide more encoding states but such schemes will be described in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-01.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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-14073529.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --NextPart-- From pcn-bounces@ietf.org Tue Oct 14 07:52:45 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021413A6B2F; Tue, 14 Oct 2008 07:52:45 -0700 (PDT) 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 D027E3A6B2F for ; Tue, 14 Oct 2008 07:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 xqGtvXiX6Aav for ; Tue, 14 Oct 2008 07:52:40 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B9BE53A659A for ; Tue, 14 Oct 2008 07:52:39 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 15:52:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 15:52:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: New Version Notification for draft-ietf-pcn-baseline-encoding-01 Thread-Index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jg From: To: X-OriginalArrivalTime: 14 Oct 2008 14:52:32.0901 (UTC) FILETIME=[7D093350:01C92E0C] Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org As promised I have uploaded a new version. I am aware there are a handful of typos and spelling mistakes that I noticed just after uploading. I will correct these in the next version. I am now pretty happy with almost all the text. The key section for the WG to note is Appendix B where I have put in a couple of questions that I would welcome input on. The first of these is where to put the text (now set out as a table) about valid and invalid transitions at PCN nodes? Should this be part of the baseline encoding or should it be split between a new edge node behaviour document and Phil's marking behaviour. The second question relates to how to best handle the unexpected presence of the EXP codepoint. There is a potential for this to happen during any partial deployment of an experimental encoding extension scheme. Whilst it would be best for an operator to ensure all nodes run the same encoding there is a chance this might not happen. The best solution as I see it is for the baseline scheme to treat EXP the same as NM but to raise a management alarm... I have also highlighted another point in Appendix A which needs a decision: should we as a WG recommend that RFC3168 full functionality tunnels SHOULD NOT be used in a PCN-domain or would it be better to put our collective voices behind Bob's attempts to correct the anomalous behaviour of tunnels which he is currently trying to push through TSVWG (draft-briscoe-tsvwg-ecn-tunnel-01) Toby -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 14 October 2008 15:35 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-01 A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-ietf-pcn-baseline-encoding Revision: 01 Title: Baseline Encoding and Transport of Pre-Congestion Information Creation_date: 2008-10-14 WG ID: pcn Number_of_pages: 12 Abstract: Pre-congestion notification (PCN) provides information to support admission control and flow termination in order to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for only two PCN encoding states. It is designed to be easily extended to provide more encoding states but such schemes will be described in other documents. The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 14 15:26:11 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE54228C132; Tue, 14 Oct 2008 15:26:11 -0700 (PDT) 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 0F21028C132 for ; Tue, 14 Oct 2008 15:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 AyvWcxyYtBKO for ; Tue, 14 Oct 2008 15:26:08 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id CDBCC3A6AA0 for ; Tue, 14 Oct 2008 15:26:06 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E096FA0633; Wed, 15 Oct 2008 00:26:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id D3C83A062C; Wed, 15 Oct 2008 00:26:59 +0200 (CEST) Received: from [132.187.246.34] (wvpn034.vpn.uni-wuerzburg.de [132.187.246.34]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5B0D5198DD4; Wed, 15 Oct 2008 00:26:59 +0200 (CEST) Message-ID: <48F51C55.40309@informatik.uni-wuerzburg.de> Date: Wed, 15 Oct 2008 00:25:26 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Philip Eardley References: <4A916DBC72536E419A0BD955EDECEDEC03DAA328@E03MVB1-UKBR.domain1.systemhost.net> <1223987930.10191.16.camel@tachyon> In-Reply-To: <1223987930.10191.16.camel@tachyon> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil and all, I've got some comments on the marking document. =================================================== The abstract talks about a first and a second rate. Better: Threshold marking marks all PCN-packets if the PCN traffic rate is greater than its configured reference rate (PCN-threshold-rate). Excess marking marks a proportion of PCN-packets, such that the amount of unmarked packets equals the rate of its configured reference rate (PCN-excess-rate). =================================================== Intro: "than some configured rate ..." -> than its reference rate (PCN-threshold-rate). The same one line below ... (PCN-excess-rate). =================================================== [RFC3168] ... ; this document defines such an alternative. Disagree: PCN marking is not intended to be delivered to end systems and is, therefore, it is not an alternative RED-like default congestion marking. The only commonality between RED-like marking and threshold/excess marking is that they re-mark the same codepoints. =================================================== The explanation of meter talks about measurements which is misleading at this point of the document. Of course, later in the document is stated that this does not tell anything about the implementation. Just try another formulation avoiding the work measurement. Better: o Threshold meter: determine whether the rate of all PCN-packets on a link is greater than its configured PCN-threshold-rate. o Excess traffic meter: measure by how much the rate of PCN-packets on a link is greater than its configured PCN-excess-rate. =================================================== o Competing-non-PCN-packet: a non PCN-packet that competes for the same capacity as PCN-traffic. "Capacity" means the forwarding bandwidth on a link; "competes" means that competing-non-PCN- packets will delay PCN-packets in the queue for the link. Competing-non-PCN-packets MUST NOT be PCN-marked (ie only PCN- packets can be PCN-marked). Note: In general it is not advised to have any competing-non-PCN-traffic. This is hard to understand. In addition, this is not precise as with any non-preemptive scheduling any non-PCN-traffic can delay non-PCN-traffic. Better: Competing-non-PCN-packet: a non-PCN-packet sharing a link with PCN-packets and competing with them for its forwarding bandwidth. "Competing" means that it can be elected for transmission in spite of waiting PCN-packets. ... Section 2.1 similar case. =================================================== Section 2.2 o metering all metered-packets to determine if the level of metered- traffic is sufficiently high to overload the PCN behaviour aggregate. (According to [RFC2475] metering is "the process of measuring the temporal properties (eg rate) of a traffic stream".) What does "to overload the PCN behaviour aggregate" mean? =================================================== If the PCN-node drops PCN-packets then: o PCN-packets that arrive at the PCN-node already excess-traffic- marked SHOULD be preferentially dropped; This default behavior significantly delays direct measured rate termination (DMRT) as well as marked flow termination (see Section IV.B of [1] and Section V.D.4 of [2]). Thus, if these termination methods should be further considered as options, there must be a choice that unmarked PCN packets are dropped preferentially. The presented drop preference is only beneficial for indirect measured rate termination (IMRT). However, the implementation of IMRT is quite complex as it needs to correlate distributed measurements and biased measurement intervals can lead to overtermination (see Section IV.B of [1]). Therefore, I find it risky to close the door for other termination methods by recommending only preferential dropping of marked packets. [1] http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf [2] http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf =================================================== Section 2.4 In addition to the above, if the token bucket is within an MTU of being empty, then the meter SHOULD indicate to the Marking function that the packet is to be excess-traffic-marked; MTU means the maximum size of PCN-packets on the link. Otherwise the meter MUST NOT indicate marking. Some statement should say that this choice has been made to achieve packet-size-independent marking. =================================================== Section 2.5 This section describes the required joint behavior of excess and threshold markers in specific deployment scenarios. Doing that in the main body of the documents sounds like excluding other use, e.g. for packet-specific dual marking which allows the implementation of a CL-like admission control and flow termination with only a single DSCP. I suggest decoupling the description of the meter and marker functions from their joint behavior which depends on the specific encoding. =================================================== General "Threshold marking" is not a good name for the algorithm. The name was a working name in some email conversations of Anna and me. It was inspired by the fact that the token bucket based mechanism used a threshold to trigger the marking, the name was tight to the specific token bucket implementation, not well deliberated and not intended for eternal use. There are several reasons why a different name should be chosen: 1) This document explicitly states that no special implementation should be mandated. 2) Also implementations of excess traffic marking use thresholds, e.g. for implementing the MTU check. 3) The name threshold marking does not say what the algorithm does. Therefore, I propose exhaustive marking. I do not see why an obviously bad nomenclature should be used if better nomenclature exists. It prevents people from memorizing what the marking behavior does which is important for quickly understanding the technology. Ok, this last note is a matter of style. It is important but not as important as the introduction of an admissible and supportable rate in the architecture draft to allow for a description of the PCN concept independently of any specific deployment scenario. Regards, Michael Steven Blake wrote: > We want to advance this document quickly. Please come to Minneapolis > with comments prepared. Or better yet, send them to the list ASAP. > > > On Thu, 2008-10-02 at 15:29 +0100, philip.eardley@bt.com wrote: > > >> Hi, >> This is the update to the marking behaviour draft, which (I think) >> includes all the discussion we had on the list and in Dublin about the >> previous version (draft-eardley-pan-marking-behaviour-01) >> >> Summary of changes: >> >> o Removed material concerning per domain behaviour and PCN-boundary- >> node operation (temporarily archived to Appendix C) >> it was agreed that this draft should be just about the 'per-hop' >> behaviour. >> >> We need a draft about the per-domain behaviour. This will be very short, >> eg saying that all nodes in the PCN-domain have to be configured to do >> the same type of marking, the same choice about encoding states, do >> policing at the ingress-node etc. ietf-pcn-baseline-encoding Appendix B >> also indicates some things that the PCN-boundary-nodes need to do. >> I (& Toby) don't have time to write this per-domain behaviour draft >> (hoping for volunteer(s)!) >> >> There's also the Info edge behaviour draft or drafts. Some of the >> material in Appendix C might be useful for that. >> >> >> o Removed mention of downgrading as an option for per-hop traffic >> conditioning. In fact, downgrading is no longer allowed because S >> 2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a >> non PCN-packet". >> >> o Traffic conditioning is now a MAY. Since in general flow >> termination (not traffic conditioning) is PCN's method for >> handling problems of too much traffic. >> I think I got the conclusion on this right, but would appreciate people >> checking. I think a MAY captures best our conclusion (rather than a >> SHOULD or not talking about it all) >> >> o Metered-packets: competing-non-PCN-packets now MAY be metered. >> Since it is recommended that the operator doesn't allow any >> competing-non-PCN-traffic, and (if there is) there are potentially >> other ways of coping. >> This was the discussion with Christian recently about Section 6.5 of the >> architecture draft. >> In the previous draft, it was a MUST to meter these >> competing-non-PCN-packets. This seems onerous when we also recommend >> that there is no such traffic. >> >> o No changes (outside traffic conditioning & metering of competing- >> non-PCN-traffic) to the Normative sections of the draft. >> >> o Appendix B.1 added about competing-non-PCN-traffic. Recommended >> that there is no such traffic, but guidance given if there is. >> >> >> Sorry this has taken me longer than expected to get out. >> >> I'll do another rev before Minneapolis. I believe (or at least hope!) >> that it'll then be ready for last call/ >> >> Best wishes >> phil >> >> { -----Original Message----- >> { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> { Internet-Drafts@ietf.org >> { Sent: 02 October 2008 13:45 >> { To: i-d-announce@ietf.org >> { Cc: pcn@ietf.org >> { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.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-00.txt >> { Pages : 22 >> { Date : 2008-10-02 >> { >> { 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 first >> { configured rate. Excess traffic marking marks a proportion of PCN- >> { packets, such that the amount marked equals the traffic rate in >> { excess of a second configured rate.Requirements Language >> { >> { The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> { "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> { document are to be interpreted as described in RFC 2119 [RFC2119]. >> { >> { A URL for this Internet-Draft is: >> { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour- >> { 00.txt >> { >> { Internet-Drafts are also available by anonymous FTP at: >> { ftp://ftp.ietf.org/internet-drafts/ >> { >> { Below is the data which will enable a MIME compliant mail reader >> { implementation to automatically retrieve the ASCII version of the >> { Internet-Draft. >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > > > Regards, > > // Steve > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 00:18:10 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817273A6886; Wed, 15 Oct 2008 00:18:10 -0700 (PDT) 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 5357C3A685D for ; Wed, 15 Oct 2008 00:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xar+tg1MO0HS for ; Wed, 15 Oct 2008 00:18:08 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 2E6A83A6858 for ; Wed, 15 Oct 2008 00:18:08 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m9F7GkRE029347 for ; Wed, 15 Oct 2008 09:16:46 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 15 Oct 2008 07:16:46 +0000 To: "pcn@ietf.org" Date: Wed, 15 Oct 2008 07:16:46 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1223987748.10191.13.camel@tachyon> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 15 Oct 2008 09:16:47 +0200 (MEST) Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil I have read version 07 of the PCN architecture draft. Thanks for trying to incorporate my last comments. However, I think that some more clarifications are needed: Comment_1: Section 6, page 15: Please remove the words "at most" that refers to the extension of encodings: Please change from: "Extension encodings may be defined that, at most, use a second DSCP .." INTO: "Extension encodings may be defined that use a second DSCP .." ----------------------------- Comment_2: Section 7.4, page 23: Please add the following combination of words to the following sentence: - (others might be possible) Please change from: "As well as the functions covered above, other specific admission control functions need to be performed:" INTO: "As well as the functions covered above, other specific admission control functions need to be performed (others might be possible):" ------------------------------------ Comment_3: Section 7.4, page 23: Please change from: "There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used):" INTO: "There are various possibilities (others might be possible) for how the functionality could be distributed (we assume the operator would configure which is used):" ------------------------- Comment_4: Section 7.5, page 24: Please change from: "As well as the functions covered above, other specific termination control functions need to be performed:" INTO: "As well as the functions covered above, other specific termination control functions need to be performed (others might be possible):" Best regards, Georgios On 10/14/2008, "Steven Blake" wrote: >By my reading of the last call comments, the only remaining issue where >we have some disagreement is surrounding the terminology proposed by >Michael Menth. > >Does everyone agree that this is the last remaining issue? > >If so, could we close on that this week? Please send your commments to >the list ASAP. > > >Regards, > >// Steve > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 02:00:51 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158C13A688D; Wed, 15 Oct 2008 02:00:51 -0700 (PDT) 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 A93F728C1FB for ; Wed, 15 Oct 2008 02:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 BpwwqZmClfPm for ; Wed, 15 Oct 2008 02:00:49 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 65D9328C1F4 for ; Wed, 15 Oct 2008 02:00:49 -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, 15 Oct 2008 10:01:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 10:01:43 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA35E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOg From: To: , X-OriginalArrivalTime: 15 Oct 2008 09:01:47.0215 (UTC) FILETIME=[A73E1DF0:01C92EA4] Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Thanks Georgios, Comment 1: I wrote in the document that extension encodings would either use the baseline DSCP or "at most" a second dscp. You have in mind that an extension encoding might use further DSCPs. I think 1 or 2 dscps reflects all opinions that I've heard & all extension encodings proposed so far. Further, Steve's WG consensus call in March had Q2: Should the PCN wg produce an experimental-track extension to the standards-track PCN scheme that requires another encoding state (for a total of three encoding states)? Such an extension, I think, needs "at most a second DSCP". So I'm inclined not to change the text. I'm interested whether you have a specific idea for an extension encoding that requires three DSCPs? (would like to see the proposal, even if just a sketch) Comments 2 (3 & 4 are very similar): What's the reason behind this suggestion? The text describes the admission control functions that have been talked about within the WG (except for probing, which is covered later). Do you have specific functions beyond ones that are already mentioned? Similarly for comment 3, do you have a particular example of another way that the admission ctrl functionality could /should be distributed? I think if your motivation is that we should have as few restrictions as possible - I'm inclined to disagree. The doc already talks about quite a few different approaches for admission and termination. One of Lars's criticisms of an earlier version of the architecture draft was that it was too vague and hadn't narrowed down enough from the infinite spectrum of possibilities. So I need more persuasion about comments 2-4. Thanks Phil/ { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Georgios Karagiannis { Sent: 15 October 2008 08:17 { To: pcn@ietf.org { Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture { { Hi Phil { { { I have read version 07 of the PCN architecture draft. { Thanks for trying to incorporate my last comments. { However, I think that some more clarifications are needed: { { Comment_1: { Section 6, page 15: { Please remove the words "at most" that refers to the extension of { encodings: { { Please change from: { "Extension encodings may be { defined that, at most, use a second DSCP .." { { INTO: { { "Extension encodings may be { defined that use a second DSCP .." { { ----------------------------- { { { Comment_2: { Section 7.4, page 23: { Please add the following combination of words to the following sentence: { - (others might be possible) { Please change from: { "As well as the functions covered above, other specific admission { control functions need to be performed:" { { INTO: { "As well as the functions covered above, other specific admission { control functions need to be performed (others might be possible):" { { ------------------------------------ { { { Comment_3: { Section 7.4, page 23: { { Please change from: { "There are various possibilities for how the functionality could be { distributed (we assume the operator would configure which is used):" { { INTO: { "There are various possibilities (others might be possible) for how the { functionality could be { distributed (we assume the operator would configure which is used):" { { ------------------------- { { { Comment_4: { Section 7.5, page 24: { Please change from: { { "As well as the functions covered above, other specific termination { control functions need to be performed:" { { INTO: { "As well as the functions covered above, other specific termination { control functions need to be performed (others might be possible):" { { Best regards, { Georgios { { { { { { { { { { On 10/14/2008, "Steven Blake" wrote: { { >By my reading of the last call comments, the only remaining issue where { >we have some disagreement is surrounding the terminology proposed by { >Michael Menth. { > { >Does everyone agree that this is the last remaining issue? { > { >If so, could we close on that this week? Please send your commments to { >the list ASAP. { > { > { >Regards, { > { >// Steve { > { >_______________________________________________ { >PCN mailing list { >PCN@ietf.org { >https://www.ietf.org/mailman/listinfo/pcn { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 02:17:32 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA563A6918; Wed, 15 Oct 2008 02:17:32 -0700 (PDT) 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 4BFB63A68CC for ; Wed, 15 Oct 2008 02:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k61Jq8cccMpD for ; Wed, 15 Oct 2008 02:17:30 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 0DE643A6953 for ; Wed, 15 Oct 2008 02:17:29 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m9F9Hfqg018223; Wed, 15 Oct 2008 11:17:45 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <4A916DBC72536E419A0BD955EDECEDEC03DAA35E@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 15 Oct 2008 11:17:34 +0200 Message-ID: <000901c92ea6$df42b6f0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA35E@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOgAAFfiCA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 15 Oct 2008 11:17:46 +0200 (MEST) Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Please see in line: > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 15 oktober 2008 11:02 > To: karagian@cs.utwente.nl; pcn@ietf.org > Subject: RE: [PCN] Second Last Call for draft-ietf-pcn-architecture > > Thanks Georgios, > > Comment 1: > I wrote in the document that extension encodings would either > use the baseline DSCP or "at most" a second dscp. You have in > mind that an extension encoding might use further DSCPs. I > think 1 or 2 dscps reflects all opinions that I've heard & > all extension encodings proposed so far. > Further, Steve's WG consensus call in March had > Q2: Should the PCN wg produce an experimental-track extension to the > standards-track PCN scheme that requires another encoding > state (for > a total of three encoding states)? > Such an extension, I think, needs "at most a second DSCP". > > So I'm inclined not to change the text. > > I'm interested whether you have a specific idea for an > extension encoding that requires three DSCPs? (would like to > see the proposal, even if just a sketch) Georgios: This is associated with the possibility of using the Affected marking encoding. The answer on how many DSCPs will be used, will be asnwerwed by other documents and not the PCN architecture draft. > > > Comments 2 (3 & 4 are very similar): > What's the reason behind this suggestion? The text describes > the admission control functions that have been talked about > within the WG (except for probing, which is covered later). > Do you have specific functions beyond ones that are already > mentioned? Similarly for comment 3, do you have a particular > example of another way that the admission ctrl functionality > could /should be distributed? > > I think if your motivation is that we should have as few > restrictions as possible - I'm inclined to disagree. The doc > already talks about quite a few different approaches for > admission and termination. One of Lars's criticisms of an > earlier version of the architecture draft was that it was too > vague and hadn't narrowed down enough from the infinite > spectrum of possibilities. So I need more persuasion about > comments 2-4. Georgios: The comments 2,3, and 4 are related to the discussion regarding the HOSE model vs. ingress-egress-aggregate model. The description in 7.4 and 7.5 talks only about the ingress-egress-aggregate model. You may work out commnets 2,3 and 4 and rephrase the text as you want such that other models than ingress-egress-aggregate model are not excluded. Best regards, Georgios > > Thanks > Phil/ > > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of { Georgios Karagiannis { Sent: 15 October 2008 > 08:17 { To: pcn@ietf.org { Subject: Re: [PCN] Second Last > Call for draft-ietf-pcn-architecture { { Hi Phil { { { I have > read version 07 of the PCN architecture draft. > { Thanks for trying to incorporate my last comments. > { However, I think that some more clarifications are needed: > { > { Comment_1: > { Section 6, page 15: > { Please remove the words "at most" that refers to the > extension of { encodings: > { > { Please change from: > { "Extension encodings may be > { defined that, at most, use a second DSCP .." > { > { INTO: > { > { "Extension encodings may be > { defined that use a second DSCP .." > { > { ----------------------------- > { > { > { Comment_2: > { Section 7.4, page 23: > { Please add the following combination of words to the following > sentence: > { - (others might be possible) > { Please change from: > { "As well as the functions covered above, other specific admission > { control functions need to be performed:" > { > { INTO: > { "As well as the functions covered above, other specific admission > { control functions need to be performed (others might be > possible):" > { > { ------------------------------------ > { > { > { Comment_3: > { Section 7.4, page 23: > { > { Please change from: > { "There are various possibilities for how the functionality could be > { distributed (we assume the operator would configure which is > used):" > { > { INTO: > { "There are various possibilities (others might be > possible) for how the { functionality could be > { distributed (we assume the operator would configure which is > used):" > { > { ------------------------- > { > { > { Comment_4: > { Section 7.5, page 24: > { Please change from: > { > { "As well as the functions covered above, other specific termination > { control functions need to be performed:" > { > { INTO: > { "As well as the functions covered above, other specific termination > { control functions need to be performed (others might be > possible):" > { > { Best regards, > { Georgios > { > { > { > { > { > { > { > { > { > { On 10/14/2008, "Steven Blake" wrote: > { > { >By my reading of the last call comments, the only > remaining issue where { >we have some disagreement is > surrounding the terminology proposed by { >Michael Menth. > { > > { >Does everyone agree that this is the last remaining issue? > { > > { >If so, could we close on that this week? Please send your > commments to { >the list ASAP. > { > > { > > { >Regards, > { > > { >// Steve > { > > { >_______________________________________________ > { >PCN mailing list > { >PCN@ietf.org > { >https://www.ietf.org/mailman/listinfo/pcn > { _______________________________________________ > { PCN mailing list > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 03:08:23 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7F03A68CC; Wed, 15 Oct 2008 03:08:23 -0700 (PDT) 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 37CAD3A68CC for ; Wed, 15 Oct 2008 03:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 yvOQNfJz+KAb for ; Wed, 15 Oct 2008 03:08:21 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E3A933A68B1 for ; Wed, 15 Oct 2008 03:08:20 -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, 15 Oct 2008 11:09:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 11:09:17 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA361@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000901c92ea6$df42b6f0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOgAAFfiCAAAOC+kA== From: To: , X-OriginalArrivalTime: 15 Oct 2008 10:09:18.0423 (UTC) FILETIME=[15F36670:01C92EAE] Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { > { > Comment 1: { > I wrote in the document that extension encodings would either { > use the baseline DSCP or "at most" a second dscp. You have in { > mind that an extension encoding might use further DSCPs. I { > think 1 or 2 dscps reflects all opinions that I've heard & { > all extension encodings proposed so far. { > Further, Steve's WG consensus call in March had { > Q2: Should the PCN wg produce an experimental-track extension to the { > standards-track PCN scheme that requires another encoding { > state (for { > a total of three encoding states)? { > Such an extension, I think, needs "at most a second DSCP". { > { > So I'm inclined not to change the text. { > { > I'm interested whether you have a specific idea for an { > extension encoding that requires three DSCPs? (would like to { > see the proposal, even if just a sketch) { { Georgios: This is associated with the possibility of using the { Affected marking encoding. { The answer on how many DSCPs will be used, will be asnwerwed by other { documents and not the PCN architecture draft. Why would affected marking need a 3rd dscp? 2 dscps would seem to leave plenty of room. { { { { Georgios: The comments 2,3, and 4 are related to the discussion { regarding the HOSE model vs. ingress-egress-aggregate model. { { The description in 7.4 and 7.5 talks only about the { ingress-egress-aggregate model. { { You may work out commnets 2,3 and 4 and rephrase the text as you want { such that other models than ingress-egress-aggregate model are not { excluded. Ok. I don't see why comment 3 (distribution of admission ctrl functionality) applies. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 03:14:47 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75093A6A39; Wed, 15 Oct 2008 03:14:47 -0700 (PDT) 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 C34963A6A39 for ; Wed, 15 Oct 2008 03:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx54oim1UjqM for ; Wed, 15 Oct 2008 03:14:43 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C0CB33A6956 for ; Wed, 15 Oct 2008 03:14:42 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m9FAFaTJ028036; Wed, 15 Oct 2008 12:15:40 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <000901c92ea6$df42b6f0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA361@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 15 Oct 2008 12:15:31 +0200 Message-ID: <000c01c92eae$f7ada7b0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA361@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOgAAFfiCAAAOC+kAABRfiw X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 15 Oct 2008 12:15:40 +0200 (MEST) Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Please see in line! > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 15 oktober 2008 12:09 > To: karagian@cs.utwente.nl; pcn@ietf.org > Subject: RE: [PCN] Second Last Call for draft-ietf-pcn-architecture > > { > > { > Comment 1: > { > I wrote in the document that extension encodings would > either { > use the baseline DSCP or "at most" a second dscp. > You have in { > mind that an extension encoding might use > further DSCPs. I { > think 1 or 2 dscps reflects all opinions > that I've heard & { > all extension encodings proposed so far. > { > Further, Steve's WG consensus call in March had { > Q2: > Should the PCN wg produce an experimental-track extension to the > { > standards-track PCN scheme that requires another encoding > { > state (for > { > a total of three encoding states)? > { > Such an extension, I think, needs "at most a second DSCP". > { > > { > So I'm inclined not to change the text. > { > > { > I'm interested whether you have a specific idea for an { > > extension encoding that requires three DSCPs? (would like > to { > see the proposal, even if just a sketch) { { Georgios: > This is associated with the possibility of using the { > Affected marking encoding. > { The answer on how many DSCPs will be used, will be > asnwerwed by other { documents and not the PCN architecture draft. > > Why would affected marking need a 3rd dscp? 2 dscps would > seem to leave plenty of room. Georgios: It depends on how the specification of the encoding states will be standardised. > > { > { > { > { Georgios: The comments 2,3, and 4 are related to the > discussion { regarding the HOSE model vs. > ingress-egress-aggregate model. > { > { The description in 7.4 and 7.5 talks only about the { > ingress-egress-aggregate model. > { > { You may work out commnets 2,3 and 4 and rephrase the text > as you want { such that other models than > ingress-egress-aggregate model are not { excluded. > > Ok. I don't see why comment 3 (distribution of admission ctrl > functionality) applies. Georgios: You are right. If comment_2 is worked out, than comment_3 will also be worked out! Best regards, Georgios > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 03:20:25 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077333A6C5C; Wed, 15 Oct 2008 03:20:25 -0700 (PDT) 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 919DD3A68B9 for ; Wed, 15 Oct 2008 03:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 MNVBadl6MNvx for ; Wed, 15 Oct 2008 03:20:22 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 9489E3A6853 for ; Wed, 15 Oct 2008 03:20:22 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 11:21:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 11:21:10 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA363@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000c01c92eae$f7ada7b0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOgAAFfiCAAAOC+kAABRfiwAAAyDYA= From: To: , X-OriginalArrivalTime: 15 Oct 2008 10:21:11.0499 (UTC) FILETIME=[BEFA29B0:01C92EAF] Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { > Why would affected marking need a 3rd dscp? 2 dscps would { > seem to leave plenty of room. { { Georgios: It depends on how the specification of the encoding states { will be standardised. Well, that's not really an answer. { > { > Ok. I don't see why comment 3 (distribution of admission ctrl { > functionality) applies. { { Georgios: You are right. If comment_2 is worked out, than comment_3 will { also be worked out! { just to make sure I understand. If I add in comments 2 & 4, then you're happy that I ignore comment 3. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 03:31:13 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2A628C1FB; Wed, 15 Oct 2008 03:31:13 -0700 (PDT) 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 0C49D3A6922 for ; Wed, 15 Oct 2008 03:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 juUdmLuZUB1p for ; Wed, 15 Oct 2008 03:31:10 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 391B93A68B0 for ; Wed, 15 Oct 2008 03:31:09 -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, 15 Oct 2008 11:31:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 11:31:31 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA365@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48F51C55.40309@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt Thread-Index: AckuS/suhuk4yBLTRYi1U6NTwHeHSwAZMwww From: To: , X-OriginalArrivalTime: 15 Oct 2008 10:31:32.0200 (UTC) FILETIME=[30F19E80:01C92EB1] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Please can a 3168 expert answer this comment from Michael. I think the text may have come from bob (or I mangled his text)/ thanks { =================================================== { { { [RFC3168] ... ; this document defines such an alternative. { Disagree: PCN marking is not intended to be delivered to end systems and { is, therefore, it is not an alternative RED-like default congestion { marking. The only commonality between RED-like marking and { threshold/excess marking is that they re-mark the same codepoints. { { =================================================== the text appears in the Intro & in full is [RFC3168] defines a broadly RED-like default congestion marking behaviour, but allows alternatives to be defined; this document defines such an alternative. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 04:10:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C283A6C64; Wed, 15 Oct 2008 04:10:20 -0700 (PDT) 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 4C03E3A6C64 for ; Wed, 15 Oct 2008 04:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-0.318, 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 iOysOKLirVQF for ; Wed, 15 Oct 2008 04:10:18 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 673EC3A694D for ; Wed, 15 Oct 2008 04:10:16 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 12:11:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 12:11:14 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA367@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jgACqNtjA= From: To: , X-OriginalArrivalTime: 15 Oct 2008 11:11:14.0479 (UTC) FILETIME=[BCE48BF0:01C92EB6] Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Toby, Michael has brought up what I think is a good suggestion in the context of the marking behaviour draft http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-00 { =================================================== { { Section 2.5 { { This section describes the required joint behavior of excess and threshold { markers in specific deployment scenarios. Doing that in the main body of { the documents sounds like excluding other use, e.g. for packet-specific { dual { marking which allows the implementation of a CL-like admission control and { flow termination with only a single DSCP. I suggest decoupling the { description { of the meter and marker functions from their joint behavior which depends { on { the specific encoding. I sympathise with michael's point. I'm inclined to think that most of the current text in S2.5 of ietf-pcn-marking-behaviour-00 would fit better in the baseline encoding draft. I think it would fit naturally into your text about encoding transitions (current Appendix B). at the moment the table just gives what the valid transitions are - this would be expanded by saying in more detail which specific transitions are valid depending on what the meters say. In answer to your question about App B "The PCN working group needs to decide whether to include this in this baseline encoding or whether to transfer it to an alternative document." I think michael's point & PSDM example means that it needs to be specified in each encoding document. You could say this in S5 (Rules for Experimental Encoding Schemes) ie require extensions to specify similarly what the encoding transitions are depending on the state of the 2 meters. phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { toby.moncaster@bt.com { Sent: 14 October 2008 15:52 { To: pcn@ietf.org { Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline- { encoding-01 { { As promised I have uploaded a new version. I am aware there are a handful { of typos and spelling mistakes that I noticed just after uploading. I will { correct these in the next version. I am now pretty happy with almost all { the text. { { The key section for the WG to note is Appendix B where I have put in a { couple of questions that I would welcome input on. { { The first of these is where to put the text (now set out as a table) about { valid and invalid transitions at PCN nodes? Should this be part of the { baseline encoding or should it be split between a new edge node behaviour { document and Phil's marking behaviour. { { The second question relates to how to best handle the unexpected presence { of the EXP codepoint. There is a potential for this to happen during any { partial deployment of an experimental encoding extension scheme. Whilst it { would be best for an operator to ensure all nodes run the same encoding { there is a chance this might not happen. The best solution as I see it is { for the baseline scheme to treat EXP the same as NM but to raise a { management alarm... { { I have also highlighted another point in Appendix A which needs a { decision: should we as a WG recommend that RFC3168 full functionality { tunnels SHOULD NOT be used in a PCN-domain or would it be better to put { our collective voices behind Bob's attempts to correct the anomalous { behaviour of tunnels which he is currently trying to push through TSVWG { (draft-briscoe-tsvwg-ecn-tunnel-01) { { Toby { { -----Original Message----- { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] { Sent: 14 October 2008 15:35 { 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-01 { { { A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been { successfuly submitted by T Moncaster and posted to the IETF repository. { { Filename: draft-ietf-pcn-baseline-encoding { Revision: 01 { Title: Baseline Encoding and Transport of Pre-Congestion { Information { Creation_date: 2008-10-14 { WG ID: pcn { Number_of_pages: 12 { { Abstract: { Pre-congestion notification (PCN) provides information to support { admission control and flow termination in order to protect the { Quality of Service of inelastic flows. It does this by marking { packets when traffic load on a link is approaching or has exceeded a { threshold below the physical link rate. This document specifies how { such marks are to be encoded into the IP header. The baseline { encoding described here provides for only two PCN encoding states. { It is designed to be easily extended to provide more encoding states { but such schemes will be described in other documents. { { { { The IETF Secretariat. { { { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 04:23:08 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B21828C0F5; Wed, 15 Oct 2008 04:23:08 -0700 (PDT) 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 55E603A6950 for ; Wed, 15 Oct 2008 04:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, 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 jcAGWPfg0gs8 for ; Wed, 15 Oct 2008 04:23:06 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9463A3A6914 for ; Wed, 15 Oct 2008 04:23:05 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 12:23:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 12:23:29 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA368@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48F51C55.40309@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt Thread-Index: AckuS/suhuk4yBLTRYi1U6NTwHeHSwAZK19g From: To: X-OriginalArrivalTime: 15 Oct 2008 11:23:30.0057 (UTC) FILETIME=[7354D790:01C92EB8] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael Thanks very much for your comments, very useful Phil { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 14 October 2008 23:25 { To: Eardley,PL,Philip,CXR9 R { Cc: Steven Blake; pcn { Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt { { Hi Phil and all, { { I've got some comments on the marking document. { { =================================================== { { { The abstract talks about a first and a second rate. Better: Threshold { marking marks all PCN-packets if the PCN traffic rate is greater than { its configured reference rate (PCN-threshold-rate). Excess marking { marks a proportion of PCN-packets, such that the amount of unmarked { packets equals the rate of its configured reference rate (PCN-excess- { rate). { ok { =================================================== { { { Intro: { { "than some configured rate ..." -> than its reference rate { (PCN-threshold-rate). { The same one line below ... (PCN-excess-rate). { ok { =================================================== { { { [RFC3168] ... ; this document defines such an alternative. { Disagree: PCN marking is not intended to be delivered to end systems and { is, therefore, it is not an alternative RED-like default congestion { marking. The only commonality between RED-like marking and { threshold/excess marking is that they re-mark the same codepoints. { see other email, need someone else to answer this one. { =================================================== { { { The explanation of meter talks about measurements which is misleading at { this point of the document. Of course, later in the document is stated { that this does not tell anything about the implementation. Just try { another formulation avoiding the work measurement. Better: { { o Threshold meter: determine whether the rate of all PCN-packets on a { link is { greater than its configured PCN-threshold-rate. { { o Excess traffic meter: measure by how much the rate of PCN-packets on { a link { is greater than its configured PCN-excess-rate. { ok, I'll delete measurement. Would like to keep the mention of aggregate pcn-pkts on link (rather than per flow). Although this is implied by the MUSTs later on, it might not be obvious to the fresh reader. I'll add to your text above something like "The threshold meter operates on the aggregate of all PCN-packets on the link, and not on an individual flow." { { =================================================== { { o Competing-non-PCN-packet: a non PCN-packet that competes for the { same capacity as PCN-traffic. "Capacity" means the forwarding { bandwidth on a link; "competes" means that competing-non-PCN- { packets will delay PCN-packets in the queue for the link. { Competing-non-PCN-packets MUST NOT be PCN-marked (ie only PCN- { packets can be PCN-marked). Note: In general it is not advised to { have any competing-non-PCN-traffic. { { This is hard to understand. In addition, this is not precise as with any { non-preemptive scheduling any non-PCN-traffic can delay non-PCN-traffic. { Better: { { Competing-non-PCN-packet: a non-PCN-packet sharing a link with PCN- { packets { and competing with them for its forwarding bandwidth. "Competing" { means { that it can be elected for transmission in spite of waiting PCN- { packets. { ... { { Section 2.1 similar case. Thanks. I struggled to get the phrasing nice, and I think your version is better. { { =================================================== { { Section 2.2 { { o metering all metered-packets to determine if the level of metered- { traffic is sufficiently high to overload the PCN behaviour { aggregate. (According to [RFC2475] metering is "the process of { measuring the temporal properties (eg rate) of a traffic stream".) { { What does "to overload the PCN behaviour aggregate" mean? I'll try & re-phrase & will look at diffserv phrasing when get time. I meant something like 'faster than the BA can schedule'. { { =================================================== { { If the PCN-node drops PCN-packets then: { { o PCN-packets that arrive at the PCN-node already excess-traffic- { marked SHOULD be preferentially dropped; { { This default behavior significantly delays direct measured rate { termination (DMRT) as well as marked flow termination (see Section { IV.B of [1] and Section V.D.4 of [2]). Thus, if these termination { methods should be further considered as options, there must be a choice { that unmarked PCN packets are dropped preferentially. { The presented drop preference is only beneficial for { indirect measured rate termination (IMRT). However, the implementation { of IMRT is quite complex as it needs to correlate distributed measurements { and biased measurement intervals can lead to overtermination { (see Section IV.B of [1]). Therefore, I find it risky to close the door { for other termination methods by recommending only preferential dropping { of marked packets. { { [1] http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf { [2] http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf This was discussed extensively before. The current text represents the WG consensus decision. Is there new information or argument that means the WG consensus might change? { { =================================================== { { Section 2.4 { { In addition to the above, if the token bucket is within an MTU of { being empty, then the meter SHOULD indicate to the Marking function { that the packet is to be excess-traffic-marked; MTU means the maximum { size of PCN-packets on the link. Otherwise the meter MUST NOT { indicate marking. { { Some statement should say that this choice has been made to achieve { packet-size-independent marking. I'll add a pointer to the appendix where this is explained. { { { =================================================== { { Section 2.5 { { This section describes the required joint behavior of excess and threshold { markers in specific deployment scenarios. Doing that in the main body of { the documents sounds like excluding other use, e.g. for packet-specific { dual { marking which allows the implementation of a CL-like admission control and { flow termination with only a single DSCP. I suggest decoupling the { description { of the meter and marker functions from their joint behavior which depends { on { the specific encoding. See other email. Thanks. This would reduce this section to just the start: the list of bullets, plus: A PCN-packet MUST be marked to reflect the metering results, by setting its encoding state as specified by the specific encoding that applies in the PCN-domain. { { =================================================== { { General { { "Threshold marking" is not a good name for the algorithm. The name was a { working { name in some email conversations of Anna and me. It was inspired by the { fact that { the token bucket based mechanism used a threshold to trigger the marking, { the { name was tight to the specific token bucket implementation, not well { deliberated { and not intended for eternal use. There are several reasons why a { different name { should be chosen: { 1) This document explicitly states that no special implementation should { be mandated. { 2) Also implementations of excess traffic marking use thresholds, e.g. for { implementing the MTU check. { 3) The name threshold marking does not say what the algorithm does. { Therefore, I propose exhaustive marking. { { I do not see why an obviously bad nomenclature should be used if better { nomenclature exists. It prevents people from memorizing what the marking { behavior does { which is important for quickly understanding the technology. Ok, this last { note is { a matter of style. It is important but not as important as the { introduction of an { admissible and supportable rate in the architecture draft to allow for a { description of { the PCN concept independently of any specific deployment scenario. ). Although in isolation I also prefer exhaustive marking, in practice I think having the names "exhaustive marking" and "excess traffic marking" would be very confusing. They are just too similar names & abbreviations. I chatted with anna in Dublin about alternative names - but we failed to think of anything better than threshold marking that didn't start 'ex' On the subject of the addition of the terms admissible and supportable rate to the architecture draft, so far I think we have 2 people in favour, 2 against (excluding me) and everyone else indifferent or at least silent. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 04:27:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C96528C1FC; Wed, 15 Oct 2008 04:27:55 -0700 (PDT) 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 712223A6950 for ; Wed, 15 Oct 2008 04:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFYLKafga-dP for ; Wed, 15 Oct 2008 04:27:53 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 80E443A68B0 for ; Wed, 15 Oct 2008 04:27:53 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m9FBS2wD009193; Wed, 15 Oct 2008 13:28:05 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <000c01c92eae$f7ada7b0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA363@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 15 Oct 2008 13:27:57 +0200 Message-ID: <000d01c92eb9$15a2d470$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA363@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOgAAFfiCAAAOC+kAABRfiwAAAyDYAAAmqfgA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 15 Oct 2008 13:28:05 +0200 (MEST) Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Please see in line! > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 15 oktober 2008 12:21 > To: karagian@cs.utwente.nl; pcn@ietf.org > Subject: RE: [PCN] Second Last Call for draft-ietf-pcn-architecture > > { > Why would affected marking need a 3rd dscp? 2 dscps would > { > seem to leave plenty of room. > { > { Georgios: It depends on how the specification of the > encoding states { will be standardised. > > Well, that's not really an answer.] Georgios: Yes, sorry! Affected marking needs one additional DCSP. > > { > > { > Ok. I don't see why comment 3 (distribution of admission > ctrl { > functionality) applies. > { > { Georgios: You are right. If comment_2 is worked out, than > comment_3 will { also be worked out! > { > just to make sure I understand. If I add in comments 2 & 4, > then you're happy that I ignore comment 3. > Georgios: Yes if you add in comments 2 & 4, then you could ignore comment 3! Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 04:31:06 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3098D3A6963; Wed, 15 Oct 2008 04:31:06 -0700 (PDT) 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 4578B3A6963 for ; Wed, 15 Oct 2008 04:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 FLbXwLltonjP for ; Wed, 15 Oct 2008 04:31:04 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 4364D3A68B0 for ; Wed, 15 Oct 2008 04:31:04 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 12:31:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 12:31:09 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA36C@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000d01c92eb9$15a2d470$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Second Last Call for draft-ietf-pcn-architecture Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOgAAFfiCAAAOC+kAABRfiwAAAyDYAAAmqfgAAAHzcQ From: To: , X-OriginalArrivalTime: 15 Oct 2008 11:31:10.0981 (UTC) FILETIME=[86104350:01C92EB9] Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { Georgios: { Affected marking needs one additional DCSP. So I presume you're ok with the current text (which says one additional dscp)? Just checking! Thanks Phil. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 06:08:26 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7B628C217; Wed, 15 Oct 2008 06:08:26 -0700 (PDT) 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 BAE8C28C21D for ; Wed, 15 Oct 2008 06:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uekEhGMzTQKW for ; Wed, 15 Oct 2008 06:08:23 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 0267828C213 for ; Wed, 15 Oct 2008 06:08:21 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5EAB2A06A8; Wed, 15 Oct 2008 15:08:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4FF3FA06A4; Wed, 15 Oct 2008 15:08:54 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 35B2A198DFD; Wed, 15 Oct 2008 15:08:54 +0200 (CEST) Message-ID: <48F5EB06.3080109@informatik.uni-wuerzburg.de> Date: Wed, 15 Oct 2008 15:07:18 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA367@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA367@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, I think you understood my point. I try to clarify a bit more what I and possibly you also mean. Marking documents should cover only the individual behavior of the markers and not reveal too many specifics about their exact application in specific PCN deployment scenarios. Input: set of packets to be metered, set of packets to be marked Output: set of marked packets The encoding documents should define the codepoints, explain their semantics, and give constraints about their usage. Documents about deployment scenarios should describe the behavior of PCN nodes, the correct configuration of the markers and bind their action to the specific encoding. This document should give the glue, i.e. it tells how conditioning is done, which meters and markers are used and configured with which reference rates, which packets are input for the meters and markers, and how metering results are translated into encodings. There are two major possibilities for the description of a specific PCN architecture. 1. Provide marking and encoding drafts as generic building blocks. An additional document explains how they are used in a specific deployment scenario. There may be one deployment scenario or more, depending on whether a single one covers all needs. The current objective of the group is to define one deployment scenario and keep the door open for others just in case the one does not satisfy the application scenarios. That's at least my understanding. 2. Provide marking and encoding drafts as parts of a specific deployment scenario. This degrades readability of the documents and prevents simple extension of PCN since the building blocks are not generic and must be changed to describe alternative deployment scenarios. Currently I see that the second path is taken because the marking draft contains a lot deployment specific assumptions. I don't know whether this happened intentionally or not. Regards, Michael philip.eardley@bt.com wrote: > Toby, > > Michael has brought up what I think is a good suggestion in the context > of the marking behaviour draft > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-00 > > { =================================================== > { > { Section 2.5 > { > { This section describes the required joint behavior of excess and > threshold > { markers in specific deployment scenarios. Doing that in the main body > of > { the documents sounds like excluding other use, e.g. for > packet-specific > { dual > { marking which allows the implementation of a CL-like admission control > and > { flow termination with only a single DSCP. I suggest decoupling the > { description > { of the meter and marker functions from their joint behavior which > depends > { on > { the specific encoding. > > I sympathise with michael's point. I'm inclined to think that most of > the current text in S2.5 of ietf-pcn-marking-behaviour-00 would fit > better in the baseline encoding draft. I think it would fit naturally > into your text about encoding transitions (current Appendix B). at the > moment the table just gives what the valid transitions are - this would > be expanded by saying in more detail which specific transitions are > valid depending on what the meters say. > > In answer to your question about App B "The PCN working group needs to > decide whether to > include this in this baseline encoding or whether to transfer it to > an alternative document." > I think michael's point & PSDM example means that it needs to be > specified in each encoding document. You could say this in S5 (Rules for > Experimental Encoding Schemes) ie require extensions to specify > similarly what the encoding transitions are depending on the state of > the 2 meters. > > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { toby.moncaster@bt.com > { Sent: 14 October 2008 15:52 > { To: pcn@ietf.org > { Subject: Re: [PCN] New Version Notification > fordraft-ietf-pcn-baseline- > { encoding-01 > { > { As promised I have uploaded a new version. I am aware there are a > handful > { of typos and spelling mistakes that I noticed just after uploading. I > will > { correct these in the next version. I am now pretty happy with almost > all > { the text. > { > { The key section for the WG to note is Appendix B where I have put in a > { couple of questions that I would welcome input on. > { > { The first of these is where to put the text (now set out as a table) > about > { valid and invalid transitions at PCN nodes? Should this be part of the > { baseline encoding or should it be split between a new edge node > behaviour > { document and Phil's marking behaviour. > { > { The second question relates to how to best handle the unexpected > presence > { of the EXP codepoint. There is a potential for this to happen during > any > { partial deployment of an experimental encoding extension scheme. > Whilst it > { would be best for an operator to ensure all nodes run the same > encoding > { there is a chance this might not happen. The best solution as I see it > is > { for the baseline scheme to treat EXP the same as NM but to raise a > { management alarm... > { > { I have also highlighted another point in Appendix A which needs a > { decision: should we as a WG recommend that RFC3168 full functionality > { tunnels SHOULD NOT be used in a PCN-domain or would it be better to > put > { our collective voices behind Bob's attempts to correct the anomalous > { behaviour of tunnels which he is currently trying to push through > TSVWG > { (draft-briscoe-tsvwg-ecn-tunnel-01) > { > { Toby > { > { -----Original Message----- > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > { Sent: 14 October 2008 15:35 > { 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-01 > { > { > { A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been > { successfuly submitted by T Moncaster and posted to the IETF > repository. > { > { Filename: draft-ietf-pcn-baseline-encoding > { Revision: 01 > { Title: Baseline Encoding and Transport of > Pre-Congestion > { Information > { Creation_date: 2008-10-14 > { WG ID: pcn > { Number_of_pages: 12 > { > { Abstract: > { Pre-congestion notification (PCN) provides information to support > { admission control and flow termination in order to protect the > { Quality of Service of inelastic flows. It does this by marking > { packets when traffic load on a link is approaching or has exceeded a > { threshold below the physical link rate. This document specifies how > { such marks are to be encoded into the IP header. The baseline > { encoding described here provides for only two PCN encoding states. > { It is designed to be easily extended to provide more encoding states > { but such schemes will be described in other documents. > { > { > { > { The IETF Secretariat. > { > { > { _______________________________________________ > { PCN mailing list > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 06:21:31 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCF428C1F4; Wed, 15 Oct 2008 06:21:31 -0700 (PDT) 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 8CC5F3A68B0 for ; Wed, 15 Oct 2008 06:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.314 X-Spam-Level: X-Spam-Status: No, score=-3.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 FMy2TgPdF75i for ; Wed, 15 Oct 2008 06:21:29 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 9C18228C1F4 for ; Wed, 15 Oct 2008 06:21:29 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 14:21:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 14:21:42 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA370@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48F5EB06.3080109@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckuxzHQgf0EJ0xXTwSRWEJm/kqShQAAREDg From: To: X-OriginalArrivalTime: 15 Oct 2008 13:21:51.0797 (UTC) FILETIME=[FC4C5E50:01C92EC8] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { 1. Provide marking and encoding drafts as generic building blocks. An { additional document explains how they are used in a specific deployment { scenario. There may be one deployment scenario or more, depending on { whether a single one covers all needs. The current objective of the { group is to define one deployment scenario and keep the door open for { others just in case the one does not satisfy the application scenarios. { That's at least my understanding. { { 2. Provide marking and encoding drafts as parts of a specific deployment { scenario. This degrades readability of the documents and prevents simple { extension of PCN since the building blocks are not generic and must be { changed to describe alternative deployment scenarios. { { Currently I see that the second path is taken because the marking draft { contains a lot deployment specific assumptions. I don't know whether { this happened intentionally or not. { this wasn't intentional on my part. But I know this is something that I have to make an effort to avoid, so would appreciate it if you could point out places where the marking draft makes deployment specific assumptions. Yes I agree the text in S2.5 does. App C also, but this Appendix will be deleted in the next version (it's basically a reminder to the WG that we seem to need a PDB doc, and we need someone to write it (not me!)) thanks phil _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 06:37:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C433A6C83; Wed, 15 Oct 2008 06:37:48 -0700 (PDT) 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 971EA3A692F for ; Wed, 15 Oct 2008 06:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 yid+JTEtuair for ; Wed, 15 Oct 2008 06:37:45 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id CCB6F3A6B71 for ; Wed, 15 Oct 2008 06:37:44 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 14:38:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 14:32:50 +0100 Message-ID: In-Reply-To: <48F5EB06.3080109@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notification for draft-ietf-pcn-baseline-encoding-01 Thread-Index: AckuxzVT08mVjtSeQi+hl5KJYBXJMwAAQRkA References: <4A916DBC72536E419A0BD955EDECEDEC03DAA367@E03MVB1-UKBR.domain1.systemhost.net> <48F5EB06.3080109@informatik.uni-wuerzburg.de> From: To: , X-OriginalArrivalTime: 15 Oct 2008 13:38:27.0005 (UTC) FILETIME=[4D7D0ED0:01C92ECB] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, Thank you. This is a very clear description of the functional split between the different documents that are needed for PCN. Unfortunately at the moment we have a difficult situation where the split has not been cleanly achieved. What is missing is the set of documents describing how to collect all the pieces of PCN together into a working system. The Architecture document is the basis for such documents but has had to leave some options open to cater for the different possible deployment scenarios. As you correctly say we are currently nearer to your option 2. than your option 1. This runs the risk of limiting us in future when we come to expand PCN and also makes it harder to re-use PCN as a building block for other systems. There would seem to be 2 possible approaches we can take: A) We improve the current structure by (for instance) merging the "how it all works" bits as a Part B to the Encoding document. This is not the best option as it slightly precludes the encoding documents from being used for more general purposes in the future. Also the documents describing how to assemble a system are most likely to be informational whilst the encoding is standards track. B) We find willing authors to take on the jobs of writing deployment documents bringing together all the snippets of text that already exist and creating a coherent whole from them. This would be a reasonably straight-forward task but would require careful thought as there are a number of sensible deployments that are possible currently. This is pretty much what you describe in your option 2. Myself and Phil really have no time to write new documents for PCN so the decision on which way to go depends on enough people volunteering to write new documents. I can probably find time to assist with editing such documents but can't take sole ownership... Toby -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: 15 October 2008 14:07 To: Eardley,PL,Philip,CXR9 R Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 Hi Phil, I think you understood my point. I try to clarify a bit more what I and possibly you also mean. Marking documents should cover only the individual behavior of the markers and not reveal too many specifics about their exact application in specific PCN deployment scenarios. Input: set of packets to be metered, set of packets to be marked Output: set of marked packets The encoding documents should define the codepoints, explain their semantics, and give constraints about their usage. Documents about deployment scenarios should describe the behavior of PCN nodes, the correct configuration of the markers and bind their action to the specific encoding. This document should give the glue, i.e. it tells how conditioning is done, which meters and markers are used and configured with which reference rates, which packets are input for the meters and markers, and how metering results are translated into encodings. There are two major possibilities for the description of a specific PCN architecture. 1. Provide marking and encoding drafts as generic building blocks. An additional document explains how they are used in a specific deployment scenario. There may be one deployment scenario or more, depending on whether a single one covers all needs. The current objective of the group is to define one deployment scenario and keep the door open for others just in case the one does not satisfy the application scenarios. That's at least my understanding. 2. Provide marking and encoding drafts as parts of a specific deployment scenario. This degrades readability of the documents and prevents simple extension of PCN since the building blocks are not generic and must be changed to describe alternative deployment scenarios. Currently I see that the second path is taken because the marking draft contains a lot deployment specific assumptions. I don't know whether this happened intentionally or not. Regards, Michael philip.eardley@bt.com wrote: > Toby, > > Michael has brought up what I think is a good suggestion in the context > of the marking behaviour draft > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-00 > > { =================================================== > { > { Section 2.5 > { > { This section describes the required joint behavior of excess and > threshold > { markers in specific deployment scenarios. Doing that in the main body > of > { the documents sounds like excluding other use, e.g. for > packet-specific > { dual > { marking which allows the implementation of a CL-like admission control > and > { flow termination with only a single DSCP. I suggest decoupling the > { description > { of the meter and marker functions from their joint behavior which > depends > { on > { the specific encoding. > > I sympathise with michael's point. I'm inclined to think that most of > the current text in S2.5 of ietf-pcn-marking-behaviour-00 would fit > better in the baseline encoding draft. I think it would fit naturally > into your text about encoding transitions (current Appendix B). at the > moment the table just gives what the valid transitions are - this would > be expanded by saying in more detail which specific transitions are > valid depending on what the meters say. > > In answer to your question about App B "The PCN working group needs to > decide whether to > include this in this baseline encoding or whether to transfer it to > an alternative document." > I think michael's point & PSDM example means that it needs to be > specified in each encoding document. You could say this in S5 (Rules for > Experimental Encoding Schemes) ie require extensions to specify > similarly what the encoding transitions are depending on the state of > the 2 meters. > > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { toby.moncaster@bt.com > { Sent: 14 October 2008 15:52 > { To: pcn@ietf.org > { Subject: Re: [PCN] New Version Notification > fordraft-ietf-pcn-baseline- > { encoding-01 > { > { As promised I have uploaded a new version. I am aware there are a > handful > { of typos and spelling mistakes that I noticed just after uploading. I > will > { correct these in the next version. I am now pretty happy with almost > all > { the text. > { > { The key section for the WG to note is Appendix B where I have put in a > { couple of questions that I would welcome input on. > { > { The first of these is where to put the text (now set out as a table) > about > { valid and invalid transitions at PCN nodes? Should this be part of the > { baseline encoding or should it be split between a new edge node > behaviour > { document and Phil's marking behaviour. > { > { The second question relates to how to best handle the unexpected > presence > { of the EXP codepoint. There is a potential for this to happen during > any > { partial deployment of an experimental encoding extension scheme. > Whilst it > { would be best for an operator to ensure all nodes run the same > encoding > { there is a chance this might not happen. The best solution as I see it > is > { for the baseline scheme to treat EXP the same as NM but to raise a > { management alarm... > { > { I have also highlighted another point in Appendix A which needs a > { decision: should we as a WG recommend that RFC3168 full functionality > { tunnels SHOULD NOT be used in a PCN-domain or would it be better to > put > { our collective voices behind Bob's attempts to correct the anomalous > { behaviour of tunnels which he is currently trying to push through > TSVWG > { (draft-briscoe-tsvwg-ecn-tunnel-01) > { > { Toby > { > { -----Original Message----- > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > { Sent: 14 October 2008 15:35 > { 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-01 > { > { > { A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been > { successfuly submitted by T Moncaster and posted to the IETF > repository. > { > { Filename: draft-ietf-pcn-baseline-encoding > { Revision: 01 > { Title: Baseline Encoding and Transport of > Pre-Congestion > { Information > { Creation_date: 2008-10-14 > { WG ID: pcn > { Number_of_pages: 12 > { > { Abstract: > { Pre-congestion notification (PCN) provides information to support > { admission control and flow termination in order to protect the > { Quality of Service of inelastic flows. It does this by marking > { packets when traffic load on a link is approaching or has exceeded a > { threshold below the physical link rate. This document specifies how > { such marks are to be encoded into the IP header. The baseline > { encoding described here provides for only two PCN encoding states. > { It is designed to be easily extended to provide more encoding states > { but such schemes will be described in other documents. > { > { > { > { The IETF Secretariat. > { > { > { _______________________________________________ > { PCN mailing list > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 08:04:09 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365C83A69B2; Wed, 15 Oct 2008 08:04:09 -0700 (PDT) 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 A5B7228C235 for ; Wed, 15 Oct 2008 08:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltUSVdl2sn1c for ; Wed, 15 Oct 2008 08:04:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BE94E28C22B for ; Wed, 15 Oct 2008 08:04:03 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AA543209F6; Wed, 15 Oct 2008 17:05:01 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-eb-48f6069d496e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 96019208D0; Wed, 15 Oct 2008 17:05:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 17:05:01 +0200 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 17:05:01 +0200 Message-ID: <48F6069D.3060302@ericsson.com> Date: Wed, 15 Oct 2008 17:05:01 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: iccrg@irtf.org, pcn X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 15 Oct 2008 15:05:01.0062 (UTC) FILETIME=[65634260:01C92ED7] X-Brightmail-Tracker: AAAAAA== Subject: [PCN] Solicting interest in update of ECN handling around tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsvwg List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org ICCRG and PCN WG, This is an solicitation of interest for doing work in TSVWG around updating the ECN handling for tunnels along the lines of http://tools.ietf.org/id/draft-briscoe-tsvwg-ecn-tunnel-01.txt More specifically we are considering to adopt this document as a WG item. Please provide any feedback to the TSVWG (tsvwg@ietf.org) Thanks Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 15 08:43:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5801928C223; Wed, 15 Oct 2008 08:43:55 -0700 (PDT) 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 EF4F328C24E for ; Wed, 15 Oct 2008 08:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.24 X-Spam-Level: X-Spam-Status: No, score=0.24 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeY9giYcaLJY for ; Wed, 15 Oct 2008 08:43:54 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 03EC828C223 for ; Wed, 15 Oct 2008 08:43:53 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m9FFimPh023608; Wed, 15 Oct 2008 17:44:52 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <000d01c92eb9$15a2d470$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA36C@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 15 Oct 2008 17:44:43 +0200 Message-ID: <000e01c92edc$f4b6bff0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA36C@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: AckullMlxhwp1K4CTyCmj3sflHsG0wACfQOgAAFfiCAAAOC+kAABRfiwAAAyDYAAAmqfgAAAHzcQAAjls+A= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 15 Oct 2008 17:44:52 +0200 (MEST) Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Okay! Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 15 oktober 2008 13:31 > To: karagian@cs.utwente.nl; pcn@ietf.org > Subject: RE: [PCN] Second Last Call for draft-ietf-pcn-architecture > > { Georgios: > { Affected marking needs one additional DCSP. > > So I presume you're ok with the current text (which says one > additional dscp)? > Just checking! > Thanks > Phil. > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 16 08:31:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B153A67F1; Thu, 16 Oct 2008 08:31:48 -0700 (PDT) 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 8C16C3A67F1 for ; Thu, 16 Oct 2008 08:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZKvoxmiwUgq for ; Thu, 16 Oct 2008 08:31:40 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 805B83A67CC for ; Thu, 16 Oct 2008 08:31:40 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 16:21:33 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 16:21:29 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1224170489398; Thu, 16 Oct 2008 16:21:29 +0100 Received: from mut.jungle.bt.co.uk ([10.73.216.6]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m9GFLOwr014631; Thu, 16 Oct 2008 16:21:25 +0100 Message-Id: <200810161521.m9GFLOwr014631@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Oct 2008 16:21:36 +0100 To: From: Bob Briscoe In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA365@E03MVB1-UKBR.doma in1.systemhost.net> References: <48F51C55.40309@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA365@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 16 Oct 2008 15:21:29.0280 (UTC) FILETIME=[DCD31C00:01C92FA2] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, Michael, RFC3168 is primarly in two parts. The spec for IP, and the spec for TCP. The IP part applies regardless of whether ECN is used e2e or proxy-end or proxy-proxy or edge-edge or whatever. The TCP part applies e2e. Just because 3168 ECN in IP was spec'd with TCP as the transport, it was not just intended to be used e2e. It is in this sense that the PCN marking draft is equivalent to the use of an AQM like RED to introduce explicit congestion notification. According to Sally Floyd (when I asked her about why the two had been put in one spec) she initially intended 3168 to be split between network & transport. But the IESG wanted to make sure that ECN didn't get implemented in IP without saying how it should be responded to by the transport. Otherwise it could have created an unsafe situation if people wrote their own transports to use the new IP-ECN facility without any guidance for how it should be used. The TCP part of 3168 was intended to not only be the spec for TCP, but guidance on doing something similar in other e2e transports. Sally told me they had other edge-edge transports in mind when writing 3168, but they would be deferred for later definition. Bob At 11:31 15/10/2008, philip.eardley@bt.com wrote: >Please can a 3168 expert answer this comment from Michael. I think the >text may have come from bob (or I mangled his text)/ >thanks >{ =================================================== >{ >{ >{ [RFC3168] ... ; this document defines such an alternative. >{ Disagree: PCN marking is not intended to be delivered to end systems >and >{ is, therefore, it is not an alternative RED-like default congestion >{ marking. The only commonality between RED-like marking and >{ threshold/excess marking is that they re-mark the same codepoints. >{ >{ =================================================== > >the text appears in the Intro & in full is >[RFC3168] > defines a broadly RED-like default congestion marking behaviour, but > allows alternatives to be defined; this document defines such an > alternative. > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 17 03:35:07 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605693A6924; Fri, 17 Oct 2008 03:35:07 -0700 (PDT) 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 06C403A6A41 for ; Fri, 17 Oct 2008 03:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, 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 jExxSWirqulx for ; Fri, 17 Oct 2008 03:34:57 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id EB0723A6827 for ; Fri, 17 Oct 2008 03:34:56 -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, 17 Oct 2008 11:35:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 11:35:39 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Architecture terminology Thread-Index: AckwRBmBTg9zZ3J6R8CkmY9pdekr+Q== From: To: X-OriginalArrivalTime: 17 Oct 2008 10:35:40.0528 (UTC) FILETIME=[19C8F700:01C93044] Subject: [PCN] Architecture terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0671437929==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0671437929== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93044.19433580" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93044.19433580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had a discussion with Steve and we're suggesting this as a way forward to resolve the issues.=20 Add the terms PCN-admissible-rate and PCN-supportable-rate as additional terminology. Don't make wholesale text changes to the doc, but use these terms in a few paragraphs. Then post these to the list, and ask for comments. So this is the post with the changes and the asking! Thanks Phil =20 S2 Terminology: Add: PCN-admissible-rate: the rate of PCN-traffic on a link up to which PCN admission control should accept new PCN-flows.=20 Add: PCN-supportable-rate: the rate of PCN-traffic on a link down to which PCN flow termination should, if necessary, terminate already admitted PCN-flows. =20 S3: Benefits: Bullet 2: change "The PCN-threshold-rate on each link can be chosen small enough that admitted traffic can still be carried after a rerouting in most failure cases" to "The PCN-admissible-rate on each link can be chosen small enough that admitted traffic can still be carried after a rerouting in most failure cases" =20 Bullet 9: change "The PCN-excess-rate may be set below the maximum rate that PCN-traffic can be transmitted on a link..." to "The PCN-supportable-rate may be set below the maximum rate that PCN-traffic can be transmitted on a link..." =20 S4 Deployment scenarios: In Figure 1, under "PCN-excess-rate" add "(=3DPCN-supportable-rate)" & under "PCN-threshold-rate" add "(=3DPCN-admissible-rate)" =20 S6.1 Flow admission Change the first para from: The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- threshold-rate, by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. The PCN-threshold- rate is a parameter that can be configured by the operator and will be set lower than the traffic rate at which the link becomes congested and the node drops packets. To: The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- admissible-rate, by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. With three encoding states available, the PCN-threshold- rate is configured by the operator as equal to the PCN-admissible-rate on each link. It is set lower than the traffic rate at which the link becomes congested and the node drops packets.=20 =20 S6.2 Flow termination: Change the first para from: The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-excess-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. The PCN-excess-rate is a parameter that can be configured by the operator and may be set lower than the traffic rate at which the link becomes congested and the node drops packets. To: The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-supportable-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. With three encoding states available, the PCN-excess-rate is configured by the operator as equal to the PCN-supportable-rate on each link. It may be set lower than the traffic rate at which the link becomes congested and the node drops packets. =20 S6.3 Flow admission and/or flow termination when there are only two PCN encoding states: 3rd bullet, change: o both admission control and flow termination: only the excess- traffic-marking algorithm writes PCN-marks, however the configured rate (PCN-excess-rate) is set at the rate the admission control mechanism needs to limit PCN-traffic to, as shown in Figure 2. To: o both admission control and flow termination: only the excess- traffic-marking algorithm writes PCN-marks, however the configured rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as shown in Figure 2. =20 In Figure 2:=20 under "U*PCN-excess-rate" add "(=3DPCN-supportable-rate)" & under "PCN-excess-rate" add "(=3DPCN-admissible-rate)" ------_=_NextPart_001_01C93044.19433580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I had a discussion with Steve and we’re suggesting this as a way forward to resolve the issues. =

Add the terms PCN-admissible-rate and PCN-supportable-rate as additional terminology. Don’t make = wholesale text changes to the doc, but use these terms in a few paragraphs. Then post = these to the list, and ask for comments.  So this is the post with the = changes and the asking!

Thanks

Phil

 

S2 Terminology:

Add: PCN-admissible-rate: the rate of = PCN-traffic on a link up to which PCN admission control should accept new PCN-flows. =

Add: PCN-supportable-rate: the rate of = PCN-traffic on a link down to which PCN flow termination should, if necessary, = terminate already admitted PCN-flows.

 

S3: Benefits:

Bullet 2: change “The = PCN-threshold-rate on each link can be chosen small enough that admitted traffic can still be = carried after a rerouting in most failure cases” to “The = PCN-admissible-rate on each link can be chosen small enough that admitted traffic can still = be carried after a rerouting in most failure cases”

 

Bullet 9: change “The PCN-excess-rate = may be set below the maximum rate that PCN-traffic can be transmitted on a = link…” to “The PCN-supportable-rate may be set below the maximum rate = that PCN-traffic can be transmitted on a link…”

 

S4 Deployment scenarios:

In Figure 1, under = “PCN-excess-rate” add = “(=3DPCN-supportable-rate)” & under “PCN-threshold-rate” add = “(=3DPCN-admissible-rate)”

 

S6.1 Flow admission

Change the first para from:

The objective of PCN's flow admission control =
mechanism is to limit
   the PCN-traffic on each link in =
the PCN-domain to *roughly* its PCN-
   threshold-rate, by admitting or =
blocking prospective new flows, in
   order to protect the QoS of =
existing PCN-flows.  The =
PCN-threshold-
   rate is a parameter that can be =
configured by the operator and will
   be set lower than the traffic =
rate at which the link becomes
   congested and the node drops =
packets.
To:
The =
objective of PCN's flow admission control mechanism is to =
limit
   the PCN-traffic on each link in =
the PCN-domain to *roughly* its PCN-
   admissible-rate, by admitting or =
blocking prospective new flows, in
   order to protect the QoS of =
existing PCN-flows. With three encoding states available, the =
PCN-threshold-
   rate is configured by the =
operator as equal to the PCN-admissible-rate on each link. It is set =
lower than the traffic rate at which the link becomes congested and the =
node drops packets. 
 
S6.2 Flow =
termination:

Change the first para from:

The objective of PCN's flow termination =
mechanism is to limit the
   PCN-traffic on each link to =
*roughly* its PCN-excess-rate, by
   terminating some existing =
PCN-flows, in order to protect the QoS of
   the remaining PCN-flows.  =
The PCN-excess-rate is a parameter that =
can
   be configured by the operator =
and may be set lower than the traffic
   rate at which the link becomes =
congested and the node drops packets.
To:
The =
objective of PCN's flow termination mechanism is to limit =
the
   PCN-traffic on each link to =
*roughly* its PCN-supportable-rate, by
   terminating some existing =
PCN-flows, in order to protect the QoS of
   the remaining PCN-flows.  =
With three encoding states available, the PCN-excess-rate is configured =
by the operator as equal to the PCN-supportable-rate on each link. It =
may be set lower than the traffic
   rate at which the link becomes =
congested and the node drops packets.
 
S6.3 Flow =
admission and/or flow termination when there are only two =
PCN
      encoding =
states:
3rd bullet, =
change:
o  =
both admission control and flow termination: only the =
excess-
      =
traffic-marking algorithm writes PCN-marks, however the =
configured
      rate =
(PCN-excess-rate) is set at the rate the admission =
control
      mechanism =
needs to limit PCN-traffic to, as shown in Figure =
2.
To:
o  =
both admission control and flow termination: only the =
excess-
      =
traffic-marking algorithm writes PCN-marks, however the =
configured
      rate =
(PCN-excess-rate) is set equal to the PCN-admissible-rate, as shown in =
Figure 2.
 
In Figure =
2:

under “U*PCN-excess-rate” =  add “(=3DPCN-supportable-rate)” & under “PCN-excess-rate” add = “(=3DPCN-admissible-rate)”

=00 ------_=_NextPart_001_01C93044.19433580-- --===============0671437929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0671437929==-- From pcn-bounces@ietf.org Fri Oct 17 03:46:22 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572E63A6827; Fri, 17 Oct 2008 03:46:22 -0700 (PDT) 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 170EC3A6A44 for ; Fri, 17 Oct 2008 03:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDyI2iTA+YD0 for ; Fri, 17 Oct 2008 03:46:15 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 6A6B73A63CB for ; Fri, 17 Oct 2008 03:46:14 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Fri, 17 Oct 2008 12:47:17 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Oct 2008 12:47:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 12:47:19 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01E1FFBC@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture terminology thread-index: AckwRBmBTg9zZ3J6R8CkmY9pdekr+QAANQlA References: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Oct 2008 10:47:17.0297 (UTC) FILETIME=[B9177A10:01C93045] Cc: pcn@ietf.org Subject: Re: [PCN] Architecture terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1636687329==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1636687329== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93045.B8C939EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93045.B8C939EC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phil, =20 allright with me. =20 Regards =20 Ruediger _____ =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: Friday, October 17, 2008 12:36 PM To: pcn@ietf.org Subject: [PCN] Architecture terminology I had a discussion with Steve and we're suggesting this as a way forward = to resolve the issues.=20 Add the terms PCN-admissible-rate and PCN-supportable-rate as additional = terminology. Don't make wholesale text changes to the doc, but use these = terms in a few paragraphs. Then post these to the list, and ask for = comments. So this is the post with the changes and the asking! Thanks Phil =20 S2 Terminology: Add: PCN-admissible-rate: the rate of PCN-traffic on a link up to which = PCN admission control should accept new PCN-flows.=20 Add: PCN-supportable-rate: the rate of PCN-traffic on a link down to = which PCN flow termination should, if necessary, terminate already = admitted PCN-flows. =20 S3: Benefits: Bullet 2: change "The PCN-threshold-rate on each link can be chosen = small enough that admitted traffic can still be carried after a = rerouting in most failure cases" to "The PCN-admissible-rate on each = link can be chosen small enough that admitted traffic can still be = carried after a rerouting in most failure cases" =20 Bullet 9: change "The PCN-excess-rate may be set below the maximum rate = that PCN-traffic can be transmitted on a link..." to "The = PCN-supportable-rate may be set below the maximum rate that PCN-traffic = can be transmitted on a link..." =20 S4 Deployment scenarios: In Figure 1, under "PCN-excess-rate" add "(=3DPCN-supportable-rate)" & = under "PCN-threshold-rate" add "(=3DPCN-admissible-rate)" =20 S6.1 Flow admission Change the first para from: The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- threshold-rate, by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. The PCN-threshold- rate is a parameter that can be configured by the operator and will be set lower than the traffic rate at which the link becomes congested and the node drops packets. To: The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- admissible-rate, by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. With three encoding = states available, the PCN-threshold- rate is configured by the operator as equal to the = PCN-admissible-rate on each link. It is set lower than the traffic rate = at which the link becomes congested and the node drops packets.=20 =20 S6.2 Flow termination: Change the first para from: The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-excess-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. The PCN-excess-rate is a parameter that can be configured by the operator and may be set lower than the traffic rate at which the link becomes congested and the node drops packets. To: The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-supportable-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. With three encoding states available, the = PCN-excess-rate is configured by the operator as equal to the = PCN-supportable-rate on each link. It may be set lower than the traffic rate at which the link becomes congested and the node drops packets. =20 S6.3 Flow admission and/or flow termination when there are only two PCN encoding states: 3rd bullet, change: o both admission control and flow termination: only the excess- traffic-marking algorithm writes PCN-marks, however the configured rate (PCN-excess-rate) is set at the rate the admission control mechanism needs to limit PCN-traffic to, as shown in Figure 2. To: o both admission control and flow termination: only the excess- traffic-marking algorithm writes PCN-marks, however the configured rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as = shown in Figure 2. =20 In Figure 2:=20 under "U*PCN-excess-rate" add "(=3DPCN-supportable-rate)" & under = "PCN-excess-rate" add "(=3DPCN-admissible-rate)" ------_=_NextPart_001_01C93045.B8C939EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Phil,
 
allright with me.
 
Regards
 
Ruediger

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: Friday, October 17, 2008 12:36 = PM
To: pcn@ietf.org
Subject: [PCN] Architecture=20 terminology

I had a discussion with Steve and we’re = suggesting this=20 as a way forward to resolve the issues.

Add the terms PCN-admissible-rate and=20 PCN-supportable-rate as additional terminology. Don’t make = wholesale text=20 changes to the doc, but use these terms in a few paragraphs. Then post = these to=20 the list, and ask for comments.  So this is the post with the = changes and=20 the asking!

Thanks

Phil

 

S2 Terminology:

Add: PCN-admissible-rate: the rate of = PCN-traffic on a=20 link up to which PCN admission control should accept new PCN-flows.=20

Add: PCN-supportable-rate: the rate of = PCN-traffic on a=20 link down to which PCN flow termination should, if necessary, terminate = already=20 admitted PCN-flows.

 

S3: Benefits:

Bullet 2: change “The PCN-threshold-rate = on each link=20 can be chosen small enough that admitted traffic can still be carried = after a=20 rerouting in most failure cases” to “The PCN-admissible-rate = on each link can be=20 chosen small enough that admitted traffic can still be carried after a = rerouting=20 in most failure cases”

 

Bullet 9: change “The PCN-excess-rate = may be set below=20 the maximum rate that PCN-traffic can be transmitted on a = link…” to “The=20 PCN-supportable-rate may be set below the maximum rate that PCN-traffic = can be=20 transmitted on a link…”

 

S4 Deployment scenarios:

In Figure 1, under = “PCN-excess-rate” add=20 “(=3DPCN-supportable-rate)” & under = “PCN-threshold-rate” add=20 “(=3DPCN-admissible-rate)”

 

S6.1 Flow admission

Change the first para = from:

The objective of PCN's flow admission control =
mechanism is to limit
   the PCN-traffic on =
each link in the PCN-domain to *roughly* its =
PCN-
   threshold-rate, by admitting or =
blocking prospective new flows, in
   order to protect the QoS of existing PCN-flows.  =
The PCN-threshold-
   rate is a =
parameter that can be configured by the operator and =
will
   be set lower than the traffic =
rate at which the link becomes
   congested and the node drops =
packets.
To:
The objective of PCN's flow =
admission control mechanism is to limit
   the PCN-traffic on each link in the PCN-domain to =
*roughly* its PCN-
   admissible-rate, =
by admitting or blocking prospective new flows, =
in
   order to protect the QoS of =
existing PCN-flows. With three encoding states available, the =
PCN-threshold-
   rate is configured =
by the operator as equal to the PCN-admissible-rate on each link. It is =
set lower than the traffic rate at which the link becomes congested and =
the node drops packets. 
 
S6.2 Flow =
termination:

Change the first para = from:

The objective of PCN's flow termination =
mechanism is to limit the
   PCN-traffic =
on each link to *roughly* its PCN-excess-rate, =
by
   terminating some existing =
PCN-flows, in order to protect the QoS of
   the remaining PCN-flows.  The PCN-excess-rate is =
a parameter that can
   be configured by =
the operator and may be set lower than the =
traffic
   rate at which the =
link becomes congested and the node drops =
packets.
To:
The objective of PCN's flow =
termination mechanism is to limit the
   PCN-traffic on each link to *roughly* its =
PCN-supportable-rate, by
   terminating =
some existing PCN-flows, in order to protect the QoS =
of
   the remaining PCN-flows.  =
With three encoding states available, the PCN-excess-rate is configured =
by the operator as equal to the PCN-supportable-rate on each link. It =
may be set lower than the traffic
   rate at which the link becomes congested and the node =
drops packets.
 
S6.3 Flow admission and/or flow =
termination when there are only two PCN
      encoding =
states:
3rd bullet, =
change:
o  both admission control =
and flow termination: only the excess-
      traffic-marking algorithm writes =
PCN-marks, however the configured
      rate (PCN-excess-rate) is set at =
the rate the admission control
      mechanism needs to limit =
PCN-traffic to, as shown in Figure 2.
To:
o  both admission control =
and flow termination: only the excess-
      traffic-marking algorithm writes =
PCN-marks, however the configured
      rate (PCN-excess-rate) is set equal =
to the PCN-admissible-rate, as shown in Figure =
2.
 
In Figure =
2:

under “U*PCN-excess-rate” =  add=20 “(=3DPCN-supportable-rate)” & under = “PCN-excess-rate” add=20 “(=3DPCN-admissible-rate)”

------_=_NextPart_001_01C93045.B8C939EC-- --===============1636687329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1636687329==-- From pcn-bounces@ietf.org Fri Oct 17 04:00:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A473A6924; Fri, 17 Oct 2008 04:00:44 -0700 (PDT) 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 4C7AF3A6897 for ; Fri, 17 Oct 2008 04:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMd8SCRS7jVx for ; Fri, 17 Oct 2008 04:00:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 89F2C3A6924 for ; Fri, 17 Oct 2008 04:00:35 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 031522206D; Fri, 17 Oct 2008 13:01:37 +0200 (CEST) X-AuditID: c1b4fb3e-a7682bb000007a96-ea-48f87058946e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BEECC22281; Fri, 17 Oct 2008 13:00:40 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 13:00:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 13:00:21 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05088602B4@esealmw109.eemea.ericsson.se> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture terminology Thread-Index: AckwRBmBTg9zZ3J6R8CkmY9pdekr+QAAzNQw References: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> From: "Ingemar Johansson S" To: , X-OriginalArrivalTime: 17 Oct 2008 11:00:22.0537 (UTC) FILETIME=[8D219790:01C93047] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] Architecture terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507576856==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1507576856== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93047.8CE7B5A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93047.8CE7B5A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I believe that the terms PCN-admissible-rate and PCN-supportable-rate much better explains what it is all about. =20 /Ingemar ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: den 17 oktober 2008 12:36 To: pcn@ietf.org Subject: [PCN] Architecture terminology =09 =09 I had a discussion with Steve and we're suggesting this as a way forward to resolve the issues.=20 Add the terms PCN-admissible-rate and PCN-supportable-rate as additional terminology. Don't make wholesale text changes to the doc, but use these terms in a few paragraphs. Then post these to the list, and ask for comments. So this is the post with the changes and the asking! Thanks Phil =20 S2 Terminology: Add: PCN-admissible-rate: the rate of PCN-traffic on a link up to which PCN admission control should accept new PCN-flows.=20 Add: PCN-supportable-rate: the rate of PCN-traffic on a link down to which PCN flow termination should, if necessary, terminate already admitted PCN-flows. =20 S3: Benefits: Bullet 2: change "The PCN-threshold-rate on each link can be chosen small enough that admitted traffic can still be carried after a rerouting in most failure cases" to "The PCN-admissible-rate on each link can be chosen small enough that admitted traffic can still be carried after a rerouting in most failure cases" =20 Bullet 9: change "The PCN-excess-rate may be set below the maximum rate that PCN-traffic can be transmitted on a link..." to "The PCN-supportable-rate may be set below the maximum rate that PCN-traffic can be transmitted on a link..." =20 S4 Deployment scenarios: In Figure 1, under "PCN-excess-rate" add "(=3DPCN-supportable-rate)" & under "PCN-threshold-rate" add "(=3DPCN-admissible-rate)" =20 S6.1 Flow admission Change the first para from: The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- threshold-rate, by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. The PCN-threshold- rate is a parameter that can be configured by the operator and will be set lower than the traffic rate at which the link becomes congested and the node drops packets. To: The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- admissible-rate, by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. With three encoding states available, the PCN-threshold- rate is configured by the operator as equal to the PCN-admissible-rate on each link. It is set lower than the traffic rate at which the link becomes congested and the node drops packets.=20 =20 S6.2 Flow termination: Change the first para from: The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-excess-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. The PCN-excess-rate is a parameter that can be configured by the operator and may be set lower than the traffic rate at which the link becomes congested and the node drops packets. To: The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-supportable-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. With three encoding states available, the PCN-excess-rate is configured by the operator as equal to the PCN-supportable-rate on each link. It may be set lower than the traffic rate at which the link becomes congested and the node drops packets. =20 S6.3 Flow admission and/or flow termination when there are only two PCN encoding states: 3rd bullet, change: o both admission control and flow termination: only the excess- traffic-marking algorithm writes PCN-marks, however the configured rate (PCN-excess-rate) is set at the rate the admission control mechanism needs to limit PCN-traffic to, as shown in Figure 2. To: o both admission control and flow termination: only the excess- traffic-marking algorithm writes PCN-marks, however the configured rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as shown in Figure 2. =20 In Figure 2:=20 under "U*PCN-excess-rate" add "(=3DPCN-supportable-rate)" & under "PCN-excess-rate" add "(=3DPCN-admissible-rate)" ------_=_NextPart_001_01C93047.8CE7B5A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
I = believe that the=20 terms PCN-admissible-rate and PCN-supportable-rate much better explains = what it=20 is all about.
 
/Ingemar

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: den 17 oktober 2008=20 12:36
To: pcn@ietf.org
Subject: [PCN] Architecture = terminology

I had a discussion with Steve and = we’re suggesting=20 this as a way forward to resolve the issues.

Add the terms PCN-admissible-rate and=20 PCN-supportable-rate as additional terminology. Don’t make = wholesale text=20 changes to the doc, but use these terms in a few paragraphs. Then post = these=20 to the list, and ask for comments.  So this is the post with the = changes=20 and the asking!

Thanks

Phil

 

S2 Terminology:

Add: PCN-admissible-rate: the rate of = PCN-traffic on a=20 link up to which PCN admission control should accept new PCN-flows.=20

Add: PCN-supportable-rate: the rate of = PCN-traffic on=20 a link down to which PCN flow termination should, if necessary, = terminate=20 already admitted PCN-flows.

 

S3: Benefits:

Bullet 2: change “The = PCN-threshold-rate on each link=20 can be chosen small enough that admitted traffic can still be carried = after a=20 rerouting in most failure cases” to “The = PCN-admissible-rate on each link can=20 be chosen small enough that admitted traffic can still be carried = after a=20 rerouting in most failure cases”

 

Bullet 9: change “The PCN-excess-rate = may be set below=20 the maximum rate that PCN-traffic can be transmitted on a = link…” to “The=20 PCN-supportable-rate may be set below the maximum rate that = PCN-traffic can be=20 transmitted on a link…”

 

S4 Deployment scenarios:

In Figure 1, under = “PCN-excess-rate” add=20 “(=3DPCN-supportable-rate)” & under = “PCN-threshold-rate” add=20 “(=3DPCN-admissible-rate)”

 

S6.1 Flow admission

Change the first para = from:

The objective of PCN's flow admission control =
mechanism is to limit
   the PCN-traffic on =
each link in the PCN-domain to *roughly* its =
PCN-
   threshold-rate, by admitting or =
blocking prospective new flows, in
   order to protect the QoS of existing PCN-flows.  =
The PCN-threshold-
   rate is a =
parameter that can be configured by the operator and =
will
   be set lower than the traffic =
rate at which the link becomes
   congested and the node drops =
packets.
To:
The objective of PCN's flow =
admission control mechanism is to limit
   the PCN-traffic on each link in the PCN-domain to =
*roughly* its PCN-
   admissible-rate, =
by admitting or blocking prospective new flows, =
in
   order to protect the QoS of =
existing PCN-flows. With three encoding states available, the =
PCN-threshold-
   rate is configured =
by the operator as equal to the PCN-admissible-rate on each link. It is =
set lower than the traffic rate at which the link becomes congested and =
the node drops packets. 
 
S6.2 Flow =
termination:

Change the first para = from:

The objective of PCN's flow termination =
mechanism is to limit the
   PCN-traffic =
on each link to *roughly* its PCN-excess-rate, =
by
   terminating some existing =
PCN-flows, in order to protect the QoS of
   the remaining PCN-flows.  The PCN-excess-rate is =
a parameter that can
   be configured by =
the operator and may be set lower than the =
traffic
   rate at which the =
link becomes congested and the node drops =
packets.
To:
The objective of PCN's flow =
termination mechanism is to limit the
   PCN-traffic on each link to *roughly* its =
PCN-supportable-rate, by
   terminating =
some existing PCN-flows, in order to protect the QoS =
of
   the remaining PCN-flows.  =
With three encoding states available, the PCN-excess-rate is configured =
by the operator as equal to the PCN-supportable-rate on each link. It =
may be set lower than the traffic
   rate at which the link becomes congested and the node =
drops packets.
 
S6.3 Flow admission and/or flow =
termination when there are only two PCN
      encoding =
states:
3rd bullet, =
change:
o  both admission control =
and flow termination: only the excess-
      traffic-marking algorithm writes =
PCN-marks, however the configured
      rate (PCN-excess-rate) is set at =
the rate the admission control
      mechanism needs to limit =
PCN-traffic to, as shown in Figure 2.
To:
o  both admission control =
and flow termination: only the excess-
      traffic-marking algorithm writes =
PCN-marks, however the configured
      rate (PCN-excess-rate) is set equal =
to the PCN-admissible-rate, as shown in Figure =
2.
 
In Figure =
2:

under “U*PCN-excess-rate” =  add=20 “(=3DPCN-supportable-rate)” & under = “PCN-excess-rate” add=20 = “(=3DPCN-admissible-rate)”

------_=_NextPart_001_01C93047.8CE7B5A2-- --===============1507576856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1507576856==-- From pcn-bounces@ietf.org Fri Oct 17 04:20:01 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B5A3A6A49; Fri, 17 Oct 2008 04:20:01 -0700 (PDT) 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 5E3D23A6A49 for ; Fri, 17 Oct 2008 04:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.171, 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 APkI3z5GoBEh for ; Fri, 17 Oct 2008 04:19:58 -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 EDA5D3A697F for ; Fri, 17 Oct 2008 04:19:57 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5329AA0714; Fri, 17 Oct 2008 13:20:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 46EC7A0605; Fri, 17 Oct 2008 13:20:59 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 30857198EB2; Fri, 17 Oct 2008 13:20:59 +0200 (CEST) Message-ID: <48F874B8.6070308@informatik.uni-wuerzburg.de> Date: Fri, 17 Oct 2008 13:19:20 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] Architecture terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, thanks a lot! Regards, Michael philip.eardley@bt.com wrote: > > I had a discussion with Steve and we=92re suggesting this as a way = > forward to resolve the issues. > > Add the terms PCN-admissible-rate and PCN-supportable-rate as = > additional terminology. Don=92t make wholesale text changes to the doc, = > but use these terms in a few paragraphs. Then post these to the list, = > and ask for comments. So this is the post with the changes and the asking! > > Thanks > > Phil > > S2 Terminology: > > Add: PCN-admissible-rate: the rate of PCN-traffic on a link up to = > which PCN admission control should accept new PCN-flows. > > Add: PCN-supportable-rate: the rate of PCN-traffic on a link down to = > which PCN flow termination should, if necessary, terminate already = > admitted PCN-flows. > > = > > S3: Benefits: > > Bullet 2: change =93The PCN-threshold-rate on each link can be chosen = > small enough that admitted traffic can still be carried after a = > rerouting in most failure cases=94 to =93The PCN-admissible-rate on each = > link can be chosen small enough that admitted traffic can still be = > carried after a rerouting in most failure cases=94 > > Bullet 9: change =93The PCN-excess-rate may be set below the maximum = > rate that PCN-traffic can be transmitted on a link=85=94 to =93The = > PCN-supportable-rate may be set below the maximum rate that = > PCN-traffic can be transmitted on a link=85=94 > > S4 Deployment scenarios: > > In Figure 1, under =93PCN-excess-rate=94 add =93(=3DPCN-supportable-rate)= =94 & = > under =93PCN-threshold-rate=94 add =93(=3DPCN-admissible-rate)=94 > > S6.1 Flow admission > > Change the first para from: > > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > threshold-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. The PCN-threshold- > rate is a parameter that can be configured by the operator and will > be set lower than the traffic rate at which the link becomes > congested and the node drops packets. > To: > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > admissible-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. With three encoding st= ates available, the PCN-threshold- > rate is configured by the operator as equal to the PCN-admissible-rate= on each link. It is set lower than the traffic rate at which the link beco= mes congested and the node drops packets. = > = > S6.2 Flow termination: > > Change the first para from: > > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-excess-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. The PCN-excess-rate is a parameter that can > be configured by the operator and may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > To: > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-supportable-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. With three encoding states available, the PC= N-excess-rate is configured by the operator as equal to the PCN-supportable= -rate on each link. It may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > = > S6.3 Flow admission and/or flow termination when there are only two PCN > encoding states: > 3^rd bullet, change: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set at the rate the admission control > mechanism needs to limit PCN-traffic to, as shown in Figure 2. > To: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as = shown in Figure 2. > = > In Figure 2: = > > under =93U*PCN-excess-rate=94 add =93(=3DPCN-supportable-rate)=94 & under = > =93PCN-excess-rate=94 add =93(=3DPCN-admissible-rate)=94 > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > = -- = Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 17 05:47:37 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E28E3A67EE; Fri, 17 Oct 2008 05:47:37 -0700 (PDT) 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 A7B713A67EE for ; Fri, 17 Oct 2008 05:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.266, 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 FaraReO1LtdA for ; Fri, 17 Oct 2008 05:47:35 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 019B83A6767 for ; Fri, 17 Oct 2008 05:47:34 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 13:48:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 13:47:56 +0100 Message-ID: In-Reply-To: <48F874B8.6070308@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture terminology Thread-Index: AckwSnlNeRxRiidSRWCRRtSgDnmWAwAC09Fg References: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> <48F874B8.6070308@informatik.uni-wuerzburg.de> From: To: , X-OriginalArrivalTime: 17 Oct 2008 12:48:01.0309 (UTC) FILETIME=[96DBFCD0:01C93056] Cc: pcn@ietf.org Subject: Re: [PCN] Architecture terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Firstly the changes are OK with me. I think perhaps this whole debate highlights (and is symptomatic of) something that Michael was getting at in his earlier email thread relating to the marking draft. To summarise that thread: PCN consists of 3 core ideas: methods of metering and marking packets, methods to convey those marks and a way to join all the pieces into a coherent whole in a given system (designed for a given deployment scenario). All these need separate documents. Over the top of all that lies the PCN architecture document which sets out an overall framework into which all the pieces have to fit. I think much of the current debate stems from the architecture document having to describe both an overall framework but also having to include at least some guidance on how to integrate all the pieces. It is this integration part that leads to the discussion between which terminology is best... Toby -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: 17 October 2008 12:19 To: Eardley,PL,Philip,CXR9 R Cc: pcn Subject: Re: [PCN] Architecture terminology Hi Phil, thanks a lot! Regards, Michael philip.eardley@bt.com wrote: > > I had a discussion with Steve and we're suggesting this as a way > forward to resolve the issues. > > Add the terms PCN-admissible-rate and PCN-supportable-rate as > additional terminology. Don't make wholesale text changes to the doc, > but use these terms in a few paragraphs. Then post these to the list, > and ask for comments. So this is the post with the changes and the asking! > > Thanks > > Phil > > S2 Terminology: > > Add: PCN-admissible-rate: the rate of PCN-traffic on a link up to > which PCN admission control should accept new PCN-flows. > > Add: PCN-supportable-rate: the rate of PCN-traffic on a link down to > which PCN flow termination should, if necessary, terminate already > admitted PCN-flows. > > > > S3: Benefits: > > Bullet 2: change "The PCN-threshold-rate on each link can be chosen > small enough that admitted traffic can still be carried after a > rerouting in most failure cases" to "The PCN-admissible-rate on each > link can be chosen small enough that admitted traffic can still be > carried after a rerouting in most failure cases" > > Bullet 9: change "The PCN-excess-rate may be set below the maximum > rate that PCN-traffic can be transmitted on a link..." to "The > PCN-supportable-rate may be set below the maximum rate that > PCN-traffic can be transmitted on a link..." > > S4 Deployment scenarios: > > In Figure 1, under "PCN-excess-rate" add "(=PCN-supportable-rate)" & > under "PCN-threshold-rate" add "(=PCN-admissible-rate)" > > S6.1 Flow admission > > Change the first para from: > > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > threshold-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. The PCN-threshold- > rate is a parameter that can be configured by the operator and will > be set lower than the traffic rate at which the link becomes > congested and the node drops packets. > To: > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > admissible-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. With three encoding states available, the PCN-threshold- > rate is configured by the operator as equal to the PCN-admissible-rate on each link. It is set lower than the traffic rate at which the link becomes congested and the node drops packets. > > S6.2 Flow termination: > > Change the first para from: > > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-excess-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. The PCN-excess-rate is a parameter that can > be configured by the operator and may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > To: > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-supportable-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. With three encoding states available, the PCN-excess-rate is configured by the operator as equal to the PCN-supportable-rate on each link. It may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > > S6.3 Flow admission and/or flow termination when there are only two PCN > encoding states: > 3^rd bullet, change: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set at the rate the admission control > mechanism needs to limit PCN-traffic to, as shown in Figure 2. > To: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as shown in Figure 2. > > In Figure 2: > > under "U*PCN-excess-rate" add "(=PCN-supportable-rate)" & under > "PCN-excess-rate" add "(=PCN-admissible-rate)" > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Oct 19 17:18:08 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8053A693B; Sun, 19 Oct 2008 17:18:08 -0700 (PDT) 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 058A73A693B for ; Sun, 19 Oct 2008 17:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.86 X-Spam-Level: *** X-Spam-Status: No, score=3.86 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE4VymHHqNzg for ; Sun, 19 Oct 2008 17:18:06 -0700 (PDT) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id C12553A68BD for ; Sun, 19 Oct 2008 17:18:05 -0700 (PDT) Received: (qmail 39480 invoked by alias); 20 Oct 2008 00:19:15 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 20 Oct 2008 00:19:15 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m9K0JDOM009097 for ; Mon, 20 Oct 2008 09:19:14 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m9K0JDE7098022 for ; Mon, 20 Oct 2008 09:19:13 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: from [192.168.21.66] (ip21-066.tec.ntt-at.co.jp [192.168.21.66]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id BD16453F61; Mon, 20 Oct 2008 09:19:13 +0900 (JST) Date: Mon, 20 Oct 2008 09:18:42 +0900 From: =?ISO-2022-JP?B?GyRCOjRGIyEhQmdKZRsoQg==?= To: pcn@ietf.org Message-Id: <20081020091653.3D7A.26AD349@ntt-at.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] Subject: Re: [PCN] Architecture terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, Thank you very much. Best regards, Daisuke > > I had a discussion with Steve and we?re suggesting this as a way > forward to resolve the issues. > > Add the terms PCN-admissible-rate and PCN-supportable-rate as > additional terminology. Don?t make wholesale text changes to the doc, > but use these terms in a few paragraphs. Then post these to the list, > and ask for comments. So this is the post with the changes and the asking! > > Thanks > > Phil > > S2 Terminology: > > Add: PCN-admissible-rate: the rate of PCN-traffic on a link up to > which PCN admission control should accept new PCN-flows. > > Add: PCN-supportable-rate: the rate of PCN-traffic on a link down to > which PCN flow termination should, if necessary, terminate already > admitted PCN-flows. > > > > S3: Benefits: > > Bullet 2: change ?The PCN-threshold-rate on each link can be chosen > small enough that admitted traffic can still be carried after a > rerouting in most failure cases? to ?The PCN-admissible-rate on each > link can be chosen small enough that admitted traffic can still be > carried after a rerouting in most failure cases? > > Bullet 9: change ?The PCN-excess-rate may be set below the maximum > rate that PCN-traffic can be transmitted on a link?? to ?The > PCN-supportable-rate may be set below the maximum rate that > PCN-traffic can be transmitted on a link?? > > S4 Deployment scenarios: > > In Figure 1, under ?PCN-excess-rate? add ?(=PCN-supportable-rate)? & > under ?PCN-threshold-rate? add ?(=PCN-admissible-rate)? > > S6.1 Flow admission > > Change the first para from: > > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > threshold-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. The PCN-threshold- > rate is a parameter that can be configured by the operator and will > be set lower than the traffic rate at which the link becomes > congested and the node drops packets. > To: > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > admissible-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. With three encoding states available, the PCN-threshold- > rate is configured by the operator as equal to the PCN-admissible-rate on each link. It is set lower than the traffic rate at which the link becomes congested and the node drops packets. > > S6.2 Flow termination: > > Change the first para from: > > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-excess-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. The PCN-excess-rate is a parameter that can > be configured by the operator and may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > To: > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-supportable-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. With three encoding states available, the PCN-excess-rate is configured by the operator as equal to the PCN-supportable-rate on each link. It may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > > S6.3 Flow admission and/or flow termination when there are only two PCN > encoding states: > 3^rd bullet, change: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set at the rate the admission control > mechanism needs to limit PCN-traffic to, as shown in Figure 2. > To: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as shown in Figure 2. > > In Figure 2: > > under ?U*PCN-excess-rate? add ?(=PCN-supportable-rate)? & under > ?PCN-excess-rate? add ?(=PCN-admissible-rate)? > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Oct 19 19:48:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0130D3A68C0; Sun, 19 Oct 2008 19:48:03 -0700 (PDT) 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 2056A3A68C0 for ; Sun, 19 Oct 2008 19:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 lda7t5NtgUB1 for ; Sun, 19 Oct 2008 19:48:01 -0700 (PDT) Received: from smtp114.rog.mail.re2.yahoo.com (smtp114.rog.mail.re2.yahoo.com [68.142.225.230]) by core3.amsl.com (Postfix) with SMTP id CC4F23A6806 for ; Sun, 19 Oct 2008 19:48:00 -0700 (PDT) Received: (qmail 81647 invoked from network); 20 Oct 2008 02:49:10 -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=dpXQBmeKOWNB2utdhIvKPCVkcXx5S+6x6vRTOarb78mEfpsfeSD+hmfM0gKP0JGxjYNrp6SFsAFJ53k8P9w9v0Gd7G20QJE3BGqePxK7+Z+G6V9nMMDA786cmd5ZYj5+O0uM0TJyteHCP7rtnYDH9ZFja+Du8doQzEZ7abXEJRY= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp114.rog.mail.re2.yahoo.com with SMTP; 20 Oct 2008 02:49:10 -0000 X-YMail-OSG: 4lUiCAIVM1ltqKpROFkiMdswOR9nU3vYwB45fhcVIX8mIyBnyyfPC7DNCeYP9cf0qw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FBF1A7.7090105@rogers.com> Date: Sun, 19 Oct 2008 22:49:11 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA39B@E03MVB1-UKBR.domain1.systemhost.net> Cc: pcn@ietf.org Subject: Re: [PCN] Architecture terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org ... and I'll join the chorus of agreement. philip.eardley@bt.com wrote: > I had a discussion with Steve and we're suggesting this as a way forward > to resolve the issues. > > Add the terms PCN-admissible-rate and PCN-supportable-rate as additional > terminology. Don't make wholesale text changes to the doc, but use these > terms in a few paragraphs. Then post these to the list, and ask for > comments. So this is the post with the changes and the asking! > > Thanks > > Phil > > > > S2 Terminology: > > Add: PCN-admissible-rate: the rate of PCN-traffic on a link up to which > PCN admission control should accept new PCN-flows. > > Add: PCN-supportable-rate: the rate of PCN-traffic on a link down to > which PCN flow termination should, if necessary, terminate already > admitted PCN-flows. > > > > S3: Benefits: > > Bullet 2: change "The PCN-threshold-rate on each link can be chosen > small enough that admitted traffic can still be carried after a > rerouting in most failure cases" to "The PCN-admissible-rate on each > link can be chosen small enough that admitted traffic can still be > carried after a rerouting in most failure cases" > > > > Bullet 9: change "The PCN-excess-rate may be set below the maximum rate > that PCN-traffic can be transmitted on a link..." to "The > PCN-supportable-rate may be set below the maximum rate that PCN-traffic > can be transmitted on a link..." > > > > S4 Deployment scenarios: > > In Figure 1, under "PCN-excess-rate" add "(=PCN-supportable-rate)" & > under "PCN-threshold-rate" add "(=PCN-admissible-rate)" > > > > S6.1 Flow admission > > Change the first para from: > > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > threshold-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. The PCN-threshold- > rate is a parameter that can be configured by the operator and will > be set lower than the traffic rate at which the link becomes > congested and the node drops packets. > To: > The objective of PCN's flow admission control mechanism is to limit > the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- > admissible-rate, by admitting or blocking prospective new flows, in > order to protect the QoS of existing PCN-flows. With three encoding > states available, the PCN-threshold- > rate is configured by the operator as equal to the > PCN-admissible-rate on each link. It is set lower than the traffic rate > at which the link becomes congested and the node drops packets. > > S6.2 Flow termination: > > Change the first para from: > > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-excess-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. The PCN-excess-rate is a parameter that can > be configured by the operator and may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > To: > The objective of PCN's flow termination mechanism is to limit the > PCN-traffic on each link to *roughly* its PCN-supportable-rate, by > terminating some existing PCN-flows, in order to protect the QoS of > the remaining PCN-flows. With three encoding states available, the > PCN-excess-rate is configured by the operator as equal to the > PCN-supportable-rate on each link. It may be set lower than the traffic > rate at which the link becomes congested and the node drops packets. > > S6.3 Flow admission and/or flow termination when there are only two PCN > encoding states: > 3rd bullet, change: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set at the rate the admission control > mechanism needs to limit PCN-traffic to, as shown in Figure 2. > To: > o both admission control and flow termination: only the excess- > traffic-marking algorithm writes PCN-marks, however the configured > rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as > shown in Figure 2. > > In Figure 2: > > under "U*PCN-excess-rate" add "(=PCN-supportable-rate)" & under > "PCN-excess-rate" add "(=PCN-admissible-rate)" > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 20 03:30:05 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816F928C103; Mon, 20 Oct 2008 03:30:05 -0700 (PDT) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 66C213A69B5; Mon, 20 Oct 2008 03:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081020103001.66C213A69B5@core3.amsl.com> Date: Mon, 20 Oct 2008 03:30:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-08.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --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-08.txt Pages : 57 Date : 2008-10-20 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-08.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-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-20032356.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --NextPart-- From pcn-bounces@ietf.org Mon Oct 20 03:48:58 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B41C3A68FF; Mon, 20 Oct 2008 03:48:58 -0700 (PDT) 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 BEAAA3A68FF; Mon, 20 Oct 2008 03:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=0.537, 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 PTYfNlTG9AH8; Mon, 20 Oct 2008 03:48:56 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id ACD9B3A68DC; Mon, 20 Oct 2008 03:48:55 -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); Mon, 20 Oct 2008 11:49:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 11:49:04 +0100 Message-ID: In-Reply-To: <48F6069D.3060302@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Solicting interest in update of ECN handling around tunnels Thread-Index: Acku13KNpSS2X2eBTHuGN747Z77Z2QDyDX3w References: <48F6069D.3060302@ericsson.com> From: To: , , X-OriginalArrivalTime: 20 Oct 2008 10:49:05.0908 (UTC) FILETIME=[79117340:01C932A1] Subject: Re: [PCN] Solicting interest in update of ECN handling around tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org As I said before I strongly support this being adopted as a TSVWG workgroup= . This work is necessary to correct an anomaly that currently exists betwee= n RFC 3168 and RFC 4301. This has implications for any PCN encoding scheme as any scheme will be har= med by the presence of 3168 tunnels (of either flavour). The anomaly also m= akes it impossible for a vendor to comply with both 3168 and 4301 at the sa= me time... Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 = -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Magnu= s Westerlund Sent: 15 October 2008 16:05 To: iccrg@irtf.org; pcn Subject: [PCN] Solicting interest in update of ECN handling around tunnels ICCRG and PCN WG, This is an solicitation of interest for doing work in TSVWG around updating the ECN handling for tunnels along the lines of http://tools.ietf.org/id/draft-briscoe-tsvwg-ecn-tunnel-01.txt More specifically we are considering to adopt this document as a WG item. Please provide any feedback to the TSVWG (tsvwg@ietf.org) Thanks Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 20 03:56:07 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383873A69DA; Mon, 20 Oct 2008 03:56:07 -0700 (PDT) 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 C820A3A6998 for ; Mon, 20 Oct 2008 03:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.306 X-Spam-Level: X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 Rgzx32zKr3vA for ; Mon, 20 Oct 2008 03:56:06 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B01FB3A69DD for ; Mon, 20 Oct 2008 03:56:05 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 11:57:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 11:57:14 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3A7@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20081020103001.66C213A69B5@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-architecture-08.txt Thread-Index: Ackyn1xAlaxmIc08TXO2KiYbVebhnAAAHcTw From: To: X-OriginalArrivalTime: 20 Oct 2008 10:57:15.0247 (UTC) FILETIME=[9CBCA7F0:01C932A2] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-architecture-08.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org http://tools.ietf.org/html/draft-ietf-pcn-architecture-08 This updates with all the comments from the 2nd WGLC:- o Section 2: added definition for PCN-admissible-rate and PCN- supportable-rate. Small changes to use these terms as follows: Section 3, bullets 2 & 9; S6.1 para 1; S6.2 para1; S6.3 bullet 3; added to Figs 1 & 2. o added the phrase "(others might be possible") before the list of approaches in Section 6.3, 7.4 & 7.5. o added references to RFC2753 (A framework for policy-based admission control) in S7.4 & S7.5. o throughout, updated references now that marking behaviour & baseline encoding are WG drafts. o a few typos corrected changes also can be seen at http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-p cn-architecture-08.txt thanks phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Internet-Drafts@ietf.org { Sent: 20 October 2008 11:30 { To: i-d-announce@ietf.org { Cc: pcn@ietf.org { Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-08.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-08.txt { Pages : 57 { Date : 2008-10-20 { { 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-08.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 From pcn-bounces@ietf.org Mon Oct 20 04:48:36 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF673A698C; Mon, 20 Oct 2008 04:48:36 -0700 (PDT) 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 EA7CB3A6919; Mon, 20 Oct 2008 04:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 DsQg8m+Y9wBM; Mon, 20 Oct 2008 04:48:33 -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 D6D763A6915; Mon, 20 Oct 2008 04:48:32 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 62B3F198E06; Mon, 20 Oct 2008 13:19:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 53FC1198E05; Mon, 20 Oct 2008 13:19:50 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 393D7198DFC; Mon, 20 Oct 2008 13:19:50 +0200 (CEST) Message-ID: <48FC68F4.2070308@informatik.uni-wuerzburg.de> Date: Mon, 20 Oct 2008 13:18:12 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <48F6069D.3060302@ericsson.com> In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, iccrg@irtf.org, tsvwg@ietf.org Subject: Re: [PCN] [Tsvwg] Solicting interest in update of ECN handling around tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I also support this document for the same reasons as Toby. Regards, Michael toby.moncaster@bt.com wrote: > As I said before I strongly support this being adopted as a TSVWG workgro= up. This work is necessary to correct an anomaly that currently exists betw= een RFC 3168 and RFC 4301. > > This has implications for any PCN encoding scheme as any scheme will be h= armed by the presence of 3168 tunnels (of either flavour). The anomaly also= makes it impossible for a vendor to comply with both 3168 and 4301 at the = same time... > > Toby > > ____________________________________________________________________ > Toby Moncaster, Networks Research Centre, BT > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 = > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Mag= nus Westerlund > Sent: 15 October 2008 16:05 > To: iccrg@irtf.org; pcn > Subject: [PCN] Solicting interest in update of ECN handling around tunnels > > ICCRG and PCN WG, > > This is an solicitation of interest for doing work in TSVWG around > updating the ECN handling for tunnels along the lines of > http://tools.ietf.org/id/draft-briscoe-tsvwg-ecn-tunnel-01.txt > > More specifically we are considering to adopt this document as a WG item. > > Please provide any feedback to the TSVWG (tsvwg@ietf.org) > > Thanks > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > = -- = Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 20 06:30:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3643A69D2; Mon, 20 Oct 2008 06:30:02 -0700 (PDT) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E29893A6A10; Mon, 20 Oct 2008 06: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: <20081020133001.E29893A6A10@core3.amsl.com> Date: Mon, 20 Oct 2008 06:30:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --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 : Marking behaviour of PCN-nodes Author(s) : P. Eardley Filename : draft-ietf-pcn-marking-behaviour-01.txt Pages : 19 Date : 2008-10-20 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 its configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of its configured 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-01.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-marking-behaviour-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-20061608.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --NextPart-- From pcn-bounces@ietf.org Mon Oct 20 06:39:08 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104F03A6A10; Mon, 20 Oct 2008 06:39:08 -0700 (PDT) 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 8748B3A6A10 for ; Mon, 20 Oct 2008 06:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 fLPcB7V91TK9 for ; Mon, 20 Oct 2008 06:39:06 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 778B13A687E for ; Mon, 20 Oct 2008 06:39:06 -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); Mon, 20 Oct 2008 14:40:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 14:40:16 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3AC@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20081020133001.E29893A6A10@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt Thread-Index: AckyuCZI7es/JACQRg6f8fVnLDgrFQAAKbpQ From: To: X-OriginalArrivalTime: 20 Oct 2008 13:40:17.0130 (UTC) FILETIME=[63318CA0:01C932B9] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi I updated the doc to take account of Michael's comments (thanks!) and a few things I spotted. Changes are clarifications etc - no changes in the MUSTs etc My intent at the Minneapolis meeting is to ask for WG last call. So any comments before then appreciated. Thanks Phil http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01 { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Internet-Drafts@ietf.org { Sent: 20 October 2008 14:30 { To: i-d-announce@ietf.org { Cc: pcn@ietf.org { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.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-01.txt { Pages : 19 { Date : 2008-10-20 { { 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 its { configured rate. Excess traffic marking marks a proportion of PCN- { packets, such that the amount marked equals the traffic rate in { excess of its configured 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- { 01.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 From pcn-bounces@ietf.org Mon Oct 20 23:44:51 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36593A6A24; Mon, 20 Oct 2008 23:44:51 -0700 (PDT) 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 B11F73A6A04 for ; Mon, 20 Oct 2008 23:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 nE1WJ+RXeHIb for ; Mon, 20 Oct 2008 23:44:49 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id D71323A69F7 for ; Mon, 20 Oct 2008 23:44:48 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Tue, 21 Oct 2008 08:46:01 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 08:46:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 08:46:00 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01E206AD@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <48F5EB06.3080109@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 thread-index: Ackux0FpidxJJW/xSRafoA8blPM8RgDt9Vbw References: <4A916DBC72536E419A0BD955EDECEDEC03DAA367@E03MVB1-UKBR.domain1.systemhost.net> <48F5EB06.3080109@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Oct 2008 06:46:00.0913 (UTC) FILETIME=[AE259410:01C93348] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael, your proposal 1. below sounds better to me than proposal 2. To ensure useful standardisation results, the WG should define a PCN cookbook (a defined structure of a PCN realisation, the structure should be standards track) and provide at least on example of a PCN recipe (you call it deployment scenario, should be informational - unless the WG succeeds in consenting on a single one). I'm not sure, whether the architecture doc is that cookbook or is meant to become it. It may be a better idea to work with the architecture doc as a framework and later, after we have RFCs on coding, marking and so on, indicate how to build a PCN solution. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: Wednesday, October 15, 2008 3:07 PM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 Hi Phil, I think you understood my point. I try to clarify a bit more what I and possibly you also mean. Marking documents should cover only the individual behavior of the markers and not reveal too many specifics about their exact application in specific PCN deployment scenarios. Input: set of packets to be metered, set of packets to be marked Output: set of marked packets The encoding documents should define the codepoints, explain their semantics, and give constraints about their usage. Documents about deployment scenarios should describe the behavior of PCN nodes, the correct configuration of the markers and bind their action to the specific encoding. This document should give the glue, i.e. it tells how conditioning is done, which meters and markers are used and configured with which reference rates, which packets are input for the meters and markers, and how metering results are translated into encodings. There are two major possibilities for the description of a specific PCN architecture. 1. Provide marking and encoding drafts as generic building blocks. An additional document explains how they are used in a specific deployment scenario. There may be one deployment scenario or more, depending on whether a single one covers all needs. The current objective of the group is to define one deployment scenario and keep the door open for others just in case the one does not satisfy the application scenarios. That's at least my understanding. 2. Provide marking and encoding drafts as parts of a specific deployment scenario. This degrades readability of the documents and prevents simple extension of PCN since the building blocks are not generic and must be changed to describe alternative deployment scenarios. Currently I see that the second path is taken because the marking draft contains a lot deployment specific assumptions. I don't know whether this happened intentionally or not. Regards, Michael philip.eardley@bt.com wrote: > Toby, > > Michael has brought up what I think is a good suggestion in the context > of the marking behaviour draft > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-00 > > { =================================================== > { > { Section 2.5 > { > { This section describes the required joint behavior of excess and > threshold > { markers in specific deployment scenarios. Doing that in the main body > of > { the documents sounds like excluding other use, e.g. for > packet-specific > { dual > { marking which allows the implementation of a CL-like admission control > and > { flow termination with only a single DSCP. I suggest decoupling the > { description > { of the meter and marker functions from their joint behavior which > depends > { on > { the specific encoding. > > I sympathise with michael's point. I'm inclined to think that most of > the current text in S2.5 of ietf-pcn-marking-behaviour-00 would fit > better in the baseline encoding draft. I think it would fit naturally > into your text about encoding transitions (current Appendix B). at the > moment the table just gives what the valid transitions are - this would > be expanded by saying in more detail which specific transitions are > valid depending on what the meters say. > > In answer to your question about App B "The PCN working group needs to > decide whether to > include this in this baseline encoding or whether to transfer it to > an alternative document." > I think michael's point & PSDM example means that it needs to be > specified in each encoding document. You could say this in S5 (Rules for > Experimental Encoding Schemes) ie require extensions to specify > similarly what the encoding transitions are depending on the state of > the 2 meters. > > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { toby.moncaster@bt.com > { Sent: 14 October 2008 15:52 > { To: pcn@ietf.org > { Subject: Re: [PCN] New Version Notification > fordraft-ietf-pcn-baseline- > { encoding-01 > { > { As promised I have uploaded a new version. I am aware there are a > handful > { of typos and spelling mistakes that I noticed just after uploading. I > will > { correct these in the next version. I am now pretty happy with almost > all > { the text. > { > { The key section for the WG to note is Appendix B where I have put in a > { couple of questions that I would welcome input on. > { > { The first of these is where to put the text (now set out as a table) > about > { valid and invalid transitions at PCN nodes? Should this be part of the > { baseline encoding or should it be split between a new edge node > behaviour > { document and Phil's marking behaviour. > { > { The second question relates to how to best handle the unexpected > presence > { of the EXP codepoint. There is a potential for this to happen during > any > { partial deployment of an experimental encoding extension scheme. > Whilst it > { would be best for an operator to ensure all nodes run the same > encoding > { there is a chance this might not happen. The best solution as I see it > is > { for the baseline scheme to treat EXP the same as NM but to raise a > { management alarm... > { > { I have also highlighted another point in Appendix A which needs a > { decision: should we as a WG recommend that RFC3168 full functionality > { tunnels SHOULD NOT be used in a PCN-domain or would it be better to > put > { our collective voices behind Bob's attempts to correct the anomalous > { behaviour of tunnels which he is currently trying to push through > TSVWG > { (draft-briscoe-tsvwg-ecn-tunnel-01) > { > { Toby > { > { -----Original Message----- > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > { Sent: 14 October 2008 15:35 > { 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-01 > { > { > { A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been > { successfuly submitted by T Moncaster and posted to the IETF > repository. > { > { Filename: draft-ietf-pcn-baseline-encoding > { Revision: 01 > { Title: Baseline Encoding and Transport of > Pre-Congestion > { Information > { Creation_date: 2008-10-14 > { WG ID: pcn > { Number_of_pages: 12 > { > { Abstract: > { Pre-congestion notification (PCN) provides information to support > { admission control and flow termination in order to protect the > { Quality of Service of inelastic flows. It does this by marking > { packets when traffic load on a link is approaching or has exceeded a > { threshold below the physical link rate. This document specifies how > { such marks are to be encoded into the IP header. The baseline > { encoding described here provides for only two PCN encoding states. > { It is designed to be easily extended to provide more encoding states > { but such schemes will be described in other documents. > { > { > { > { The IETF Secretariat. > { > { > { _______________________________________________ > { PCN mailing list > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 20 23:46:15 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FD13A6A04; Mon, 20 Oct 2008 23:46:15 -0700 (PDT) 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 5667D3A69F7 for ; Mon, 20 Oct 2008 23:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 YvYli2djZS3G for ; Mon, 20 Oct 2008 23:46:14 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id E716B3A69D0 for ; Mon, 20 Oct 2008 23:46:13 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Tue, 21 Oct 2008 08:47:27 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 08:47:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 08:47:26 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 thread-index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jgAR1FfnA= References: From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Oct 2008 06:47:26.0824 (UTC) FILETIME=[E15A8E80:01C93348] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Toby, thanks for adding more content in the reviewed version. Apart from my support of Michaels proposal 1., I still would like to comment on some of your new text: Appendix B, Table 2, row "ingress" If "PM" is an invalid codepoint out, then the ingress node does not belong to the PCN domain. As far as I understood, indication of pre-congestion on a link is signaled by a PM mark. The ingress node following your specification in row "ingress" however can't signal pre-congestion. Specifying behaviours for unexpected codepoints is a necessity and writing down this requirement adds value to the document. The question is, whether forward compatibility benefits from handling EXP as NM. The whole topic is in fact a marking issue, and there it should be dealt with. Thoughts on your proposal: - Could a future extension exist, where there's no transition from EXP to PM? Then your proposal is harmful. - What you don't discuss, as you are writing the encoding draft, is whether the EXP packets should be metered by an interior node just supporting baseline encoding. I think they should be. But may be, I'm wrong and all of this discussion on receiving packets with unexpected codings and backward/forward compatibility should be a requirement for a PCN deployment scenario document. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com Sent: Tuesday, October 14, 2008 4:52 PM To: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 As promised I have uploaded a new version. I am aware there are a handful of typos and spelling mistakes that I noticed just after uploading. I will correct these in the next version. I am now pretty happy with almost all the text. The key section for the WG to note is Appendix B where I have put in a couple of questions that I would welcome input on. The first of these is where to put the text (now set out as a table) about valid and invalid transitions at PCN nodes? Should this be part of the baseline encoding or should it be split between a new edge node behaviour document and Phil's marking behaviour. The second question relates to how to best handle the unexpected presence of the EXP codepoint. There is a potential for this to happen during any partial deployment of an experimental encoding extension scheme. Whilst it would be best for an operator to ensure all nodes run the same encoding there is a chance this might not happen. The best solution as I see it is for the baseline scheme to treat EXP the same as NM but to raise a management alarm... I have also highlighted another point in Appendix A which needs a decision: should we as a WG recommend that RFC3168 full functionality tunnels SHOULD NOT be used in a PCN-domain or would it be better to put our collective voices behind Bob's attempts to correct the anomalous behaviour of tunnels which he is currently trying to push through TSVWG (draft-briscoe-tsvwg-ecn-tunnel-01) Toby -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 14 October 2008 15:35 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-01 A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-ietf-pcn-baseline-encoding Revision: 01 Title: Baseline Encoding and Transport of Pre-Congestion Information Creation_date: 2008-10-14 WG ID: pcn Number_of_pages: 12 Abstract: Pre-congestion notification (PCN) provides information to support admission control and flow termination in order to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for only two PCN encoding states. It is designed to be easily extended to provide more encoding states but such schemes will be described in other documents. The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 01:36:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC5A3A6B46; Tue, 21 Oct 2008 01:36:02 -0700 (PDT) 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 A11B33A6924 for ; Tue, 21 Oct 2008 01:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSmS99neCjJp for ; Tue, 21 Oct 2008 01:35:57 -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 C97D93A6B4E for ; Tue, 21 Oct 2008 01:35:37 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 06D60A069A; Tue, 21 Oct 2008 10:36:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id EE0E2A068C; Tue, 21 Oct 2008 10:36:45 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D0E4A198E3C; Tue, 21 Oct 2008 10:36:45 +0200 (CEST) Message-ID: <48FD943B.6030603@informatik.uni-wuerzburg.de> Date: Tue, 21 Oct 2008 10:35:07 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Geib, Ruediger" References: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger, my thinking is what you also suspect at the end of your email: the description of the packets to be metered and the packets to be re-marked is part of the deployment model and meters and markers must be configurable with regard to this respect. The same applies to drop preferences. It does not mean that anything can be done in PCN. The restrictions come through the deployment models that say which building blocks MUST be used and how they MUST be configured. Then, metering and marking can be kept general and encoding does not need to know anything about its future use. Regards, Michael Geib, Ruediger wrote: > Toby, > > thanks for adding more content in the reviewed version. Apart from my > support of Michaels proposal 1., I still would like to comment on > some of your new text: > > Appendix B, Table 2, row "ingress" > > If "PM" is an invalid codepoint out, then the ingress node does not > belong to the PCN domain. As far as I understood, indication of > pre-congestion on a link is signaled by a PM mark. The ingress > node following your specification in row "ingress" however > can't signal pre-congestion. > > Specifying behaviours for unexpected codepoints is a necessity and > writing down this requirement adds value to the document. The > question is, whether forward compatibility benefits from handling > EXP as NM. The whole topic is in fact a marking issue, and there > it should be dealt with. Thoughts on your proposal: > - Could a future extension exist, where there's no transition > from EXP to PM? Then your proposal is harmful. > - What you don't discuss, as you are writing the encoding draft, > is whether the EXP packets should be metered by an interior > node just supporting baseline encoding. I think they should be. > But may be, I'm wrong and all of this discussion on receiving > packets with unexpected codings and backward/forward > compatibility should be a requirement for a PCN deployment > scenario document. > > Regards, > > Ruediger > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com > Sent: Tuesday, October 14, 2008 4:52 PM > To: pcn@ietf.org > Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 > > As promised I have uploaded a new version. I am aware there are a handful of typos and spelling mistakes that I noticed just after uploading. I will correct these in the next version. I am now pretty happy with almost all the text. > > The key section for the WG to note is Appendix B where I have put in a couple of questions that I would welcome input on. > > The first of these is where to put the text (now set out as a table) about valid and invalid transitions at PCN nodes? Should this be part of the baseline encoding or should it be split between a new edge node behaviour document and Phil's marking behaviour. > > The second question relates to how to best handle the unexpected presence of the EXP codepoint. There is a potential for this to happen during any partial deployment of an experimental encoding extension scheme. Whilst it would be best for an operator to ensure all nodes run the same encoding there is a chance this might not happen. The best solution as I see it is for the baseline scheme to treat EXP the same as NM but to raise a management alarm... > > I have also highlighted another point in Appendix A which needs a decision: should we as a WG recommend that RFC3168 full functionality tunnels SHOULD NOT be used in a PCN-domain or would it be better to put our collective voices behind Bob's attempts to correct the anomalous behaviour of tunnels which he is currently trying to push through TSVWG (draft-briscoe-tsvwg-ecn-tunnel-01) > > Toby > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 14 October 2008 15:35 > 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-01 > > > A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. > > Filename: draft-ietf-pcn-baseline-encoding > Revision: 01 > Title: Baseline Encoding and Transport of Pre-Congestion Information > Creation_date: 2008-10-14 > WG ID: pcn > Number_of_pages: 12 > > Abstract: > Pre-congestion notification (PCN) provides information to support > admission control and flow termination in order to protect the > Quality of Service of inelastic flows. It does this by marking > packets when traffic load on a link is approaching or has exceeded a > threshold below the physical link rate. This document specifies how > such marks are to be encoded into the IP header. The baseline > encoding described here provides for only two PCN encoding states. > It is designed to be easily extended to provide more encoding states > but such schemes will be described in other documents. > > > > The IETF Secretariat. > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 01:37:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454333A6AF2; Tue, 21 Oct 2008 01:37:42 -0700 (PDT) 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 BAE523A6B3D for ; Tue, 21 Oct 2008 01:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=-0.161, 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 dZ2MRXPXZQ-K for ; Tue, 21 Oct 2008 01:37:39 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 5359D3A6A2B for ; Tue, 21 Oct 2008 01:37:39 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 09:38:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 09:38:50 +0100 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jgAR1FfnAANcGeYA== References: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de> From: To: X-OriginalArrivalTime: 21 Oct 2008 08:38:52.0191 (UTC) FILETIME=[72249AF0:01C93358] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger, My argument for making PM an invalid transition for a PCN-ingress node is that in my head I have a conceptual model that views the PCN region as consisting of a number of nodes that do PCN marking surrounded by a fence of PCN-boundary nodes. These boundary nodes simply control ingress and egress from the region and don't actually do any marking. Of course in practise the ingress and egress nodes would also have marking functionality but it is easier to think of them as separate nodes. As far as I know there is no current proposed extension where EXP can't be marked to PM. Even in Bob's proposal with fully working tunnels EXP could be remarked to PM. The question I had in my head was the other way round: If we don't specify a behaviour for EXP in the baseline will extension encodings still work if any nodes haven't been upgraded? The answer to that seemed to be "no" for the majority of proposals (apart from the simple variant of 3 state encoding). As you say we also need to decide what to do with EXP packets regarding metering. I think as currently written Phil's draft allows them to be metered but I will check that with him. Toby -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: 21 October 2008 07:47 To: Moncaster,T,Toby,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 Toby, thanks for adding more content in the reviewed version. Apart from my support of Michaels proposal 1., I still would like to comment on some of your new text: Appendix B, Table 2, row "ingress" If "PM" is an invalid codepoint out, then the ingress node does not belong to the PCN domain. As far as I understood, indication of pre-congestion on a link is signaled by a PM mark. The ingress node following your specification in row "ingress" however can't signal pre-congestion. Specifying behaviours for unexpected codepoints is a necessity and writing down this requirement adds value to the document. The question is, whether forward compatibility benefits from handling EXP as NM. The whole topic is in fact a marking issue, and there it should be dealt with. Thoughts on your proposal: - Could a future extension exist, where there's no transition from EXP to PM? Then your proposal is harmful. - What you don't discuss, as you are writing the encoding draft, is whether the EXP packets should be metered by an interior node just supporting baseline encoding. I think they should be. But may be, I'm wrong and all of this discussion on receiving packets with unexpected codings and backward/forward compatibility should be a requirement for a PCN deployment scenario document. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com Sent: Tuesday, October 14, 2008 4:52 PM To: pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 As promised I have uploaded a new version. I am aware there are a handful of typos and spelling mistakes that I noticed just after uploading. I will correct these in the next version. I am now pretty happy with almost all the text. The key section for the WG to note is Appendix B where I have put in a couple of questions that I would welcome input on. The first of these is where to put the text (now set out as a table) about valid and invalid transitions at PCN nodes? Should this be part of the baseline encoding or should it be split between a new edge node behaviour document and Phil's marking behaviour. The second question relates to how to best handle the unexpected presence of the EXP codepoint. There is a potential for this to happen during any partial deployment of an experimental encoding extension scheme. Whilst it would be best for an operator to ensure all nodes run the same encoding there is a chance this might not happen. The best solution as I see it is for the baseline scheme to treat EXP the same as NM but to raise a management alarm... I have also highlighted another point in Appendix A which needs a decision: should we as a WG recommend that RFC3168 full functionality tunnels SHOULD NOT be used in a PCN-domain or would it be better to put our collective voices behind Bob's attempts to correct the anomalous behaviour of tunnels which he is currently trying to push through TSVWG (draft-briscoe-tsvwg-ecn-tunnel-01) Toby -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 14 October 2008 15:35 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-01 A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-ietf-pcn-baseline-encoding Revision: 01 Title: Baseline Encoding and Transport of Pre-Congestion Information Creation_date: 2008-10-14 WG ID: pcn Number_of_pages: 12 Abstract: Pre-congestion notification (PCN) provides information to support admission control and flow termination in order to protect the Quality of Service of inelastic flows. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This document specifies how such marks are to be encoded into the IP header. The baseline encoding described here provides for only two PCN encoding states. It is designed to be easily extended to provide more encoding states but such schemes will be described in other documents. The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 02:15:39 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7681D3A69E0; Tue, 21 Oct 2008 02:15:39 -0700 (PDT) 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 8E9F43A69E0 for ; Tue, 21 Oct 2008 02:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 aG3exAmaKSHs for ; Tue, 21 Oct 2008 02:15:37 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 9C12A3A6874 for ; Tue, 21 Oct 2008 02:15:37 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:16:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 10:16:47 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3BD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notificationfordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jgAR1FfnAANcGeYAABfU0A From: To: , X-OriginalArrivalTime: 21 Oct 2008 09:16:48.0653 (UTC) FILETIME=[BF0523D0:01C9335D] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notificationfordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { { As you say we also need to decide what to do with EXP packets regarding { metering. I think as currently written Phil's draft allows them to be { metered but I will check that with him. { PCN-pkts with EXP encoding are still PCN-pkts. Therefore they MUST be treated as a metered-pkt. Quotes from http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01 o Metered-packet: a packet that is metered by the metering functions specified below. A PCN-packet MUST be treated as a metered-packet (with the minor exception noted below in Section 2.4). A PCN-node MUST classify a packet as a PCN-packet if the value of its DSCP and ECN fields correspond to a PCN-enabled codepoint, as defined in the encoding scheme applicable to the PCN-domain. Otherwise the packet MUST NOT be classified as a PCN-packet. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 02:28:24 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40EA3A6B43; Tue, 21 Oct 2008 02:28:24 -0700 (PDT) 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 031893A6B41 for ; Tue, 21 Oct 2008 02:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 fH8nZuLG4PcS for ; Tue, 21 Oct 2008 02:28:22 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id F26433A6AB8 for ; Tue, 21 Oct 2008 02:28:21 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:29:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 10:29:23 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3BE@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48FD943B.6030603@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQ From: To: , X-OriginalArrivalTime: 21 Oct 2008 09:29:25.0579 (UTC) FILETIME=[822EE1B0:01C9335F] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { { my thinking is what you also suspect at the end of your email: the { description of the packets to be metered and the packets to be re-marked { is part of the deployment model and meters and markers must be { configurable with regard to this respect. The same applies to drop { preferences. It does not mean that anything can be done in PCN. The { restrictions come through the deployment models that say which building { blocks MUST be used and how they MUST be configured. Then, metering and { marking can be kept general and encoding does not need to know anything { about its future use. I disagree with this to some extent. I think that what pkts are metered and what re-marked is something to be standardised in the encoding drafts. This allows each to be carefully thought about and for manufacturers to say that their kit is conformant with a STD. putting this in a deployment model is not as good - there will (assuming pcn's success) potentially be many deployment models, and many deployment models based on a particular encoding. The framework is that the behaviour of the interior nodes (in terms of both marking behaviour & encoding) is simple and clear, without a whole lot of configurable options. Meanwhile, there's more freedom in terms of the behaviour of the gateways in how they interpret these marks. Of course it may turn out that in practice there are only a couple of good sets of gateway behaviour. Anyway, I read your email as proposing that the marking and encoding should allow lots of freedom with lots of configurable options, and that the deployment models should be where things are standardised in anger. I disagree with that. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 02:36:12 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF203A6A16; Tue, 21 Oct 2008 02:36:12 -0700 (PDT) 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 A528A3A68F0 for ; Tue, 21 Oct 2008 02:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 AUgNjEzxQlFn for ; Tue, 21 Oct 2008 02:36:10 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 7954B3A6A16 for ; Tue, 21 Oct 2008 02:36:10 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:37:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 10:37:17 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3BF@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Version Notificationfordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jgAR1FfnAAN9hTkA== From: To: X-OriginalArrivalTime: 21 Oct 2008 09:37:18.0755 (UTC) FILETIME=[9C37CF30:01C93360] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notificationfordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { The key section for the WG to note is Appendix B where I have put in a { couple of questions that I would welcome input on. { { The first of these is where to put the text (now set out as a table) about { valid and invalid transitions at PCN nodes? Should this be part of the { baseline encoding or should it be split between a new edge node behaviour { document and Phil's marking behaviour. My view is that this should be in the encoding drafts, as what transitions are valid depends on the encoding (eg the answer would be different for PSDM). However, I also think - since other encodings are seen as extensions of the baseline encoding - that the baseline should define what 'extensions' means - it presumably means that there are restrictions on those other encodings in terms of what transitions are valid, eg that 11 MUST correspond to some kind of PCN-marking. { { The second question relates to how to best handle the unexpected presence { of the EXP codepoint. There is a potential for this to happen during any { partial deployment of an experimental encoding extension scheme. Whilst it { would be best for an operator to ensure all nodes run the same encoding { there is a chance this might not happen. The best solution as I see it is { for the baseline scheme to treat EXP the same as NM but to raise a { management alarm... I think this is reasonable. { { I have also highlighted another point in Appendix A which needs a { decision: should we as a WG recommend that RFC3168 full functionality { tunnels SHOULD NOT be used in a PCN-domain or would it be better to put { our collective voices behind Bob's attempts to correct the anomalous { behaviour of tunnels which he is currently trying to push through TSVWG { (draft-briscoe-tsvwg-ecn-tunnel-01) 'should we recommend...' - don't know. 'should we put our collective voices..' - yes. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 03:12:12 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A3D3A6ACE; Tue, 21 Oct 2008 03:12:12 -0700 (PDT) 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 743CD3A67E7 for ; Tue, 21 Oct 2008 03:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 Xz2vO+pbeCk6 for ; Tue, 21 Oct 2008 03:12:10 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 1EE7A3A6B07 for ; Tue, 21 Oct 2008 03:12:09 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 21 Oct 2008 12:13:19 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 12:13:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 12:13:16 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01E20860@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3BE@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 thread-index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2A= References: <48FD943B.6030603@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA3BE@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Oct 2008 10:13:17.0163 (UTC) FILETIME=[A2BABBB0:01C93365] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, my view is, that the coding and marking as they are specified right now are = allright, but may have to be reduced to the bare functionality specified. = Examples of deployment models and references to documents specifying them could be given - but these should be teasers, no lengthy descriptions. Separate documents may discuss different deployment models. There and only = there, flexibility should be allowed. I also think, PCN should generally = leave room for experimental extensions (like PCN sucessfully does eg. = with experimental three codepoint marking schemes). = A question coming to my mind is, whether we are able to consent on further = standard ingress/egrees node functionalities apart from baseline coding = and marking behaviour. Egress measurement functions is one such topic. = The more such basic standard functionalities we can agree on, the better. My general philosophy is: define a common starting point. Leave room to = learn and adapt systems, once we all started from the common starting = point. What I dislike, and I think we aggree on that, is parallel = customisation of different solutions from start on. = Regards, Ruediger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] = Sent: Tuesday, October 21, 2008 11:29 AM To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encod= ing-01 { = { my thinking is what you also suspect at the end of your email: the { description of the packets to be metered and the packets to be re-marked { is part of the deployment model and meters and markers must be { configurable with regard to this respect. The same applies to drop { preferences. It does not mean that anything can be done in PCN. The { restrictions come through the deployment models that say which building { blocks MUST be used and how they MUST be configured. Then, metering and { marking can be kept general and encoding does not need to know anything { about its future use. I disagree with this to some extent. = I think that what pkts are metered and what re-marked is something to be standardised in the encoding drafts. This allows each to be carefully thought about and for manufacturers to say that their kit is conformant with a STD. putting this in a deployment model is not as good - there will (assuming pcn's success) potentially be many deployment models, and many deployment models based on a particular encoding. The framework is that the behaviour of the interior nodes (in terms of both marking behaviour & encoding) is simple and clear, without a whole lot of configurable options. Meanwhile, there's more freedom in terms of the behaviour of the gateways in how they interpret these marks. Of course it may turn out that in practice there are only a couple of good sets of gateway behaviour. Anyway, I read your email as proposing that the marking and encoding should allow lots of freedom with lots of configurable options, and that the deployment models should be where things are standardised in anger. I disagree with that. = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 03:35:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDDE33A6ACE; Tue, 21 Oct 2008 03:35:20 -0700 (PDT) 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 3DC9F3A680D for ; Tue, 21 Oct 2008 03:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 lDcyylBG-Pmt for ; Tue, 21 Oct 2008 03:35:15 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 212883A6A95 for ; Tue, 21 Oct 2008 03:35:14 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 11:36:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 11:36:26 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3C1@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E20860@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2AAAgG44A== From: To: X-OriginalArrivalTime: 21 Oct 2008 10:36:28.0510 (UTC) FILETIME=[E0096FE0:01C93368] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { -----Original Message----- { From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] { Sent: 21 October 2008 11:13 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Phil, { = { my view is, that the coding and marking as they are specified right now { are { allright, but may have to be reduced to the bare functionality specified. Not sure what you mean, what needs reducing? (not sure if this is cutting o= ut some of the MUSTS/SHOULDS or cutting some of the explanatory material) { Examples of deployment models and references to documents specifying them { could be given - but these should be teasers, no lengthy descriptions. Yes { = { Separate documents may discuss different deployment models. There and only { there, flexibility should be allowed. I also think, PCN should generally { leave room for experimental extensions (like PCN sucessfully does eg. { with experimental three codepoint marking schemes). Agree { = { A question coming to my mind is, whether we are able to consent on further { standard ingress/egrees node functionalities apart from baseline coding { and marking behaviour. Egress measurement functions is one such topic. That's an interesting question. It would certainly be nice. Perhaps one tha= t's easier to discuss f2f? { The more such basic standard functionalities we can agree on, the better. { = { My general philosophy is: define a common starting point. Leave room to { learn and adapt systems, once we all started from the common starting { point. What I dislike, and I think we aggree on that, is parallel { customisation of different solutions from start on. Agree! { = { Regards, { = { Ruediger { = { = { -----Original Message----- { From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { Sent: Tuesday, October 21, 2008 11:29 AM { To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger { Cc: pcn@ietf.org { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { { { { my thinking is what you also suspect at the end of your email: the { { description of the packets to be metered and the packets to be { re-marked { { is part of the deployment model and meters and markers must be { { configurable with regard to this respect. The same applies to drop { { preferences. It does not mean that anything can be done in PCN. The { { restrictions come through the deployment models that say which { building { { blocks MUST be used and how they MUST be configured. Then, metering { and { { marking can be kept general and encoding does not need to know { anything { { about its future use. { = { I disagree with this to some extent. { = { I think that what pkts are metered and what re-marked is something to be { standardised in the encoding drafts. This allows each to be carefully { thought about and for manufacturers to say that their kit is conformant { with a STD. putting this in a deployment model is not as good - there { will (assuming pcn's success) potentially be many deployment models, and { many deployment models based on a particular encoding. The framework is { that the behaviour of the interior nodes (in terms of both marking { behaviour & encoding) is simple and clear, without a whole lot of { configurable options. Meanwhile, there's more freedom in terms of the { behaviour of the gateways in how they interpret these marks. Of course { it may turn out that in practice there are only a couple of good sets of { gateway behaviour. { Anyway, I read your email as proposing that the marking and encoding { should allow lots of freedom with lots of configurable options, and that { the deployment models should be where things are standardised in anger. { I disagree with that. { = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 04:11:40 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE663A6ACE; Tue, 21 Oct 2008 04:11:40 -0700 (PDT) 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 0F78C3A6ACE for ; Tue, 21 Oct 2008 04:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 l4CLcakpWM6G for ; Tue, 21 Oct 2008 04:11:38 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 9CE2D3A6A5D for ; Tue, 21 Oct 2008 04:11:37 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 21 Oct 2008 13:12:50 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 13:12:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 13:12:51 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01E208B1@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3C1@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 thread-index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2AAAgG44AABBOfQ References: <1B6169C658325341A3B8066E23919E1C01E20860@S4DE8PSAANK.mitte.t-com.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA3C1@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Oct 2008 11:12:49.0804 (UTC) FILETIME=[F4307CC0:01C9336D] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, = { my view is, that the coding and marking as they are specified right now a= re { allright, but may have to be reduced to the bare functionality specified. [Phil]: Not sure what you mean, what needs reducing? (not sure if this is cutting o= ut = some of the MUSTS/SHOULDS or cutting some of the explanatory material) [Ru]: = On a general level if anything should be cut out, explanatory material (I m= ay = have review comments on content, but that's not what I'm talking about here= ). Please also note that by the above I'm not critising your draft as containi= ng = not necessary information. Regards, Rudiger { Examples of deployment models and references to documents specifying them { could be given - but these should be teasers, no lengthy descriptions. Yes { = { Separate documents may discuss different deployment models. There and only { there, flexibility should be allowed. I also think, PCN should generally { leave room for experimental extensions (like PCN sucessfully does eg. { with experimental three codepoint marking schemes). Agree { = { A question coming to my mind is, whether we are able to consent on further { standard ingress/egrees node functionalities apart from baseline coding { and marking behaviour. Egress measurement functions is one such topic. That's an interesting question. It would certainly be nice. Perhaps one tha= t's easier to discuss f2f? { The more such basic standard functionalities we can agree on, the better. { = { My general philosophy is: define a common starting point. Leave room to { learn and adapt systems, once we all started from the common starting { point. What I dislike, and I think we aggree on that, is parallel { customisation of different solutions from start on. Agree! { = { Regards, { = { Ruediger { = { = { -----Original Message----- { From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { Sent: Tuesday, October 21, 2008 11:29 AM { To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger { Cc: pcn@ietf.org { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { { { { my thinking is what you also suspect at the end of your email: the { { description of the packets to be metered and the packets to be { re-marked { { is part of the deployment model and meters and markers must be { { configurable with regard to this respect. The same applies to drop { { preferences. It does not mean that anything can be done in PCN. The { { restrictions come through the deployment models that say which { building { { blocks MUST be used and how they MUST be configured. Then, metering { and { { marking can be kept general and encoding does not need to know { anything { { about its future use. { = { I disagree with this to some extent. { = { I think that what pkts are metered and what re-marked is something to be { standardised in the encoding drafts. This allows each to be carefully { thought about and for manufacturers to say that their kit is conformant { with a STD. putting this in a deployment model is not as good - there { will (assuming pcn's success) potentially be many deployment models, and { many deployment models based on a particular encoding. The framework is { that the behaviour of the interior nodes (in terms of both marking { behaviour & encoding) is simple and clear, without a whole lot of { configurable options. Meanwhile, there's more freedom in terms of the { behaviour of the gateways in how they interpret these marks. Of course { it may turn out that in practice there are only a couple of good sets of { gateway behaviour. { Anyway, I read your email as proposing that the marking and encoding { should allow lots of freedom with lots of configurable options, and that { the deployment models should be where things are standardised in anger. { I disagree with that. { = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 04:19:50 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86AA03A6B49; Tue, 21 Oct 2008 04:19:50 -0700 (PDT) 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 A70A33A6B49 for ; Tue, 21 Oct 2008 04:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.06 X-Spam-Level: X-Spam-Status: No, score=-3.06 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 B8G1m0iiCxbo for ; Tue, 21 Oct 2008 04:19:48 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 135CF3A67F8 for ; Tue, 21 Oct 2008 04:19:47 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 12:21:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 12:20:59 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3C2@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E208B1@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2AAAgG44AABBOfQAACdGMA= From: To: X-OriginalArrivalTime: 21 Oct 2008 11:21:00.0237 (UTC) FILETIME=[18829FD0:01C9336F] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ok, - will wait for your comments on the marking draft = Thanks! phil { -----Original Message----- { From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] { Sent: 21 October 2008 12:13 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Hi Phil, { = { { my view is, that the coding and marking as they are specified right now { are { { allright, but may have to be reduced to the bare functionality { specified. { = { [Phil]: { Not sure what you mean, what needs reducing? (not sure if this is cutting { out { some of the MUSTS/SHOULDS or cutting some of the explanatory material) { = { [Ru]: { On a general level if anything should be cut out, explanatory material (I { may { have review comments on content, but that's not what I'm talking about { here). { Please also note that by the above I'm not critising your draft as { containing { not necessary information. { = { Regards, Rudiger { = { = { = { = { { Examples of deployment models and references to documents specifying { them { { could be given - but these should be teasers, no lengthy descriptions. { Yes { = { { { { Separate documents may discuss different deployment models. There and { only { { there, flexibility should be allowed. I also think, PCN should generally { { leave room for experimental extensions (like PCN sucessfully does eg. { { with experimental three codepoint marking schemes). { Agree { = { { { { A question coming to my mind is, whether we are able to consent on { further { { standard ingress/egrees node functionalities apart from baseline coding { { and marking behaviour. Egress measurement functions is one such topic. { That's an interesting question. It would certainly be nice. Perhaps one { that's easier to discuss f2f? { = { { The more such basic standard functionalities we can agree on, the { better. { { { { My general philosophy is: define a common starting point. Leave room to { { learn and adapt systems, once we all started from the common starting { { point. What I dislike, and I think we aggree on that, is parallel { { customisation of different solutions from start on. { Agree! { = { { { { Regards, { { { { Ruediger { { { { { { -----Original Message----- { { From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { { Sent: Tuesday, October 21, 2008 11:29 AM { { To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger { { Cc: pcn@ietf.org { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { { encoding-01 { { { { { { { { my thinking is what you also suspect at the end of your email: the { { { description of the packets to be metered and the packets to be { { re-marked { { { is part of the deployment model and meters and markers must be { { { configurable with regard to this respect. The same applies to drop { { { preferences. It does not mean that anything can be done in PCN. The { { { restrictions come through the deployment models that say which { { building { { { blocks MUST be used and how they MUST be configured. Then, metering { { and { { { marking can be kept general and encoding does not need to know { { anything { { { about its future use. { { { { I disagree with this to some extent. { { { { I think that what pkts are metered and what re-marked is something to be { { standardised in the encoding drafts. This allows each to be carefully { { thought about and for manufacturers to say that their kit is conformant { { with a STD. putting this in a deployment model is not as good - there { { will (assuming pcn's success) potentially be many deployment models, and { { many deployment models based on a particular encoding. The framework is { { that the behaviour of the interior nodes (in terms of both marking { { behaviour & encoding) is simple and clear, without a whole lot of { { configurable options. Meanwhile, there's more freedom in terms of the { { behaviour of the gateways in how they interpret these marks. Of course { { it may turn out that in practice there are only a couple of good sets of { { gateway behaviour. { { Anyway, I read your email as proposing that the marking and encoding { { should allow lots of freedom with lots of configurable options, and that { { the deployment models should be where things are standardised in anger. { { I disagree with that. { { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 05:50:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245863A6934; Tue, 21 Oct 2008 05:50:52 -0700 (PDT) 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 550743A6934 for ; Tue, 21 Oct 2008 05:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.152, 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 z8vru02HxUJt for ; Tue, 21 Oct 2008 05:50:50 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id E6F373A6916 for ; Tue, 21 Oct 2008 05:50:49 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 13:51:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 13:50:51 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3C2@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2AAAgG44AABBOfQAACdGMAAAxuSoA== References: <1B6169C658325341A3B8066E23919E1C01E208B1@S4DE8PSAANK.mitte.t-com.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA3C2@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 21 Oct 2008 12:51:14.0520 (UTC) FILETIME=[B3ACA580:01C9337B] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I don't know if it is what Phil is doing but personally my approach in the = encoding draft has been to include explanatory text whilst the document mat= ures with the intention of then removing most of the explanation once the d= ocument becomes ready to be last-called and moved to RFC. Toby -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of phili= p.eardley@bt.com Sent: 21 October 2008 12:21 To: Ruediger.Geib@t-systems.com Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encodi= ng-01 Ok, - will wait for your comments on the marking draft = Thanks! phil { -----Original Message----- { From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] { Sent: 21 October 2008 12:13 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Hi Phil, { = { { my view is, that the coding and marking as they are specified right now { are { { allright, but may have to be reduced to the bare functionality { specified. { = { [Phil]: { Not sure what you mean, what needs reducing? (not sure if this is cutting { out { some of the MUSTS/SHOULDS or cutting some of the explanatory material) { = { [Ru]: { On a general level if anything should be cut out, explanatory material (I { may { have review comments on content, but that's not what I'm talking about { here). { Please also note that by the above I'm not critising your draft as { containing { not necessary information. { = { Regards, Rudiger { = { = { = { = { { Examples of deployment models and references to documents specifying { them { { could be given - but these should be teasers, no lengthy descriptions. { Yes { = { { { { Separate documents may discuss different deployment models. There and { only { { there, flexibility should be allowed. I also think, PCN should generally { { leave room for experimental extensions (like PCN sucessfully does eg. { { with experimental three codepoint marking schemes). { Agree { = { { { { A question coming to my mind is, whether we are able to consent on { further { { standard ingress/egrees node functionalities apart from baseline coding { { and marking behaviour. Egress measurement functions is one such topic. { That's an interesting question. It would certainly be nice. Perhaps one { that's easier to discuss f2f? { = { { The more such basic standard functionalities we can agree on, the { better. { { { { My general philosophy is: define a common starting point. Leave room to { { learn and adapt systems, once we all started from the common starting { { point. What I dislike, and I think we aggree on that, is parallel { { customisation of different solutions from start on. { Agree! { = { { { { Regards, { { { { Ruediger { { { { { { -----Original Message----- { { From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { { Sent: Tuesday, October 21, 2008 11:29 AM { { To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger { { Cc: pcn@ietf.org { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { { encoding-01 { { { { { { { { my thinking is what you also suspect at the end of your email: the { { { description of the packets to be metered and the packets to be { { re-marked { { { is part of the deployment model and meters and markers must be { { { configurable with regard to this respect. The same applies to drop { { { preferences. It does not mean that anything can be done in PCN. The { { { restrictions come through the deployment models that say which { { building { { { blocks MUST be used and how they MUST be configured. Then, metering { { and { { { marking can be kept general and encoding does not need to know { { anything { { { about its future use. { { { { I disagree with this to some extent. { { { { I think that what pkts are metered and what re-marked is something to be { { standardised in the encoding drafts. This allows each to be carefully { { thought about and for manufacturers to say that their kit is conformant { { with a STD. putting this in a deployment model is not as good - there { { will (assuming pcn's success) potentially be many deployment models, and { { many deployment models based on a particular encoding. The framework is { { that the behaviour of the interior nodes (in terms of both marking { { behaviour & encoding) is simple and clear, without a whole lot of { { configurable options. Meanwhile, there's more freedom in terms of the { { behaviour of the gateways in how they interpret these marks. Of course { { it may turn out that in practice there are only a couple of good sets of { { gateway behaviour. { { Anyway, I read your email as proposing that the marking and encoding { { should allow lots of freedom with lots of configurable options, and that { { the deployment models should be where things are standardised in anger. { { I disagree with that. { { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 06:32:49 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113273A6813; Tue, 21 Oct 2008 06:32:49 -0700 (PDT) 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 E78F93A6813 for ; Tue, 21 Oct 2008 06:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 rzrft5gGpuH9 for ; Tue, 21 Oct 2008 06:32:46 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 5D9E93A67A7 for ; Tue, 21 Oct 2008 06:32:45 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Tue, 21 Oct 2008 15:32:57 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 15:32:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 15:32:53 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01E209BB@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 thread-index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2AAAgG44AABBOfQAACdGMAAAxuSoAABPKaA References: <1B6169C658325341A3B8066E23919E1C01E208B1@S4DE8PSAANK.mitte.t-com.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA3C2@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Oct 2008 13:32:54.0834 (UTC) FILETIME=[85FA4920:01C93381] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, Appendix B of your actual draft caused some controversy. Is it intended to = be normative (don't recall what your text says) or just raising attention = to some topics to be discussed? = The appendix free version of your draft is well written, if it comes to me. Regards, Ruediger -----Original Message----- From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] = Sent: Tuesday, October 21, 2008 2:51 PM To: philip.eardley@bt.com; Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encodi= ng-01 I don't know if it is what Phil is doing but personally my approach in the = encoding draft has been to include explanatory text whilst the document mat= ures with the intention of then removing most of the explanation once the d= ocument becomes ready to be last-called and moved to RFC. Toby -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of phili= p.eardley@bt.com Sent: 21 October 2008 12:21 To: Ruediger.Geib@t-systems.com Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encodi= ng-01 Ok, - will wait for your comments on the marking draft = Thanks! phil { -----Original Message----- { From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] { Sent: 21 October 2008 12:13 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Hi Phil, { = { { my view is, that the coding and marking as they are specified right now { are { { allright, but may have to be reduced to the bare functionality { specified. { = { [Phil]: { Not sure what you mean, what needs reducing? (not sure if this is cutting { out { some of the MUSTS/SHOULDS or cutting some of the explanatory material) { = { [Ru]: { On a general level if anything should be cut out, explanatory material (I { may { have review comments on content, but that's not what I'm talking about { here). { Please also note that by the above I'm not critising your draft as { containing { not necessary information. { = { Regards, Rudiger { = { = { = { = { { Examples of deployment models and references to documents specifying { them { { could be given - but these should be teasers, no lengthy descriptions. { Yes { = { { { { Separate documents may discuss different deployment models. There and { only { { there, flexibility should be allowed. I also think, PCN should generally { { leave room for experimental extensions (like PCN sucessfully does eg. { { with experimental three codepoint marking schemes). { Agree { = { { { { A question coming to my mind is, whether we are able to consent on { further { { standard ingress/egrees node functionalities apart from baseline coding { { and marking behaviour. Egress measurement functions is one such topic. { That's an interesting question. It would certainly be nice. Perhaps one { that's easier to discuss f2f? { = { { The more such basic standard functionalities we can agree on, the { better. { { { { My general philosophy is: define a common starting point. Leave room to { { learn and adapt systems, once we all started from the common starting { { point. What I dislike, and I think we aggree on that, is parallel { { customisation of different solutions from start on. { Agree! { = { { { { Regards, { { { { Ruediger { { { { { { -----Original Message----- { { From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { { Sent: Tuesday, October 21, 2008 11:29 AM { { To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger { { Cc: pcn@ietf.org { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { { encoding-01 { { { { { { { { my thinking is what you also suspect at the end of your email: the { { { description of the packets to be metered and the packets to be { { re-marked { { { is part of the deployment model and meters and markers must be { { { configurable with regard to this respect. The same applies to drop { { { preferences. It does not mean that anything can be done in PCN. The { { { restrictions come through the deployment models that say which { { building { { { blocks MUST be used and how they MUST be configured. Then, metering { { and { { { marking can be kept general and encoding does not need to know { { anything { { { about its future use. { { { { I disagree with this to some extent. { { { { I think that what pkts are metered and what re-marked is something to be { { standardised in the encoding drafts. This allows each to be carefully { { thought about and for manufacturers to say that their kit is conformant { { with a STD. putting this in a deployment model is not as good - there { { will (assuming pcn's success) potentially be many deployment models, and { { many deployment models based on a particular encoding. The framework is { { that the behaviour of the interior nodes (in terms of both marking { { behaviour & encoding) is simple and clear, without a whole lot of { { configurable options. Meanwhile, there's more freedom in terms of the { { behaviour of the gateways in how they interpret these marks. Of course { { it may turn out that in practice there are only a couple of good sets of { { gateway behaviour. { { Anyway, I read your email as proposing that the marking and encoding { { should allow lots of freedom with lots of configurable options, and that { { the deployment models should be where things are standardised in anger. { { I disagree with that. { { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 07:31:21 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A6B3A6A70; Tue, 21 Oct 2008 07:31:21 -0700 (PDT) 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 2BD133A6A70 for ; Tue, 21 Oct 2008 07:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=-0.359, 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 JHaHrM9l8gPa for ; Tue, 21 Oct 2008 07:31:19 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AA6D63A6801 for ; Tue, 21 Oct 2008 07:31:18 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 15:32:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 15:32:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3C4@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E209BB@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2AAAgG44AABBOfQAACdGMAAAxuSoAABPKaAAAIkG5A= From: To: , X-OriginalArrivalTime: 21 Oct 2008 14:32:30.0954 (UTC) FILETIME=[D982E4A0:01C93389] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org For the marking behaviour draft, both the Appendices are Informative. App A= is examples of algos that meet the std. app B is explanation /discussion /= comments on the std. Whether or not it's worth keeping either of them in th= e actual rfc, I don't have a particular view on. Personally I like to see t= he reasons for things, but I suppose this could always be done by reference= (the rfc could say something like "see the I-D App B for explanations"???) For App B of the encoding draft, my view is that this should be normative (= not yet studied whether I agree with all the content) { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Geib, Ruediger { Sent: 21 October 2008 14:33 { To: Moncaster,T,Toby,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Hi Toby, { = { Appendix B of your actual draft caused some controversy. Is it intended to { be normative (don't recall what your text says) or just raising attention { to some topics to be discussed? { = { The appendix free version of your draft is well written, if it comes to { me. { = { Regards, { = { Ruediger { = { = { -----Original Message----- { From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] { Sent: Tuesday, October 21, 2008 2:51 PM { To: philip.eardley@bt.com; Geib, R=FCdiger { Cc: pcn@ietf.org { Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { I don't know if it is what Phil is doing but personally my approach in the { encoding draft has been to include explanatory text whilst the document { matures with the intention of then removing most of the explanation once { the document becomes ready to be last-called and moved to RFC. { = { Toby { = { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { philip.eardley@bt.com { Sent: 21 October 2008 12:21 { To: Ruediger.Geib@t-systems.com { Cc: pcn@ietf.org { Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Ok, - will wait for your comments on the marking draft { Thanks! { phil { = { { -----Original Message----- { { From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] { { Sent: 21 October 2008 12:13 { { To: Eardley,PL,Philip,CXR9 R { { Cc: pcn@ietf.org { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { { encoding-01 { { { { Hi Phil, { { { { { my view is, that the coding and marking as they are specified right { now { { are { { { allright, but may have to be reduced to the bare functionality { { specified. { { { { [Phil]: { { Not sure what you mean, what needs reducing? (not sure if this is { cutting { { out { { some of the MUSTS/SHOULDS or cutting some of the explanatory material) { { { { [Ru]: { { On a general level if anything should be cut out, explanatory material { (I { { may { { have review comments on content, but that's not what I'm talking about { { here). { { Please also note that by the above I'm not critising your draft as { { containing { { not necessary information. { { { { Regards, Rudiger { { { { { { { { { { { Examples of deployment models and references to documents specifying { { them { { { could be given - but these should be teasers, no lengthy descriptions. { { Yes { { { { { { { { Separate documents may discuss different deployment models. There and { { only { { { there, flexibility should be allowed. I also think, PCN should { generally { { { leave room for experimental extensions (like PCN sucessfully does eg. { { { with experimental three codepoint marking schemes). { { Agree { { { { { { { { A question coming to my mind is, whether we are able to consent on { { further { { { standard ingress/egrees node functionalities apart from baseline { coding { { { and marking behaviour. Egress measurement functions is one such topic. { { That's an interesting question. It would certainly be nice. Perhaps one { { that's easier to discuss f2f? { { { { { The more such basic standard functionalities we can agree on, the { { better. { { { { { { My general philosophy is: define a common starting point. Leave room { to { { { learn and adapt systems, once we all started from the common starting { { { point. What I dislike, and I think we aggree on that, is parallel { { { customisation of different solutions from start on. { { Agree! { { { { { { { { Regards, { { { { { { Ruediger { { { { { { { { { -----Original Message----- { { { From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { { { Sent: Tuesday, October 21, 2008 11:29 AM { { { To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger { { { Cc: pcn@ietf.org { { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { { { encoding-01 { { { { { { { { { { { my thinking is what you also suspect at the end of your email: the { { { { description of the packets to be metered and the packets to be { { { re-marked { { { { is part of the deployment model and meters and markers must be { { { { configurable with regard to this respect. The same applies to drop { { { { preferences. It does not mean that anything can be done in PCN. The { { { { restrictions come through the deployment models that say which { { { building { { { { blocks MUST be used and how they MUST be configured. Then, metering { { { and { { { { marking can be kept general and encoding does not need to know { { { anything { { { { about its future use. { { { { { { I disagree with this to some extent. { { { { { { I think that what pkts are metered and what re-marked is something to { be { { { standardised in the encoding drafts. This allows each to be carefully { { { thought about and for manufacturers to say that their kit is { conformant { { { with a STD. putting this in a deployment model is not as good - there { { { will (assuming pcn's success) potentially be many deployment models, { and { { { many deployment models based on a particular encoding. The framework { is { { { that the behaviour of the interior nodes (in terms of both marking { { { behaviour & encoding) is simple and clear, without a whole lot of { { { configurable options. Meanwhile, there's more freedom in terms of the { { { behaviour of the gateways in how they interpret these marks. Of course { { { it may turn out that in practice there are only a couple of good sets { of { { { gateway behaviour. { { { Anyway, I read your email as proposing that the marking and encoding { { { should allow lots of freedom with lots of configurable options, and { that { { { the deployment models should be where things are standardised in { anger. { { { I disagree with that. { { { { = { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 08:22:40 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A5B3A6A3B; Tue, 21 Oct 2008 08:22:40 -0700 (PDT) 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 9346A3A6A39 for ; Tue, 21 Oct 2008 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.159, 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 WbqEOj7sEOPH for ; Tue, 21 Oct 2008 08:22:38 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 13FA13A6A42 for ; Tue, 21 Oct 2008 08:22:37 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 16:23:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 16:23:54 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3C4@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckzWEDp5Ul/aFtMRB24MiVReIpfAAABZdgQAACli2AAAgG44AABBOfQAACdGMAAAxuSoAABPKaAAAIkG5AAAe20kA== References: <1B6169C658325341A3B8066E23919E1C01E209BB@S4DE8PSAANK.mitte.t-com.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA3C4@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 21 Oct 2008 15:23:49.0598 (UTC) FILETIME=[0486AFE0:01C93391] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org The appendices are meant to be informative and will either disappear in the= final version or will move to a different document. Appendix A will go com= pletely as it will just reference Bob's work on tunnelling, Appendix B will= be partially incorporated (in response to WG responses to the questions I = put in there) and Appendix C will be probably be replaced with a future dep= loyment model draft(s). Toby -----Original Message----- From: Eardley,PL,Philip,CXR9 R = Sent: 21 October 2008 15:33 To: 'Geib, Ruediger'; Moncaster,T,Toby,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-encodin= g-01 For the marking behaviour draft, both the Appendices are Informative. App A= is examples of algos that meet the std. app B is explanation /discussion /= comments on the std. Whether or not it's worth keeping either of them in th= e actual rfc, I don't have a particular view on. Personally I like to see t= he reasons for things, but I suppose this could always be done by reference= (the rfc could say something like "see the I-D App B for explanations"???) For App B of the encoding draft, my view is that this should be normative (= not yet studied whether I agree with all the content) { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Geib, Ruediger { Sent: 21 October 2008 14:33 { To: Moncaster,T,Toby,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Hi Toby, { = { Appendix B of your actual draft caused some controversy. Is it intended to { be normative (don't recall what your text says) or just raising attention { to some topics to be discussed? { = { The appendix free version of your draft is well written, if it comes to { me. { = { Regards, { = { Ruediger { = { = { -----Original Message----- { From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] { Sent: Tuesday, October 21, 2008 2:51 PM { To: philip.eardley@bt.com; Geib, R=FCdiger { Cc: pcn@ietf.org { Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { I don't know if it is what Phil is doing but personally my approach in the { encoding draft has been to include explanatory text whilst the document { matures with the intention of then removing most of the explanation once { the document becomes ready to be last-called and moved to RFC. { = { Toby { = { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { philip.eardley@bt.com { Sent: 21 October 2008 12:21 { To: Ruediger.Geib@t-systems.com { Cc: pcn@ietf.org { Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { = { Ok, - will wait for your comments on the marking draft { Thanks! { phil { = { { -----Original Message----- { { From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] { { Sent: 21 October 2008 12:13 { { To: Eardley,PL,Philip,CXR9 R { { Cc: pcn@ietf.org { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { { encoding-01 { { { { Hi Phil, { { { { { my view is, that the coding and marking as they are specified right { now { { are { { { allright, but may have to be reduced to the bare functionality { { specified. { { { { [Phil]: { { Not sure what you mean, what needs reducing? (not sure if this is { cutting { { out { { some of the MUSTS/SHOULDS or cutting some of the explanatory material) { { { { [Ru]: { { On a general level if anything should be cut out, explanatory material { (I { { may { { have review comments on content, but that's not what I'm talking about { { here). { { Please also note that by the above I'm not critising your draft as { { containing { { not necessary information. { { { { Regards, Rudiger { { { { { { { { { { { Examples of deployment models and references to documents specifying { { them { { { could be given - but these should be teasers, no lengthy descriptions. { { Yes { { { { { { { { Separate documents may discuss different deployment models. There and { { only { { { there, flexibility should be allowed. I also think, PCN should { generally { { { leave room for experimental extensions (like PCN sucessfully does eg. { { { with experimental three codepoint marking schemes). { { Agree { { { { { { { { A question coming to my mind is, whether we are able to consent on { { further { { { standard ingress/egrees node functionalities apart from baseline { coding { { { and marking behaviour. Egress measurement functions is one such topic. { { That's an interesting question. It would certainly be nice. Perhaps one { { that's easier to discuss f2f? { { { { { The more such basic standard functionalities we can agree on, the { { better. { { { { { { My general philosophy is: define a common starting point. Leave room { to { { { learn and adapt systems, once we all started from the common starting { { { point. What I dislike, and I think we aggree on that, is parallel { { { customisation of different solutions from start on. { { Agree! { { { { { { { { Regards, { { { { { { Ruediger { { { { { { { { { -----Original Message----- { { { From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { { { Sent: Tuesday, October 21, 2008 11:29 AM { { { To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger { { { Cc: pcn@ietf.org { { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { { { encoding-01 { { { { { { { { { { { my thinking is what you also suspect at the end of your email: the { { { { description of the packets to be metered and the packets to be { { { re-marked { { { { is part of the deployment model and meters and markers must be { { { { configurable with regard to this respect. The same applies to drop { { { { preferences. It does not mean that anything can be done in PCN. The { { { { restrictions come through the deployment models that say which { { { building { { { { blocks MUST be used and how they MUST be configured. Then, metering { { { and { { { { marking can be kept general and encoding does not need to know { { { anything { { { { about its future use. { { { { { { I disagree with this to some extent. { { { { { { I think that what pkts are metered and what re-marked is something to { be { { { standardised in the encoding drafts. This allows each to be carefully { { { thought about and for manufacturers to say that their kit is { conformant { { { with a STD. putting this in a deployment model is not as good - there { { { will (assuming pcn's success) potentially be many deployment models, { and { { { many deployment models based on a particular encoding. The framework { is { { { that the behaviour of the interior nodes (in terms of both marking { { { behaviour & encoding) is simple and clear, without a whole lot of { { { configurable options. Meanwhile, there's more freedom in terms of the { { { behaviour of the gateways in how they interpret these marks. Of course { { { it may turn out that in practice there are only a couple of good sets { of { { { gateway behaviour. { { { Anyway, I read your email as proposing that the marking and encoding { { { should allow lots of freedom with lots of configurable options, and { that { { { the deployment models should be where things are standardised in { anger. { { { I disagree with that. { { { { = { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 21 09:22:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868983A6B76; Tue, 21 Oct 2008 09:22:55 -0700 (PDT) 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 AD6833A6A0D for ; Tue, 21 Oct 2008 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.180, 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 bZyYkjl62aQL for ; Tue, 21 Oct 2008 09:22:53 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 7C23B3A6B02 for ; Tue, 21 Oct 2008 09:22:53 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1B58A198DE5; Tue, 21 Oct 2008 18:24:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0D689198DCB; Tue, 21 Oct 2008 18:24:04 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id DB908198DC3; Tue, 21 Oct 2008 18:24:03 +0200 (CEST) Message-ID: <48FE01C0.50204@informatik.uni-wuerzburg.de> Date: Tue, 21 Oct 2008 18:22:24 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA3BE@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3BE@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, yes, you are right. My example was ill-conceived. Currently I cannot think either of a sensible deployment model that would not meter all PCN packets for threshold marking and all unmarked PCN packets for excess marking. My comment actually concerns the dropping behavior. Its definition in the marking draft unnecessarily constrains the use of the meters and markers and should be rather defined by deployment models. Of course, only sensible freedom should be allowed in the marking and encoding draft. What sensible freedom is depends on which deployment models should be able to be basically supported. Now or possibly in the future. Regards, Michael philip.eardley@bt.com wrote: > { > { my thinking is what you also suspect at the end of your email: the > { description of the packets to be metered and the packets to be > re-marked > { is part of the deployment model and meters and markers must be > { configurable with regard to this respect. The same applies to drop > { preferences. It does not mean that anything can be done in PCN. The > { restrictions come through the deployment models that say which > building > { blocks MUST be used and how they MUST be configured. Then, metering > and > { marking can be kept general and encoding does not need to know > anything > { about its future use. > > I disagree with this to some extent. > > I think that what pkts are metered and what re-marked is something to be > standardised in the encoding drafts. This allows each to be carefully > thought about and for manufacturers to say that their kit is conformant > with a STD. putting this in a deployment model is not as good - there > will (assuming pcn's success) potentially be many deployment models, and > many deployment models based on a particular encoding. The framework is > that the behaviour of the interior nodes (in terms of both marking > behaviour & encoding) is simple and clear, without a whole lot of > configurable options. Meanwhile, there's more freedom in terms of the > behaviour of the gateways in how they interpret these marks. Of course > it may turn out that in practice there are only a couple of good sets of > gateway behaviour. > Anyway, I read your email as proposing that the marking and encoding > should allow lots of freedom with lots of configurable options, and that > the deployment models should be where things are standardised in anger. > I disagree with that. > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 01:37:54 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C190D3A6938; Wed, 22 Oct 2008 01:37:54 -0700 (PDT) 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 4E7D53A68B1 for ; Wed, 22 Oct 2008 01:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMVBcCElyqfw for ; Wed, 22 Oct 2008 01:37:52 -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 053E73A67F2 for ; Wed, 22 Oct 2008 01:37:52 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 059BF198DD3; Wed, 22 Oct 2008 10:39:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id ECF96198DD1; Wed, 22 Oct 2008 10:39:07 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CB588198DC8; Wed, 22 Oct 2008 10:39:07 +0200 (CEST) Message-ID: <48FEE649.1090307@informatik.uni-wuerzburg.de> Date: Wed, 22 Oct 2008 10:37:29 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CB@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CB@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, the issue is whether the marking draft should also restrict drop preferences. Dropping of marked packets is not needed from a general marking perspective. It's only needed for indirect measured rate termination which is only one termination option out of many others. Requiring preferential dropping of special packets only limits the number of options of what you can do with PCN marking. Therefore, such constraints are better suitable for deployment models. Regards, Michael philip.eardley@bt.com wrote: > The thing is that we discussed dropping quite a lot at/near the ietf in > Philadelphia, and the preferential dropping v reaction times argument. > not that it's impossible to re-visit the decision, but is there new > evidence or argument? > > phil > > { -----Original Message----- > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { Sent: 21 October 2008 17:22 > { To: Eardley,PL,Philip,CXR9 R > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org > { Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- > { encoding-01 > { > { Hi Phil, > { > { yes, you are right. My example was ill-conceived. Currently I cannot > { think either of a sensible deployment model that would not meter all > PCN > { packets for threshold marking and all unmarked PCN packets for excess > { marking. > { > { My comment actually concerns the dropping behavior. Its definition in > { the marking draft unnecessarily constrains the use of the meters and > { markers and should be rather defined by deployment models. > { > { Of course, only sensible freedom should be allowed in the marking and > { encoding draft. What sensible freedom is depends on which deployment > { models should be able to be basically supported. Now or possibly in > the > { future. > { > { Regards, > { > { Michael > { > { > { philip.eardley@bt.com wrote: > { > { > { > { my thinking is what you also suspect at the end of your email: the > { > { description of the packets to be metered and the packets to be > { > re-marked > { > { is part of the deployment model and meters and markers must be > { > { configurable with regard to this respect. The same applies to drop > { > { preferences. It does not mean that anything can be done in PCN. > The > { > { restrictions come through the deployment models that say which > { > building > { > { blocks MUST be used and how they MUST be configured. Then, > metering > { > and > { > { marking can be kept general and encoding does not need to know > { > anything > { > { about its future use. > { > > { > I disagree with this to some extent. > { > > { > I think that what pkts are metered and what re-marked is something > to be > { > standardised in the encoding drafts. This allows each to be > carefully > { > thought about and for manufacturers to say that their kit is > conformant > { > with a STD. putting this in a deployment model is not as good - > there > { > will (assuming pcn's success) potentially be many deployment models, > and > { > many deployment models based on a particular encoding. The framework > is > { > that the behaviour of the interior nodes (in terms of both marking > { > behaviour & encoding) is simple and clear, without a whole lot of > { > configurable options. Meanwhile, there's more freedom in terms of > the > { > behaviour of the gateways in how they interpret these marks. Of > course > { > it may turn out that in practice there are only a couple of good > sets of > { > gateway behaviour. > { > Anyway, I read your email as proposing that the marking and encoding > { > should allow lots of freedom with lots of configurable options, and > that > { > the deployment models should be where things are standardised in > anger. > { > I disagree with that. > { > > { > { -- > { Dr. Michael Menth, Assistant Professor > { University of Wuerzburg, Institute of Computer Science > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { mailto:menth@informatik.uni-wuerzburg.de > { http://www3.informatik.uni-wuerzburg.de/research/ngn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 01:44:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3433A67F5; Wed, 22 Oct 2008 01:44:44 -0700 (PDT) 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 0319A3A6938 for ; Wed, 22 Oct 2008 01:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 ocicmAXNhySq for ; Wed, 22 Oct 2008 01:44:42 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D7A153A67F3 for ; Wed, 22 Oct 2008 01:44:41 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 09:12:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 09:12:53 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CB@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48FE01C0.50204@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: AckzmXJvZGgeN7mfRCqG1GZ7CQ6LigAg0f9A From: To: X-OriginalArrivalTime: 22 Oct 2008 08:12:54.0822 (UTC) FILETIME=[FC4AB460:01C9341D] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org The thing is that we discussed dropping quite a lot at/near the ietf in Philadelphia, and the preferential dropping v reaction times argument. not that it's impossible to re-visit the decision, but is there new evidence or argument? phil { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 21 October 2008 17:22 { To: Eardley,PL,Philip,CXR9 R { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { { Hi Phil, { { yes, you are right. My example was ill-conceived. Currently I cannot { think either of a sensible deployment model that would not meter all PCN { packets for threshold marking and all unmarked PCN packets for excess { marking. { { My comment actually concerns the dropping behavior. Its definition in { the marking draft unnecessarily constrains the use of the meters and { markers and should be rather defined by deployment models. { { Of course, only sensible freedom should be allowed in the marking and { encoding draft. What sensible freedom is depends on which deployment { models should be able to be basically supported. Now or possibly in the { future. { { Regards, { { Michael { { { philip.eardley@bt.com wrote: { > { { > { my thinking is what you also suspect at the end of your email: the { > { description of the packets to be metered and the packets to be { > re-marked { > { is part of the deployment model and meters and markers must be { > { configurable with regard to this respect. The same applies to drop { > { preferences. It does not mean that anything can be done in PCN. The { > { restrictions come through the deployment models that say which { > building { > { blocks MUST be used and how they MUST be configured. Then, metering { > and { > { marking can be kept general and encoding does not need to know { > anything { > { about its future use. { > { > I disagree with this to some extent. { > { > I think that what pkts are metered and what re-marked is something to be { > standardised in the encoding drafts. This allows each to be carefully { > thought about and for manufacturers to say that their kit is conformant { > with a STD. putting this in a deployment model is not as good - there { > will (assuming pcn's success) potentially be many deployment models, and { > many deployment models based on a particular encoding. The framework is { > that the behaviour of the interior nodes (in terms of both marking { > behaviour & encoding) is simple and clear, without a whole lot of { > configurable options. Meanwhile, there's more freedom in terms of the { > behaviour of the gateways in how they interpret these marks. Of course { > it may turn out that in practice there are only a couple of good sets of { > gateway behaviour. { > Anyway, I read your email as proposing that the marking and encoding { > should allow lots of freedom with lots of configurable options, and that { > the deployment models should be where things are standardised in anger. { > I disagree with that. { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 01:52:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1671A3A69A0; Wed, 22 Oct 2008 01:52:44 -0700 (PDT) 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 63F803A69A0 for ; Wed, 22 Oct 2008 01:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpMU+Rsm5Fnz for ; Wed, 22 Oct 2008 01:52:39 -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 DBCF33A67F3 for ; Wed, 22 Oct 2008 01:52:38 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E0DEBA066F; Wed, 22 Oct 2008 10:53:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id D4513A066D; Wed, 22 Oct 2008 10:53:54 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B319BA05E8; Wed, 22 Oct 2008 10:53:54 +0200 (CEST) Message-ID: <48FEE9C0.1000003@informatik.uni-wuerzburg.de> Date: Wed, 22 Oct 2008 10:52:16 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CB@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CB@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, you ask for arguments and new evidence that indirect measured rate termination (IMRT), which is the only termination method that works well with preferential dropping of marked packets, is not sufficient. Just see IV.C of http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf Certainly, workarounds can be provided to reduce the likelihood of overtermination with IMRT, but they make it even more complex and extend its reaction time. Therefore, I do not find it a good idea to rule out other termination methods by integrating an unnecessary constraints in the marking draft. There are other termination methods that are also fast even in the presence of packet loss, simpler to build, work with multipath routing, and do not suffer from this source of overtermination. Evidence is given in that paper or also in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf Regards, Michael philip.eardley@bt.com wrote: > The thing is that we discussed dropping quite a lot at/near the ietf in > Philadelphia, and the preferential dropping v reaction times argument. > not that it's impossible to re-visit the decision, but is there new > evidence or argument? > > phil > > { -----Original Message----- > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { Sent: 21 October 2008 17:22 > { To: Eardley,PL,Philip,CXR9 R > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org > { Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- > { encoding-01 > { > { Hi Phil, > { > { yes, you are right. My example was ill-conceived. Currently I cannot > { think either of a sensible deployment model that would not meter all > PCN > { packets for threshold marking and all unmarked PCN packets for excess > { marking. > { > { My comment actually concerns the dropping behavior. Its definition in > { the marking draft unnecessarily constrains the use of the meters and > { markers and should be rather defined by deployment models. > { > { Of course, only sensible freedom should be allowed in the marking and > { encoding draft. What sensible freedom is depends on which deployment > { models should be able to be basically supported. Now or possibly in > the > { future. > { > { Regards, > { > { Michael > { > { > { philip.eardley@bt.com wrote: > { > { > { > { my thinking is what you also suspect at the end of your email: the > { > { description of the packets to be metered and the packets to be > { > re-marked > { > { is part of the deployment model and meters and markers must be > { > { configurable with regard to this respect. The same applies to drop > { > { preferences. It does not mean that anything can be done in PCN. > The > { > { restrictions come through the deployment models that say which > { > building > { > { blocks MUST be used and how they MUST be configured. Then, > metering > { > and > { > { marking can be kept general and encoding does not need to know > { > anything > { > { about its future use. > { > > { > I disagree with this to some extent. > { > > { > I think that what pkts are metered and what re-marked is something > to be > { > standardised in the encoding drafts. This allows each to be > carefully > { > thought about and for manufacturers to say that their kit is > conformant > { > with a STD. putting this in a deployment model is not as good - > there > { > will (assuming pcn's success) potentially be many deployment models, > and > { > many deployment models based on a particular encoding. The framework > is > { > that the behaviour of the interior nodes (in terms of both marking > { > behaviour & encoding) is simple and clear, without a whole lot of > { > configurable options. Meanwhile, there's more freedom in terms of > the > { > behaviour of the gateways in how they interpret these marks. Of > course > { > it may turn out that in practice there are only a couple of good > sets of > { > gateway behaviour. > { > Anyway, I read your email as proposing that the marking and encoding > { > should allow lots of freedom with lots of configurable options, and > that > { > the deployment models should be where things are standardised in > anger. > { > I disagree with that. > { > > { > { -- > { Dr. Michael Menth, Assistant Professor > { University of Wuerzburg, Institute of Computer Science > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { mailto:menth@informatik.uni-wuerzburg.de > { http://www3.informatik.uni-wuerzburg.de/research/ngn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 01:53:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B673A6B56; Wed, 22 Oct 2008 01:53:52 -0700 (PDT) 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 711103A69A0 for ; Wed, 22 Oct 2008 01:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfi57N91Swsv for ; Wed, 22 Oct 2008 01:53:47 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 0CD123A6B56 for ; Wed, 22 Oct 2008 01:53:46 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m9M8st7E017503; Wed, 22 Oct 2008 10:54:58 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CB@E03MVB1-UKBR.domain1.systemhost.net> <48FEE649.1090307@informatik.uni-wuerzburg.de> Date: Wed, 22 Oct 2008 10:54:49 +0200 Message-ID: <000401c93423$da7e74b0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: Ack0Ia+EVfAwXAZqSVueOXT765e8sAAAgBTA In-Reply-To: <48FEE649.1090307@informatik.uni-wuerzburg.de> X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 22 Oct 2008 10:54:59 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all I agree with Michael that such constraints are better suitable for deployment models. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: woensdag 22 oktober 2008 10:37 > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] NewVersionNotification > fordraft-ietf-pcn-baseline-encoding-01 > > Hi Phil, > > the issue is whether the marking draft should also restrict > drop preferences. Dropping of marked packets is not needed > from a general marking perspective. It's only needed for > indirect measured rate termination which is only one > termination option out of many others. > Requiring preferential dropping of special packets only > limits the number of options of what you can do with PCN > marking. Therefore, such constraints are better suitable for > deployment models. > > Regards, > > Michael > > philip.eardley@bt.com wrote: > > The thing is that we discussed dropping quite a lot at/near > the ietf > > in Philadelphia, and the preferential dropping v reaction > times argument. > > not that it's impossible to re-visit the decision, but is there new > > evidence or argument? > > > > phil > > > > { -----Original Message----- > > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > { Sent: 21 October 2008 17:22 > > { To: Eardley,PL,Philip,CXR9 R > > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: > Re: [PCN] > > New VersionNotification fordraft-ietf-pcn-baseline- { > encoding-01 { { > > Hi Phil, { { yes, you are right. My example was ill-conceived. > > Currently I cannot { think either of a sensible deployment > model that > > would not meter all PCN { packets for threshold marking and all > > unmarked PCN packets for excess { marking. > > { > > { My comment actually concerns the dropping behavior. Its > definition > > in { the marking draft unnecessarily constrains the use of > the meters > > and { markers and should be rather defined by deployment models. > > { > > { Of course, only sensible freedom should be allowed in the marking > > and { encoding draft. What sensible freedom is depends on which > > deployment { models should be able to be basically > supported. Now or > > possibly in the { future. > > { > > { Regards, > > { > > { Michael > > { > > { > > { philip.eardley@bt.com wrote: > > { > { > > { > { my thinking is what you also suspect at the end of > your email: > > the { > { description of the packets to be metered and the > packets to > > be { > re-marked { > { is part of the deployment model and > meters and > > markers must be { > { configurable with regard to this respect. The > > same applies to drop { > { preferences. It does not mean > that anything > > can be done in PCN. > > The > > { > { restrictions come through the deployment models that > say which { > > > building { > { blocks MUST be used and how they MUST be > configured. > > Then, metering { > and { > { marking can be kept general > and encoding > > does not need to know { > anything { > { about its future use. > > { > > > { > I disagree with this to some extent. > > { > > > { > I think that what pkts are metered and what re-marked > is something > > to be { > standardised in the encoding drafts. This allows > each to be > > carefully { > thought about and for manufacturers to say that their > > kit is conformant { > with a STD. putting this in a > deployment model > > is not as good - there { > will (assuming pcn's success) > potentially > > be many deployment models, and { > many deployment models > based on a > > particular encoding. The framework is { > that the behaviour of the > > interior nodes (in terms of both marking { > behaviour & > encoding) is > > simple and clear, without a whole lot of { > configurable options. > > Meanwhile, there's more freedom in terms of the { > > behaviour of the > > gateways in how they interpret these marks. Of course { > > it may turn > > out that in practice there are only a couple of good sets of { > > > gateway behaviour. > > { > Anyway, I read your email as proposing that the marking and > > encoding { > should allow lots of freedom with lots of configurable > > options, and that { > the deployment models should be where > things are > > standardised in anger. > > { > I disagree with that. > > { > > > { > > { -- > > { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, > > Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, > > Germany, room B206 { phone: (+49)-931/888-6644, fax: > > (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de > > { http://www3.informatik.uni-wuerzburg.de/research/ngn > > > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 02:03:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30103A6AD3; Wed, 22 Oct 2008 02:03:19 -0700 (PDT) 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 53D373A6AD3 for ; Wed, 22 Oct 2008 02:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 0fzn00jDZmKH for ; Wed, 22 Oct 2008 02:03:18 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B148E3A68B1 for ; Wed, 22 Oct 2008 02:03:17 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 10:04:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 10:04:15 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CC@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48FEE9C0.1000003@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: Ack0I70JEZsFZsG9T62D5WaH9UkoyQAARJsQ From: To: X-OriginalArrivalTime: 22 Oct 2008 09:04:16.0932 (UTC) FILETIME=[295F5E40:01C93425] Cc: pcn@ietf.org Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I'll look at that and see what's new compared with what we discussed before. Thanks. I probs wont have time to do that until the flight to Minn. { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 22 October 2008 09:52 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { { Hi Phil, { { you ask for arguments and new evidence that indirect measured rate { termination (IMRT), which is the only termination method that works well { with preferential dropping of marked packets, is not sufficient. Just { see IV.C of { http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf { Certainly, workarounds can be provided to reduce the likelihood of { overtermination with IMRT, but they make it even more complex and extend { its reaction time. Therefore, I do not find it a good idea to rule out { other termination methods by integrating an unnecessary constraints in { the marking draft. There are other termination methods that are also { fast even in the presence of packet loss, simpler to build, work with { multipath routing, and do not suffer from this source of { overtermination. Evidence is given in that paper or also in { http://www3.informatik.uni- { wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > The thing is that we discussed dropping quite a lot at/near the ietf in { > Philadelphia, and the preferential dropping v reaction times argument. { > not that it's impossible to re-visit the decision, but is there new { > evidence or argument? { > { > phil { > { > { -----Original Message----- { > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > { Sent: 21 October 2008 17:22 { > { To: Eardley,PL,Philip,CXR9 R { > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { > { Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline- { > { encoding-01 { > { { > { Hi Phil, { > { { > { yes, you are right. My example was ill-conceived. Currently I cannot { > { think either of a sensible deployment model that would not meter all { > PCN { > { packets for threshold marking and all unmarked PCN packets for excess { > { marking. { > { { > { My comment actually concerns the dropping behavior. Its definition in { > { the marking draft unnecessarily constrains the use of the meters and { > { markers and should be rather defined by deployment models. { > { { > { Of course, only sensible freedom should be allowed in the marking and { > { encoding draft. What sensible freedom is depends on which deployment { > { models should be able to be basically supported. Now or possibly in { > the { > { future. { > { { > { Regards, { > { { > { Michael { > { { > { { > { philip.eardley@bt.com wrote: { > { > { { > { > { my thinking is what you also suspect at the end of your email: the { > { > { description of the packets to be metered and the packets to be { > { > re-marked { > { > { is part of the deployment model and meters and markers must be { > { > { configurable with regard to this respect. The same applies to drop { > { > { preferences. It does not mean that anything can be done in PCN. { > The { > { > { restrictions come through the deployment models that say which { > { > building { > { > { blocks MUST be used and how they MUST be configured. Then, { > metering { > { > and { > { > { marking can be kept general and encoding does not need to know { > { > anything { > { > { about its future use. { > { > { > { > I disagree with this to some extent. { > { > { > { > I think that what pkts are metered and what re-marked is something { > to be { > { > standardised in the encoding drafts. This allows each to be { > carefully { > { > thought about and for manufacturers to say that their kit is { > conformant { > { > with a STD. putting this in a deployment model is not as good - { > there { > { > will (assuming pcn's success) potentially be many deployment models, { > and { > { > many deployment models based on a particular encoding. The framework { > is { > { > that the behaviour of the interior nodes (in terms of both marking { > { > behaviour & encoding) is simple and clear, without a whole lot of { > { > configurable options. Meanwhile, there's more freedom in terms of { > the { > { > behaviour of the gateways in how they interpret these marks. Of { > course { > { > it may turn out that in practice there are only a couple of good { > sets of { > { > gateway behaviour. { > { > Anyway, I read your email as proposing that the marking and encoding { > { > should allow lots of freedom with lots of configurable options, and { > that { > { > the deployment models should be where things are standardised in { > anger. { > { > I disagree with that. { > { > { > { { > { -- { > { Dr. Michael Menth, Assistant Professor { > { University of Wuerzburg, Institute of Computer Science { > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > { mailto:menth@informatik.uni-wuerzburg.de { > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 02:05:19 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339263A6938; Wed, 22 Oct 2008 02:05:19 -0700 (PDT) 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 6E7263A6938 for ; Wed, 22 Oct 2008 02:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 VluT4a5PWuh6 for ; Wed, 22 Oct 2008 02:05:17 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id C829E3A67D0 for ; Wed, 22 Oct 2008 02:05:16 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 10:06:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 10:06:12 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000401c93423$da7e74b0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: Ack0Ia+EVfAwXAZqSVueOXT765e8sAAAgBTAAABgmIA= From: To: , X-OriginalArrivalTime: 22 Oct 2008 09:06:15.0951 (UTC) FILETIME=[705039F0:01C93425] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Remember that such choice adds complexity to the router, the standardisation and the operation. { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 22 October 2008 09:55 { To: menth@informatik.uni-wuerzburg.de; Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { { Hi all { { I agree with Michael that such constraints are better suitable for { deployment models. { { Best regards, { Georgios { { { > -----Original Message----- { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { > Behalf Of Michael Menth { > Sent: woensdag 22 oktober 2008 10:37 { > To: philip.eardley@bt.com { > Cc: pcn@ietf.org { > Subject: Re: [PCN] NewVersionNotification { > fordraft-ietf-pcn-baseline-encoding-01 { > { > Hi Phil, { > { > the issue is whether the marking draft should also restrict { > drop preferences. Dropping of marked packets is not needed { > from a general marking perspective. It's only needed for { > indirect measured rate termination which is only one { > termination option out of many others. { > Requiring preferential dropping of special packets only { > limits the number of options of what you can do with PCN { > marking. Therefore, such constraints are better suitable for { > deployment models. { > { > Regards, { > { > Michael { > { > philip.eardley@bt.com wrote: { > > The thing is that we discussed dropping quite a lot at/near { > the ietf { > > in Philadelphia, and the preferential dropping v reaction { > times argument. { > > not that it's impossible to re-visit the decision, but is there new { > > evidence or argument? { > > { > > phil { > > { > > { -----Original Message----- { > > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > > { Sent: 21 October 2008 17:22 { > > { To: Eardley,PL,Philip,CXR9 R { > > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: { > Re: [PCN] { > > New VersionNotification fordraft-ietf-pcn-baseline- { { > encoding-01 { { { > > Hi Phil, { { yes, you are right. My example was ill-conceived. { > > Currently I cannot { think either of a sensible deployment { > model that { > > would not meter all PCN { packets for threshold marking and all { > > unmarked PCN packets for excess { marking. { > > { { > > { My comment actually concerns the dropping behavior. Its { > definition { > > in { the marking draft unnecessarily constrains the use of { > the meters { > > and { markers and should be rather defined by deployment models. { > > { { > > { Of course, only sensible freedom should be allowed in the marking { > > and { encoding draft. What sensible freedom is depends on which { > > deployment { models should be able to be basically { > supported. Now or { > > possibly in the { future. { > > { { > > { Regards, { > > { { > > { Michael { > > { { > > { { > > { philip.eardley@bt.com wrote: { > > { > { { > > { > { my thinking is what you also suspect at the end of { > your email: { > > the { > { description of the packets to be metered and the { > packets to { > > be { > re-marked { > { is part of the deployment model and { > meters and { > > markers must be { > { configurable with regard to this respect. The { > > same applies to drop { > { preferences. It does not mean { > that anything { > > can be done in PCN. { > > The { > > { > { restrictions come through the deployment models that { > say which { { > > > building { > { blocks MUST be used and how they MUST be { > configured. { > > Then, metering { > and { > { marking can be kept general { > and encoding { > > does not need to know { > anything { > { about its future use. { > > { > { > > { > I disagree with this to some extent. { > > { > { > > { > I think that what pkts are metered and what re-marked { > is something { > > to be { > standardised in the encoding drafts. This allows { > each to be { > > carefully { > thought about and for manufacturers to say that their { > > kit is conformant { > with a STD. putting this in a { > deployment model { > > is not as good - there { > will (assuming pcn's success) { > potentially { > > be many deployment models, and { > many deployment models { > based on a { > > particular encoding. The framework is { > that the behaviour of the { > > interior nodes (in terms of both marking { > behaviour & { > encoding) is { > > simple and clear, without a whole lot of { > configurable options. { > > Meanwhile, there's more freedom in terms of the { > { > behaviour of the { > > gateways in how they interpret these marks. Of course { > { > it may turn { > > out that in practice there are only a couple of good sets of { > { > > gateway behaviour. { > > { > Anyway, I read your email as proposing that the marking and { > > encoding { > should allow lots of freedom with lots of configurable { > > options, and that { > the deployment models should be where { > things are { > > standardised in anger. { > > { > I disagree with that. { > > { > { > > { { > > { -- { > > { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, { > > Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, { > > Germany, room B206 { phone: (+49)-931/888-6644, fax: { > > (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { > > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > > { > { > -- { > Dr. Michael Menth, Assistant Professor { > University of Wuerzburg, Institute of Computer Science Am { > Hubland, D-97074 Wuerzburg, Germany, room B206 { > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > mailto:menth@informatik.uni-wuerzburg.de { > http://www3.informatik.uni-wuerzburg.de/research/ngn { > { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { > { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 02:38:31 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D5128C148; Wed, 22 Oct 2008 02:38:31 -0700 (PDT) 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 ECA7028C148 for ; Wed, 22 Oct 2008 02:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSfeJeuBh0tJ for ; Wed, 22 Oct 2008 02:38:28 -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 CD2E728C146 for ; Wed, 22 Oct 2008 02:38:27 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id F03C1198E4A; Wed, 22 Oct 2008 11:14:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E3CBB198E48; Wed, 22 Oct 2008 11:14:43 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id BE270A068C; Wed, 22 Oct 2008 11:14:43 +0200 (CEST) Message-ID: <48FEEEA1.2040009@informatik.uni-wuerzburg.de> Date: Wed, 22 Oct 2008 11:13:05 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3CD@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, I agree with you that the number of standardized deployment models should be kept to a minimum and to simplify deployment. However, the complexity of configuration, standardization, and operation rather depends on the complexity of the deployment model itself and there are large differences. I don't believe that this issue has been understood very well so far. Regards, Michael philip.eardley@bt.com wrote: > Remember that such choice adds complexity to the router, the > standardisation and the operation. > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 22 October 2008 09:55 > { To: menth@informatik.uni-wuerzburg.de; Eardley,PL,Philip,CXR9 R > { Cc: pcn@ietf.org > { Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- > { encoding-01 > { > { Hi all > { > { I agree with Michael that such constraints are better suitable for > { deployment models. > { > { Best regards, > { Georgios > { > { > { > -----Original Message----- > { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > { > Behalf Of Michael Menth > { > Sent: woensdag 22 oktober 2008 10:37 > { > To: philip.eardley@bt.com > { > Cc: pcn@ietf.org > { > Subject: Re: [PCN] NewVersionNotification > { > fordraft-ietf-pcn-baseline-encoding-01 > { > > { > Hi Phil, > { > > { > the issue is whether the marking draft should also restrict > { > drop preferences. Dropping of marked packets is not needed > { > from a general marking perspective. It's only needed for > { > indirect measured rate termination which is only one > { > termination option out of many others. > { > Requiring preferential dropping of special packets only > { > limits the number of options of what you can do with PCN > { > marking. Therefore, such constraints are better suitable for > { > deployment models. > { > > { > Regards, > { > > { > Michael > { > > { > philip.eardley@bt.com wrote: > { > > The thing is that we discussed dropping quite a lot at/near > { > the ietf > { > > in Philadelphia, and the preferential dropping v reaction > { > times argument. > { > > not that it's impossible to re-visit the decision, but is there > new > { > > evidence or argument? > { > > > { > > phil > { > > > { > > { -----Original Message----- > { > > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { > > { Sent: 21 October 2008 17:22 > { > > { To: Eardley,PL,Philip,CXR9 R > { > > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: > { > Re: [PCN] > { > > New VersionNotification fordraft-ietf-pcn-baseline- { > { > encoding-01 { { > { > > Hi Phil, { { yes, you are right. My example was ill-conceived. > { > > Currently I cannot { think either of a sensible deployment > { > model that > { > > would not meter all PCN { packets for threshold marking and all > { > > unmarked PCN packets for excess { marking. > { > > { > { > > { My comment actually concerns the dropping behavior. Its > { > definition > { > > in { the marking draft unnecessarily constrains the use of > { > the meters > { > > and { markers and should be rather defined by deployment models. > { > > { > { > > { Of course, only sensible freedom should be allowed in the > marking > { > > and { encoding draft. What sensible freedom is depends on which > { > > deployment { models should be able to be basically > { > supported. Now or > { > > possibly in the { future. > { > > { > { > > { Regards, > { > > { > { > > { Michael > { > > { > { > > { > { > > { philip.eardley@bt.com wrote: > { > > { > { > { > > { > { my thinking is what you also suspect at the end of > { > your email: > { > > the { > { description of the packets to be metered and the > { > packets to > { > > be { > re-marked { > { is part of the deployment model and > { > meters and > { > > markers must be { > { configurable with regard to this respect. > The > { > > same applies to drop { > { preferences. It does not mean > { > that anything > { > > can be done in PCN. > { > > The > { > > { > { restrictions come through the deployment models that > { > say which { > { > > > building { > { blocks MUST be used and how they MUST be > { > configured. > { > > Then, metering { > and { > { marking can be kept general > { > and encoding > { > > does not need to know { > anything { > { about its future use. > { > > { > > { > > { > I disagree with this to some extent. > { > > { > > { > > { > I think that what pkts are metered and what re-marked > { > is something > { > > to be { > standardised in the encoding drafts. This allows > { > each to be > { > > carefully { > thought about and for manufacturers to say that > their > { > > kit is conformant { > with a STD. putting this in a > { > deployment model > { > > is not as good - there { > will (assuming pcn's success) > { > potentially > { > > be many deployment models, and { > many deployment models > { > based on a > { > > particular encoding. The framework is { > that the behaviour of > the > { > > interior nodes (in terms of both marking { > behaviour & > { > encoding) is > { > > simple and clear, without a whole lot of { > configurable options. > { > > Meanwhile, there's more freedom in terms of the { > > { > behaviour of the > { > > gateways in how they interpret these marks. Of course { > > { > it may turn > { > > out that in practice there are only a couple of good sets of { > > { > > gateway behaviour. > { > > { > Anyway, I read your email as proposing that the marking and > { > > encoding { > should allow lots of freedom with lots of > configurable > { > > options, and that { > the deployment models should be where > { > things are > { > > standardised in anger. > { > > { > I disagree with that. > { > > { > > { > > { > { > > { -- > { > > { Dr. Michael Menth, Assistant Professor { University of > Wuerzburg, > { > > Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, > { > > Germany, room B206 { phone: (+49)-931/888-6644, fax: > { > > (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de > { > > { http://www3.informatik.uni-wuerzburg.de/research/ngn > { > > > { > > { > -- > { > Dr. Michael Menth, Assistant Professor > { > University of Wuerzburg, Institute of Computer Science Am > { > Hubland, D-97074 Wuerzburg, Germany, room B206 > { > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { > mailto:menth@informatik.uni-wuerzburg.de > { > http://www3.informatik.uni-wuerzburg.de/research/ngn > { > > { > _______________________________________________ > { > PCN mailing list > { > PCN@ietf.org > { > https://www.ietf.org/mailman/listinfo/pcn > { > > { > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 05:56:07 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6143A69E9; Wed, 22 Oct 2008 05:56:07 -0700 (PDT) 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 0371E3A6899 for ; Wed, 22 Oct 2008 05:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 2Xy+GrGrzmMS for ; Wed, 22 Oct 2008 05:56: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 1DCCB3A6A03 for ; Wed, 22 Oct 2008 05:56:03 -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, 22 Oct 2008 13:57:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 13:57:18 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3D1@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48FEEEA1.2040009@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: Ack0JqICM1+UnSQWR1GyGNpjtuZcDgAHe3+A From: To: X-OriginalArrivalTime: 22 Oct 2008 12:57:20.0080 (UTC) FILETIME=[B7FA6D00:01C93445] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org The marking draft at the moment gives very low complexity of interior nodes and their configuration, eg parameters are the threshold-rate & excess-traffic-rate. Complexity of the boundary nodes is something that we understand less well. I see the deployment model as being about the boundary node behaviour, where it's appropriate to have a bit of freedom in terms of >1 different (EXP) behaviours. { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 22 October 2008 10:13 { To: Eardley,PL,Philip,CXR9 R { Cc: karagian@cs.utwente.nl; pcn@ietf.org { Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { { Hi Phil, { { I agree with you that the number of standardized deployment models { should be kept to a minimum and to simplify deployment. However, the { complexity of configuration, standardization, and operation rather { depends on the complexity of the deployment model itself and there are { large differences. I don't believe that this issue has been understood { very well so far. { { Regards, { { Michael { { philip.eardley@bt.com wrote: { > Remember that such choice adds complexity to the router, the { > standardisation and the operation. { > { > { -----Original Message----- { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { Sent: 22 October 2008 09:55 { > { To: menth@informatik.uni-wuerzburg.de; Eardley,PL,Philip,CXR9 R { > { Cc: pcn@ietf.org { > { Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- { > { encoding-01 { > { { > { Hi all { > { { > { I agree with Michael that such constraints are better suitable for { > { deployment models. { > { { > { Best regards, { > { Georgios { > { { > { { > { > -----Original Message----- { > { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { > { > Behalf Of Michael Menth { > { > Sent: woensdag 22 oktober 2008 10:37 { > { > To: philip.eardley@bt.com { > { > Cc: pcn@ietf.org { > { > Subject: Re: [PCN] NewVersionNotification { > { > fordraft-ietf-pcn-baseline-encoding-01 { > { > { > { > Hi Phil, { > { > { > { > the issue is whether the marking draft should also restrict { > { > drop preferences. Dropping of marked packets is not needed { > { > from a general marking perspective. It's only needed for { > { > indirect measured rate termination which is only one { > { > termination option out of many others. { > { > Requiring preferential dropping of special packets only { > { > limits the number of options of what you can do with PCN { > { > marking. Therefore, such constraints are better suitable for { > { > deployment models. { > { > { > { > Regards, { > { > { > { > Michael { > { > { > { > philip.eardley@bt.com wrote: { > { > > The thing is that we discussed dropping quite a lot at/near { > { > the ietf { > { > > in Philadelphia, and the preferential dropping v reaction { > { > times argument. { > { > > not that it's impossible to re-visit the decision, but is there { > new { > { > > evidence or argument? { > { > > { > { > > phil { > { > > { > { > > { -----Original Message----- { > { > > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { > { > > { Sent: 21 October 2008 17:22 { > { > > { To: Eardley,PL,Philip,CXR9 R { > { > > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: { > { > Re: [PCN] { > { > > New VersionNotification fordraft-ietf-pcn-baseline- { { > { > encoding-01 { { { > { > > Hi Phil, { { yes, you are right. My example was ill-conceived. { > { > > Currently I cannot { think either of a sensible deployment { > { > model that { > { > > would not meter all PCN { packets for threshold marking and all { > { > > unmarked PCN packets for excess { marking. { > { > > { { > { > > { My comment actually concerns the dropping behavior. Its { > { > definition { > { > > in { the marking draft unnecessarily constrains the use of { > { > the meters { > { > > and { markers and should be rather defined by deployment models. { > { > > { { > { > > { Of course, only sensible freedom should be allowed in the { > marking { > { > > and { encoding draft. What sensible freedom is depends on which { > { > > deployment { models should be able to be basically { > { > supported. Now or { > { > > possibly in the { future. { > { > > { { > { > > { Regards, { > { > > { { > { > > { Michael { > { > > { { > { > > { { > { > > { philip.eardley@bt.com wrote: { > { > > { > { { > { > > { > { my thinking is what you also suspect at the end of { > { > your email: { > { > > the { > { description of the packets to be metered and the { > { > packets to { > { > > be { > re-marked { > { is part of the deployment model and { > { > meters and { > { > > markers must be { > { configurable with regard to this respect. { > The { > { > > same applies to drop { > { preferences. It does not mean { > { > that anything { > { > > can be done in PCN. { > { > > The { > { > > { > { restrictions come through the deployment models that { > { > say which { { > { > > > building { > { blocks MUST be used and how they MUST be { > { > configured. { > { > > Then, metering { > and { > { marking can be kept general { > { > and encoding { > { > > does not need to know { > anything { > { about its future use. { > { > > { > { > { > > { > I disagree with this to some extent. { > { > > { > { > { > > { > I think that what pkts are metered and what re-marked { > { > is something { > { > > to be { > standardised in the encoding drafts. This allows { > { > each to be { > { > > carefully { > thought about and for manufacturers to say that { > their { > { > > kit is conformant { > with a STD. putting this in a { > { > deployment model { > { > > is not as good - there { > will (assuming pcn's success) { > { > potentially { > { > > be many deployment models, and { > many deployment models { > { > based on a { > { > > particular encoding. The framework is { > that the behaviour of { > the { > { > > interior nodes (in terms of both marking { > behaviour & { > { > encoding) is { > { > > simple and clear, without a whole lot of { > configurable options. { > { > > Meanwhile, there's more freedom in terms of the { > { > { > behaviour of the { > { > > gateways in how they interpret these marks. Of course { > { > { > it may turn { > { > > out that in practice there are only a couple of good sets of { > { > { > > gateway behaviour. { > { > > { > Anyway, I read your email as proposing that the marking and { > { > > encoding { > should allow lots of freedom with lots of { > configurable { > { > > options, and that { > the deployment models should be where { > { > things are { > { > > standardised in anger. { > { > > { > I disagree with that. { > { > > { > { > { > > { { > { > > { -- { > { > > { Dr. Michael Menth, Assistant Professor { University of { > Wuerzburg, { > { > > Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, { > { > > Germany, room B206 { phone: (+49)-931/888-6644, fax: { > { > > (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { > { > > { http://www3.informatik.uni-wuerzburg.de/research/ngn { > { > > { > { > { > { > -- { > { > Dr. Michael Menth, Assistant Professor { > { > University of Wuerzburg, Institute of Computer Science Am { > { > Hubland, D-97074 Wuerzburg, Germany, room B206 { > { > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { > { > mailto:menth@informatik.uni-wuerzburg.de { > { > http://www3.informatik.uni-wuerzburg.de/research/ngn { > { > { > { > _______________________________________________ { > { > PCN mailing list { > { > PCN@ietf.org { > { > https://www.ietf.org/mailman/listinfo/pcn { > { > { > { { > { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 06:18:08 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472B53A6B80; Wed, 22 Oct 2008 06:18:08 -0700 (PDT) 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 CC10B3A6B80 for ; Wed, 22 Oct 2008 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=0.096, 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 HlbEopY0IOuj for ; Wed, 22 Oct 2008 06:18:06 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 0DAC83A69BF for ; Wed, 22 Oct 2008 06:18:05 -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); Wed, 22 Oct 2008 14:18:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 14:18:41 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3D1@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: Ack0JqICM1+UnSQWR1GyGNpjtuZcDgAHe3+AAAD69aA= References: <48FEEEA1.2040009@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA3D1@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 22 Oct 2008 13:18:46.0602 (UTC) FILETIME=[B6CE1AA0:01C93448] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I think I agree with Phil. We want to have a PCN system which can work "out of the box" with the minimum configuration necessary. Any refinements can then be done principally at boundary nodes where most of the control mechanism will sit. Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 22 October 2008 13:57 > To: menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline- > encoding-01 > > The marking draft at the moment gives very low complexity of interior > nodes and their configuration, eg parameters are the threshold-rate & > excess-traffic-rate. Complexity of the boundary nodes is something that > we understand less well. I see the deployment model as being about the > boundary node behaviour, where it's appropriate to have a bit of > freedom > in terms of >1 different (EXP) behaviours. > { -----Original Message----- > { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > { Sent: 22 October 2008 10:13 > { To: Eardley,PL,Philip,CXR9 R > { Cc: karagian@cs.utwente.nl; pcn@ietf.org > { Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline- > { encoding-01 > { > { Hi Phil, > { > { I agree with you that the number of standardized deployment models > { should be kept to a minimum and to simplify deployment. However, the > { complexity of configuration, standardization, and operation rather > { depends on the complexity of the deployment model itself and there > are > { large differences. I don't believe that this issue has been > understood > { very well so far. > { > { Regards, > { > { Michael > { > { philip.eardley@bt.com wrote: > { > Remember that such choice adds complexity to the router, the > { > standardisation and the operation. > { > > { > { -----Original Message----- > { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { > { Sent: 22 October 2008 09:55 > { > { To: menth@informatik.uni-wuerzburg.de; Eardley,PL,Philip,CXR9 R > { > { Cc: pcn@ietf.org > { > { Subject: RE: [PCN] NewVersionNotification > fordraft-ietf-pcn-baseline- > { > { encoding-01 > { > { > { > { Hi all > { > { > { > { I agree with Michael that such constraints are better suitable > for > { > { deployment models. > { > { > { > { Best regards, > { > { Georgios > { > { > { > { > { > { > -----Original Message----- > { > { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > { > { > Behalf Of Michael Menth > { > { > Sent: woensdag 22 oktober 2008 10:37 > { > { > To: philip.eardley@bt.com > { > { > Cc: pcn@ietf.org > { > { > Subject: Re: [PCN] NewVersionNotification > { > { > fordraft-ietf-pcn-baseline-encoding-01 > { > { > > { > { > Hi Phil, > { > { > > { > { > the issue is whether the marking draft should also restrict > { > { > drop preferences. Dropping of marked packets is not needed > { > { > from a general marking perspective. It's only needed for > { > { > indirect measured rate termination which is only one > { > { > termination option out of many others. > { > { > Requiring preferential dropping of special packets only > { > { > limits the number of options of what you can do with PCN > { > { > marking. Therefore, such constraints are better suitable for > { > { > deployment models. > { > { > > { > { > Regards, > { > { > > { > { > Michael > { > { > > { > { > philip.eardley@bt.com wrote: > { > { > > The thing is that we discussed dropping quite a lot at/near > { > { > the ietf > { > { > > in Philadelphia, and the preferential dropping v reaction > { > { > times argument. > { > { > > not that it's impossible to re-visit the decision, but is > there > { > new > { > { > > evidence or argument? > { > { > > > { > { > > phil > { > { > > > { > { > > { -----Original Message----- > { > { > > { From: Michael Menth > [mailto:menth@informatik.uni-wuerzburg.de] > { > { > > { Sent: 21 October 2008 17:22 > { > { > > { To: Eardley,PL,Philip,CXR9 R > { > { > > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: > { > { > Re: [PCN] > { > { > > New VersionNotification fordraft-ietf-pcn-baseline- { > { > { > encoding-01 { { > { > { > > Hi Phil, { { yes, you are right. My example was ill- > conceived. > { > { > > Currently I cannot { think either of a sensible deployment > { > { > model that > { > { > > would not meter all PCN { packets for threshold marking and > all > { > { > > unmarked PCN packets for excess { marking. > { > { > > { > { > { > > { My comment actually concerns the dropping behavior. Its > { > { > definition > { > { > > in { the marking draft unnecessarily constrains the use of > { > { > the meters > { > { > > and { markers and should be rather defined by deployment > models. > { > { > > { > { > { > > { Of course, only sensible freedom should be allowed in the > { > marking > { > { > > and { encoding draft. What sensible freedom is depends on > which > { > { > > deployment { models should be able to be basically > { > { > supported. Now or > { > { > > possibly in the { future. > { > { > > { > { > { > > { Regards, > { > { > > { > { > { > > { Michael > { > { > > { > { > { > > { > { > { > > { philip.eardley@bt.com wrote: > { > { > > { > { > { > { > > { > { my thinking is what you also suspect at the end of > { > { > your email: > { > { > > the { > { description of the packets to be metered and the > { > { > packets to > { > { > > be { > re-marked { > { is part of the deployment model and > { > { > meters and > { > { > > markers must be { > { configurable with regard to this > respect. > { > The > { > { > > same applies to drop { > { preferences. It does not mean > { > { > that anything > { > { > > can be done in PCN. > { > { > > The > { > { > > { > { restrictions come through the deployment models that > { > { > say which { > { > { > > > building { > { blocks MUST be used and how they MUST be > { > { > configured. > { > { > > Then, metering { > and { > { marking can be kept general > { > { > and encoding > { > { > > does not need to know { > anything { > { about its future > use. > { > { > > { > > { > { > > { > I disagree with this to some extent. > { > { > > { > > { > { > > { > I think that what pkts are metered and what re-marked > { > { > is something > { > { > > to be { > standardised in the encoding drafts. This allows > { > { > each to be > { > { > > carefully { > thought about and for manufacturers to say that > { > their > { > { > > kit is conformant { > with a STD. putting this in a > { > { > deployment model > { > { > > is not as good - there { > will (assuming pcn's success) > { > { > potentially > { > { > > be many deployment models, and { > many deployment models > { > { > based on a > { > { > > particular encoding. The framework is { > that the behaviour > of > { > the > { > { > > interior nodes (in terms of both marking { > behaviour & > { > { > encoding) is > { > { > > simple and clear, without a whole lot of { > configurable > options. > { > { > > Meanwhile, there's more freedom in terms of the { > > { > { > behaviour of the > { > { > > gateways in how they interpret these marks. Of course { > > { > { > it may turn > { > { > > out that in practice there are only a couple of good sets of > { > > > { > { > > gateway behaviour. > { > { > > { > Anyway, I read your email as proposing that the marking > and > { > { > > encoding { > should allow lots of freedom with lots of > { > configurable > { > { > > options, and that { > the deployment models should be where > { > { > things are > { > { > > standardised in anger. > { > { > > { > I disagree with that. > { > { > > { > > { > { > > { > { > { > > { -- > { > { > > { Dr. Michael Menth, Assistant Professor { University of > { > Wuerzburg, > { > { > > Institute of Computer Science { Am Hubland, D-97074 > Wuerzburg, > { > { > > Germany, room B206 { phone: (+49)-931/888-6644, fax: > { > { > > (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de > { > { > > { http://www3.informatik.uni-wuerzburg.de/research/ngn > { > { > > > { > { > > { > { > -- > { > { > Dr. Michael Menth, Assistant Professor > { > { > University of Wuerzburg, Institute of Computer Science Am > { > { > Hubland, D-97074 Wuerzburg, Germany, room B206 > { > { > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { > { > mailto:menth@informatik.uni-wuerzburg.de > { > { > http://www3.informatik.uni-wuerzburg.de/research/ngn > { > { > > { > { > _______________________________________________ > { > { > PCN mailing list > { > { > PCN@ietf.org > { > { > https://www.ietf.org/mailman/listinfo/pcn > { > { > > { > { > { > > { > { -- > { Dr. Michael Menth, Assistant Professor > { University of Wuerzburg, Institute of Computer Science > { Am Hubland, D-97074 Wuerzburg, Germany, room B206 > { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > { mailto:menth@informatik.uni-wuerzburg.de > { http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 06:32:59 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5BD3A69BF; Wed, 22 Oct 2008 06:32:59 -0700 (PDT) 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 A28E13A6A08 for ; Wed, 22 Oct 2008 06:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uimc3wf-jG0m for ; Wed, 22 Oct 2008 06:32:56 -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 D58953A6899 for ; Wed, 22 Oct 2008 06:32:55 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id AB283198DF4; Wed, 22 Oct 2008 15:33:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9F12A198DE7; Wed, 22 Oct 2008 15:33:45 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 80F65A05C0; Wed, 22 Oct 2008 15:33:45 +0200 (CEST) Message-ID: <48FF2B56.5040106@informatik.uni-wuerzburg.de> Date: Wed, 22 Oct 2008 15:32:06 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: toby.moncaster@bt.com, philip.eardley@bt.com References: <48FEEEA1.2040009@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA3D1@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil and Toby, the problem I see is the following. 1) Drop preferences do not have anything to do with marking. What you have in mind to standardize is the PCN internal node behavior which is part of a deployment model (excess and/or threshold marking based on which rates, drop preferences). 2) The nice "out of the box" behavior mentioned by Toby can be achieved with a knob "deployment model X" which effects the required settings in the router. 3) If preferential dropping of marked packets is the only option for dropping behavior for PCN internal nodes, the only indirect measured rate termination (IMRT) is possible as flow termination mechanism and this is very complex. That's already understood. So, there is not much room for further refinement. Regards, Michael toby.moncaster@bt.com wrote: > I think I agree with Phil. We want to have a PCN system which can work > "out of the box" with the minimum configuration necessary. Any > refinements can then be done principally at boundary nodes where most of > the control mechanism will sit. > > Toby > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> philip.eardley@bt.com >> Sent: 22 October 2008 13:57 >> To: menth@informatik.uni-wuerzburg.de >> Cc: pcn@ietf.org >> Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline- >> encoding-01 >> >> The marking draft at the moment gives very low complexity of interior >> nodes and their configuration, eg parameters are the threshold-rate & >> excess-traffic-rate. Complexity of the boundary nodes is something >> > that > >> we understand less well. I see the deployment model as being about the >> boundary node behaviour, where it's appropriate to have a bit of >> freedom >> in terms of >1 different (EXP) behaviours. >> { -----Original Message----- >> { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> { Sent: 22 October 2008 10:13 >> { To: Eardley,PL,Philip,CXR9 R >> { Cc: karagian@cs.utwente.nl; pcn@ietf.org >> { Subject: Re: [PCN] NewVersionNotification >> > fordraft-ietf-pcn-baseline- > >> { encoding-01 >> { >> { Hi Phil, >> { >> { I agree with you that the number of standardized deployment models >> { should be kept to a minimum and to simplify deployment. However, the >> { complexity of configuration, standardization, and operation rather >> { depends on the complexity of the deployment model itself and there >> are >> { large differences. I don't believe that this issue has been >> understood >> { very well so far. >> { >> { Regards, >> { >> { Michael >> { >> { philip.eardley@bt.com wrote: >> { > Remember that such choice adds complexity to the router, the >> { > standardisation and the operation. >> { > >> { > { -----Original Message----- >> { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> { > { Sent: 22 October 2008 09:55 >> { > { To: menth@informatik.uni-wuerzburg.de; Eardley,PL,Philip,CXR9 R >> { > { Cc: pcn@ietf.org >> { > { Subject: RE: [PCN] NewVersionNotification >> fordraft-ietf-pcn-baseline- >> { > { encoding-01 >> { > { >> { > { Hi all >> { > { >> { > { I agree with Michael that such constraints are better suitable >> for >> { > { deployment models. >> { > { >> { > { Best regards, >> { > { Georgios >> { > { >> { > { >> { > { > -----Original Message----- >> { > { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> { > { > Behalf Of Michael Menth >> { > { > Sent: woensdag 22 oktober 2008 10:37 >> { > { > To: philip.eardley@bt.com >> { > { > Cc: pcn@ietf.org >> { > { > Subject: Re: [PCN] NewVersionNotification >> { > { > fordraft-ietf-pcn-baseline-encoding-01 >> { > { > >> { > { > Hi Phil, >> { > { > >> { > { > the issue is whether the marking draft should also restrict >> { > { > drop preferences. Dropping of marked packets is not needed >> { > { > from a general marking perspective. It's only needed for >> { > { > indirect measured rate termination which is only one >> { > { > termination option out of many others. >> { > { > Requiring preferential dropping of special packets only >> { > { > limits the number of options of what you can do with PCN >> { > { > marking. Therefore, such constraints are better suitable for >> { > { > deployment models. >> { > { > >> { > { > Regards, >> { > { > >> { > { > Michael >> { > { > >> { > { > philip.eardley@bt.com wrote: >> { > { > > The thing is that we discussed dropping quite a lot at/near >> { > { > the ietf >> { > { > > in Philadelphia, and the preferential dropping v reaction >> { > { > times argument. >> { > { > > not that it's impossible to re-visit the decision, but is >> there >> { > new >> { > { > > evidence or argument? >> { > { > > >> { > { > > phil >> { > { > > >> { > { > > { -----Original Message----- >> { > { > > { From: Michael Menth >> [mailto:menth@informatik.uni-wuerzburg.de] >> { > { > > { Sent: 21 October 2008 17:22 >> { > { > > { To: Eardley,PL,Philip,CXR9 R >> { > { > > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: >> { > { > Re: [PCN] >> { > { > > New VersionNotification fordraft-ietf-pcn-baseline- { >> { > { > encoding-01 { { >> { > { > > Hi Phil, { { yes, you are right. My example was ill- >> conceived. >> { > { > > Currently I cannot { think either of a sensible deployment >> { > { > model that >> { > { > > would not meter all PCN { packets for threshold marking and >> all >> { > { > > unmarked PCN packets for excess { marking. >> { > { > > { >> { > { > > { My comment actually concerns the dropping behavior. Its >> { > { > definition >> { > { > > in { the marking draft unnecessarily constrains the use of >> { > { > the meters >> { > { > > and { markers and should be rather defined by deployment >> models. >> { > { > > { >> { > { > > { Of course, only sensible freedom should be allowed in the >> { > marking >> { > { > > and { encoding draft. What sensible freedom is depends on >> which >> { > { > > deployment { models should be able to be basically >> { > { > supported. Now or >> { > { > > possibly in the { future. >> { > { > > { >> { > { > > { Regards, >> { > { > > { >> { > { > > { Michael >> { > { > > { >> { > { > > { >> { > { > > { philip.eardley@bt.com wrote: >> { > { > > { > { >> { > { > > { > { my thinking is what you also suspect at the end of >> { > { > your email: >> { > { > > the { > { description of the packets to be metered and the >> { > { > packets to >> { > { > > be { > re-marked { > { is part of the deployment model and >> { > { > meters and >> { > { > > markers must be { > { configurable with regard to this >> respect. >> { > The >> { > { > > same applies to drop { > { preferences. It does not mean >> { > { > that anything >> { > { > > can be done in PCN. >> { > { > > The >> { > { > > { > { restrictions come through the deployment models that >> { > { > say which { >> { > { > > > building { > { blocks MUST be used and how they MUST be >> { > { > configured. >> { > { > > Then, metering { > and { > { marking can be kept general >> { > { > and encoding >> { > { > > does not need to know { > anything { > { about its future >> use. >> { > { > > { > >> { > { > > { > I disagree with this to some extent. >> { > { > > { > >> { > { > > { > I think that what pkts are metered and what re-marked >> { > { > is something >> { > { > > to be { > standardised in the encoding drafts. This allows >> { > { > each to be >> { > { > > carefully { > thought about and for manufacturers to say >> > that > >> { > their >> { > { > > kit is conformant { > with a STD. putting this in a >> { > { > deployment model >> { > { > > is not as good - there { > will (assuming pcn's success) >> { > { > potentially >> { > { > > be many deployment models, and { > many deployment models >> { > { > based on a >> { > { > > particular encoding. The framework is { > that the behaviour >> of >> { > the >> { > { > > interior nodes (in terms of both marking { > behaviour & >> { > { > encoding) is >> { > { > > simple and clear, without a whole lot of { > configurable >> options. >> { > { > > Meanwhile, there's more freedom in terms of the { > >> { > { > behaviour of the >> { > { > > gateways in how they interpret these marks. Of course { > >> { > { > it may turn >> { > { > > out that in practice there are only a couple of good sets of >> { >> >> { > { > > gateway behaviour. >> { > { > > { > Anyway, I read your email as proposing that the marking >> and >> { > { > > encoding { > should allow lots of freedom with lots of >> { > configurable >> { > { > > options, and that { > the deployment models should be where >> { > { > things are >> { > { > > standardised in anger. >> { > { > > { > I disagree with that. >> { > { > > { > >> { > { > > { >> { > { > > { -- >> { > { > > { Dr. Michael Menth, Assistant Professor { University of >> { > Wuerzburg, >> { > { > > Institute of Computer Science { Am Hubland, D-97074 >> Wuerzburg, >> { > { > > Germany, room B206 { phone: (+49)-931/888-6644, fax: >> { > { > > (+49)-931/888-6632 { >> > mailto:menth@informatik.uni-wuerzburg.de > >> { > { > > { http://www3.informatik.uni-wuerzburg.de/research/ngn >> { > { > > >> { > { > >> { > { > -- >> { > { > Dr. Michael Menth, Assistant Professor >> { > { > University of Wuerzburg, Institute of Computer Science Am >> { > { > Hubland, D-97074 Wuerzburg, Germany, room B206 >> { > { > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >> { > { > mailto:menth@informatik.uni-wuerzburg.de >> { > { > http://www3.informatik.uni-wuerzburg.de/research/ngn >> { > { > >> { > { > _______________________________________________ >> { > { > PCN mailing list >> { > { > PCN@ietf.org >> { > { > https://www.ietf.org/mailman/listinfo/pcn >> { > { > >> { > { >> { > >> { >> { -- >> { Dr. Michael Menth, Assistant Professor >> { University of Wuerzburg, Institute of Computer Science >> { Am Hubland, D-97074 Wuerzburg, Germany, room B206 >> { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >> { mailto:menth@informatik.uni-wuerzburg.de >> { http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 22 07:07:36 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D5528C104; Wed, 22 Oct 2008 07:07:36 -0700 (PDT) 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 A3BA93A677D for ; Wed, 22 Oct 2008 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.341, 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 fP+nK531I-aK for ; Wed, 22 Oct 2008 07:07:33 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id B9E2228C104 for ; Wed, 22 Oct 2008 07:07:32 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 15:08:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 15:08:36 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3D3@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <48FF2B56.5040106@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 Thread-Index: Ack0StJnOaIbIKZMTjOBkJeyXd5XzQAAv2aA From: To: , X-OriginalArrivalTime: 22 Oct 2008 14:08:37.0684 (UTC) FILETIME=[ADA0FF40:01C9344F] Cc: pcn@ietf.org Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 22 October 2008 14:32 { To: Moncaster,T,Toby,CXR9 R; Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline- { encoding-01 { { Hi Phil and Toby, { { the problem I see is the following. { { 1) Drop preferences do not have anything to do with marking. What you { have in mind to standardize is the PCN internal node behavior which is { part of a deployment model (excess and/or threshold marking based on { which rates, drop preferences). No. the meter rates are just parameters. Don't care what the edge behaviours are. The fact that the excess rate is equal to the PCN-admissible-rate or PCN-supportable-rate is something quite invisible to the meter! { 2) The nice "out of the box" behavior mentioned by Toby can be achieved { with a knob "deployment model X" which effects the required settings in { the router. (call it a deployment knob seems to be disguising what you're proposing - which is to have different PCN-interior-router behaviours, ie configurable whether it does preferential dropping or not of pkts that are already excess traffic marked. ) { 3) If preferential dropping of marked packets is the only option for { dropping behavior for PCN internal nodes, the only indirect measured { rate termination (IMRT) is possible as flow termination mechanism no it isnt. The reaction of speed of marked flow termination is slower but it still works - and if reaction speed is your most important factor you wouldn't be using marked flow termination (its benefit is in terms of not having to make measurements of flow rates). That was my understanding before, and will read your report on the plane. and { this is very complex. That's already understood. So, there is not much { room for further refinement. { { Regards, { { Michael { { { toby.moncaster@bt.com wrote: { > I think I agree with Phil. We want to have a PCN system which can work { > "out of the box" with the minimum configuration necessary. Any { > refinements can then be done principally at boundary nodes where most of { > the control mechanism will sit. { > { > Toby { > { > { >> -----Original Message----- { >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { >> philip.eardley@bt.com { >> Sent: 22 October 2008 13:57 { >> To: menth@informatik.uni-wuerzburg.de { >> Cc: pcn@ietf.org { >> Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline- { >> encoding-01 { >> { >> The marking draft at the moment gives very low complexity of interior { >> nodes and their configuration, eg parameters are the threshold-rate & { >> excess-traffic-rate. Complexity of the boundary nodes is something { >> { > that { > { >> we understand less well. I see the deployment model as being about the { >> boundary node behaviour, where it's appropriate to have a bit of { >> freedom { >> in terms of >1 different (EXP) behaviours. { >> { -----Original Message----- { >> { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { >> { Sent: 22 October 2008 10:13 { >> { To: Eardley,PL,Philip,CXR9 R { >> { Cc: karagian@cs.utwente.nl; pcn@ietf.org { >> { Subject: Re: [PCN] NewVersionNotification { >> { > fordraft-ietf-pcn-baseline- { > { >> { encoding-01 { >> { { >> { Hi Phil, { >> { { >> { I agree with you that the number of standardized deployment models { >> { should be kept to a minimum and to simplify deployment. However, the { >> { complexity of configuration, standardization, and operation rather { >> { depends on the complexity of the deployment model itself and there { >> are { >> { large differences. I don't believe that this issue has been { >> understood { >> { very well so far. { >> { { >> { Regards, { >> { { >> { Michael { >> { { >> { philip.eardley@bt.com wrote: { >> { > Remember that such choice adds complexity to the router, the { >> { > standardisation and the operation. { >> { > { >> { > { -----Original Message----- { >> { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { >> { > { Sent: 22 October 2008 09:55 { >> { > { To: menth@informatik.uni-wuerzburg.de; Eardley,PL,Philip,CXR9 R { >> { > { Cc: pcn@ietf.org { >> { > { Subject: RE: [PCN] NewVersionNotification { >> fordraft-ietf-pcn-baseline- { >> { > { encoding-01 { >> { > { { >> { > { Hi all { >> { > { { >> { > { I agree with Michael that such constraints are better suitable { >> for { >> { > { deployment models. { >> { > { { >> { > { Best regards, { >> { > { Georgios { >> { > { { >> { > { { >> { > { > -----Original Message----- { >> { > { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { >> { > { > Behalf Of Michael Menth { >> { > { > Sent: woensdag 22 oktober 2008 10:37 { >> { > { > To: philip.eardley@bt.com { >> { > { > Cc: pcn@ietf.org { >> { > { > Subject: Re: [PCN] NewVersionNotification { >> { > { > fordraft-ietf-pcn-baseline-encoding-01 { >> { > { > { >> { > { > Hi Phil, { >> { > { > { >> { > { > the issue is whether the marking draft should also restrict { >> { > { > drop preferences. Dropping of marked packets is not needed { >> { > { > from a general marking perspective. It's only needed for { >> { > { > indirect measured rate termination which is only one { >> { > { > termination option out of many others. { >> { > { > Requiring preferential dropping of special packets only { >> { > { > limits the number of options of what you can do with PCN { >> { > { > marking. Therefore, such constraints are better suitable for { >> { > { > deployment models. { >> { > { > { >> { > { > Regards, { >> { > { > { >> { > { > Michael { >> { > { > { >> { > { > philip.eardley@bt.com wrote: { >> { > { > > The thing is that we discussed dropping quite a lot at/near { >> { > { > the ietf { >> { > { > > in Philadelphia, and the preferential dropping v reaction { >> { > { > times argument. { >> { > { > > not that it's impossible to re-visit the decision, but is { >> there { >> { > new { >> { > { > > evidence or argument? { >> { > { > > { >> { > { > > phil { >> { > { > > { >> { > { > > { -----Original Message----- { >> { > { > > { From: Michael Menth { >> [mailto:menth@informatik.uni-wuerzburg.de] { >> { > { > > { Sent: 21 October 2008 17:22 { >> { > { > > { To: Eardley,PL,Philip,CXR9 R { >> { > { > > { Cc: Ruediger.Geib@t-systems.com; pcn@ietf.org { Subject: { >> { > { > Re: [PCN] { >> { > { > > New VersionNotification fordraft-ietf-pcn-baseline- { { >> { > { > encoding-01 { { { >> { > { > > Hi Phil, { { yes, you are right. My example was ill- { >> conceived. { >> { > { > > Currently I cannot { think either of a sensible deployment { >> { > { > model that { >> { > { > > would not meter all PCN { packets for threshold marking and { >> all { >> { > { > > unmarked PCN packets for excess { marking. { >> { > { > > { { >> { > { > > { My comment actually concerns the dropping behavior. Its { >> { > { > definition { >> { > { > > in { the marking draft unnecessarily constrains the use of { >> { > { > the meters { >> { > { > > and { markers and should be rather defined by deployment { >> models. { >> { > { > > { { >> { > { > > { Of course, only sensible freedom should be allowed in the { >> { > marking { >> { > { > > and { encoding draft. What sensible freedom is depends on { >> which { >> { > { > > deployment { models should be able to be basically { >> { > { > supported. Now or { >> { > { > > possibly in the { future. { >> { > { > > { { >> { > { > > { Regards, { >> { > { > > { { >> { > { > > { Michael { >> { > { > > { { >> { > { > > { { >> { > { > > { philip.eardley@bt.com wrote: { >> { > { > > { > { { >> { > { > > { > { my thinking is what you also suspect at the end of { >> { > { > your email: { >> { > { > > the { > { description of the packets to be metered and the { >> { > { > packets to { >> { > { > > be { > re-marked { > { is part of the deployment model and { >> { > { > meters and { >> { > { > > markers must be { > { configurable with regard to this { >> respect. { >> { > The { >> { > { > > same applies to drop { > { preferences. It does not mean { >> { > { > that anything { >> { > { > > can be done in PCN. { >> { > { > > The { >> { > { > > { > { restrictions come through the deployment models that { >> { > { > say which { { >> { > { > > > building { > { blocks MUST be used and how they MUST be { >> { > { > configured. { >> { > { > > Then, metering { > and { > { marking can be kept general { >> { > { > and encoding { >> { > { > > does not need to know { > anything { > { about its future { >> use. { >> { > { > > { > { >> { > { > > { > I disagree with this to some extent. { >> { > { > > { > { >> { > { > > { > I think that what pkts are metered and what re-marked { >> { > { > is something { >> { > { > > to be { > standardised in the encoding drafts. This allows { >> { > { > each to be { >> { > { > > carefully { > thought about and for manufacturers to say { >> { > that { > { >> { > their { >> { > { > > kit is conformant { > with a STD. putting this in a { >> { > { > deployment model { >> { > { > > is not as good - there { > will (assuming pcn's success) { >> { > { > potentially { >> { > { > > be many deployment models, and { > many deployment models { >> { > { > based on a { >> { > { > > particular encoding. The framework is { > that the behaviour { >> of { >> { > the { >> { > { > > interior nodes (in terms of both marking { > behaviour & { >> { > { > encoding) is { >> { > { > > simple and clear, without a whole lot of { > configurable { >> options. { >> { > { > > Meanwhile, there's more freedom in terms of the { > { >> { > { > behaviour of the { >> { > { > > gateways in how they interpret these marks. Of course { > { >> { > { > it may turn { >> { > { > > out that in practice there are only a couple of good sets of { >> { { >> { >> { > { > > gateway behaviour. { >> { > { > > { > Anyway, I read your email as proposing that the marking { >> and { >> { > { > > encoding { > should allow lots of freedom with lots of { >> { > configurable { >> { > { > > options, and that { > the deployment models should be where { >> { > { > things are { >> { > { > > standardised in anger. { >> { > { > > { > I disagree with that. { >> { > { > > { > { >> { > { > > { { >> { > { > > { -- { >> { > { > > { Dr. Michael Menth, Assistant Professor { University of { >> { > Wuerzburg, { >> { > { > > Institute of Computer Science { Am Hubland, D-97074 { >> Wuerzburg, { >> { > { > > Germany, room B206 { phone: (+49)-931/888-6644, fax: { >> { > { > > (+49)-931/888-6632 { { >> { > mailto:menth@informatik.uni-wuerzburg.de { > { >> { > { > > { http://www3.informatik.uni-wuerzburg.de/research/ngn { >> { > { > > { >> { > { > { >> { > { > -- { >> { > { > Dr. Michael Menth, Assistant Professor { >> { > { > University of Wuerzburg, Institute of Computer Science Am { >> { > { > Hubland, D-97074 Wuerzburg, Germany, room B206 { >> { > { > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { >> { > { > mailto:menth@informatik.uni-wuerzburg.de { >> { > { > http://www3.informatik.uni-wuerzburg.de/research/ngn { >> { > { > { >> { > { > _______________________________________________ { >> { > { > PCN mailing list { >> { > { > PCN@ietf.org { >> { > { > https://www.ietf.org/mailman/listinfo/pcn { >> { > { > { >> { > { { >> { > { >> { { >> { -- { >> { Dr. Michael Menth, Assistant Professor { >> { University of Wuerzburg, Institute of Computer Science { >> { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { >> { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { >> { mailto:menth@informatik.uni-wuerzburg.de { >> { http://www3.informatik.uni-wuerzburg.de/research/ngn { >> { >> _______________________________________________ { >> PCN mailing list { >> PCN@ietf.org { >> https://www.ietf.org/mailman/listinfo/pcn { >> { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 27 08:38:39 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B5B3A694C; Mon, 27 Oct 2008 08:38:39 -0700 (PDT) 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 9176A3A6915 for ; Mon, 27 Oct 2008 08:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMx5xAIKOqht for ; Mon, 27 Oct 2008 08:38:36 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id CDD933A67A4 for ; Mon, 27 Oct 2008 08:38:36 -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 1KuUAs-0003HN-Ht for pcn@ietf.org; Mon, 27 Oct 2008 11:38:34 -0400 MIME-Version: 1.0 Date: Mon, 27 Oct 2008 11:38:34 -0400 From: To: pcn@ietf.org Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] IETF 73 PCN agenda requests X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org It's that time again. PCN is currently scheduled for 2.5 hours on Tuesday morning Nov. 18. Please send agenda requests to the chairs. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 27 09:16:58 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C21D3A6B7E; Mon, 27 Oct 2008 09:16:58 -0700 (PDT) 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 11DEE3A6AAB for ; Mon, 27 Oct 2008 09:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS6oVBN3UgKf for ; Mon, 27 Oct 2008 09:16:56 -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 B1E5D3A6A0E for ; Mon, 27 Oct 2008 09:16:53 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 452FAA069A for ; Mon, 27 Oct 2008 17:16:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 370ECA06A9 for ; Mon, 27 Oct 2008 17:16:52 +0100 (CET) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1C777A0694 for ; Mon, 27 Oct 2008 17:16:52 +0100 (CET) Message-ID: <4905E90E.4020902@informatik.uni-wuerzburg.de> Date: Mon, 27 Oct 2008 17:15:10 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: pcn X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] [Fwd: New Version Notification for draft-menth-pcn-psdm-deployment-00] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I've submitted a draft giving examples what the PSDM encoding is good for. http://www.ietf.org/internet-drafts/draft-menth-pcn-psdm-deployment-00.txt Regards, Michael -------- Original Message -------- Subject: New Version Notification for draft-menth-pcn-psdm-deployment-00 Date: Mon, 27 Oct 2008 09:11:27 -0700 (PDT) From: IETF I-D Submission Tool To: menth@informatik.uni-wuerzburg.de A new version of I-D, draft-menth-pcn-psdm-deployment-00.txt has been successfuly submitted by Michael Menth and posted to the IETF repository. Filename: draft-menth-pcn-psdm-deployment Revision: 00 Title: Deployment Models for PCN-Based Admission Control and Flow Termination Using Packet-Specific Dual Marking (PSDM) Creation_date: 2008-10-24 WG ID: Independent Submission Number_of_pages: 20 Abstract: This document presents different deployment models of PCN-based admission control (AC) and flow termination (FT) using packet- specific dual marking (PSDM) for encoding. Their major is that they require only a single DSCP for packet marking and that they work reliably in the presence of ingress-egress aggregates (IEAs) with only a very small average number of flows. Moreover, an advanced model even works with multipath routing. The IETF Secretariat. -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 27 10:00:13 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9678D3A6B9C; Mon, 27 Oct 2008 10:00:13 -0700 (PDT) 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 B02683A6BA7 for ; Mon, 27 Oct 2008 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80ERPSVOReaX for ; Mon, 27 Oct 2008 10:00:11 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id A0CAD3A6BBC for ; Mon, 27 Oct 2008 10:00:11 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 17:00:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 17:00:08 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3FE@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] IETF 73 PCN agenda requests Thread-Index: Ack4ShjR/qv4MsUQSzasbTlDye9E7gACpvJA From: To: , X-OriginalArrivalTime: 27 Oct 2008 17:00:09.0577 (UTC) FILETIME=[7823FD90:01C93855] Subject: Re: [PCN] IETF 73 PCN agenda requests X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steve, will be asking for WG last call on the 2 WG docs, so time please on them: http://tools.ietf.org/wg/pcn/draft-ietf-pcn-baseline-encoding/ [bob] http://tools.ietf.org/wg/pcn/draft-ietf-pcn-marking-behaviour/ [phil] All, so if there are any issues on these docs, please raise them so we can make sure they're discussed at the meeting & as much as possible is sorted out prior to the WGLC. Thanks! phil/ { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { slblake@petri-meat.com { Sent: 27 October 2008 15:39 { To: pcn@ietf.org { Subject: [PCN] IETF 73 PCN agenda requests { { It's that time again. PCN is currently scheduled for 2.5 hours on Tuesday { morning Nov. 18. { Please send agenda requests to the chairs. { { { Regards, { { // Steve { { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 27 10:06:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A85228C10D; Mon, 27 Oct 2008 10:06:20 -0700 (PDT) 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 1EFEB3A6804 for ; Mon, 27 Oct 2008 10:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPLFD0lYibFC for ; Mon, 27 Oct 2008 10:06:18 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 0A2C83A6AC6 for ; Mon, 27 Oct 2008 10:06:17 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 17:06:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 17:05:58 -0000 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3FE@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] IETF 73 PCN agenda requests thread-index: Ack4ShjR/qv4MsUQSzasbTlDye9E7gACpvJAAABWB4A= References: <4A916DBC72536E419A0BD955EDECEDEC03DAA3FE@E03MVB1-UKBR.domain1.systemhost.net> From: To: , , X-OriginalArrivalTime: 27 Oct 2008 17:06:17.0109 (UTC) FILETIME=[5334EC50:01C93856] Subject: Re: [PCN] IETF 73 PCN agenda requests X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Just to remind people there were a couple of questions I raised in the appendices of the baseline encoding. There have been a few responses so far but these will need to be decided before any WGLC can complete. Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 27 October 2008 17:00 > To: slblake@petri-meat.com; pcn@ietf.org > Subject: Re: [PCN] IETF 73 PCN agenda requests > > Steve, > > will be asking for WG last call on the 2 WG docs, so time please on > them: > > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-baseline-encoding/ [bob] > http://tools.ietf.org/wg/pcn/draft-ietf-pcn-marking-behaviour/ [phil] > > All, > so if there are any issues on these docs, please raise them so we can > make sure they're discussed at the meeting & as much as possible is > sorted out prior to the WGLC. > > Thanks! > phil/ > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { slblake@petri-meat.com > { Sent: 27 October 2008 15:39 > { To: pcn@ietf.org > { Subject: [PCN] IETF 73 PCN agenda requests > { > { It's that time again. PCN is currently scheduled for 2.5 hours on > Tuesday > { morning Nov. 18. > { Please send agenda requests to the chairs. > { > { > { Regards, > { > { // Steve > { > { _______________________________________________ > { PCN mailing list > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 27 12:13:36 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23763A6B89; Mon, 27 Oct 2008 12:13:35 -0700 (PDT) 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 D9E313A6975 for ; Mon, 27 Oct 2008 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=1.427, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmQcF-25iwRp for ; Mon, 27 Oct 2008 12:13:28 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id F12503A6A0D for ; Mon, 27 Oct 2008 12:13:27 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 19:13:26 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 19:13:26 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1225134805811; Mon, 27 Oct 2008 19:13:25 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m9RJDOmD013620; Mon, 27 Oct 2008 19:13:24 GMT Message-Id: <200810271913.m9RJDOmD013620@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 19:13:28 +0000 To: "tsvwg IETF list" , "PCN IETF list" From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Oct 2008 19:13:26.0295 (UTC) FILETIME=[168E5270:01C93868] Subject: [PCN] New Version: draft-ietf-tsvwg-ecn-tunnel-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, As of a couple of weeks ago, this became a tsvwg wg item. I posted an -00 then, but I've just posted a corrected -01. I'd appreciate review comments as this is effectively a (minor) change to IP forwarding, so there could be weird dependencies I've not thought of (I've tried my hardest to make sure there aren't). The top level questions I'd like to pose for reviewers are: Q1. I've convinced myself no harm to any existing mechanisms would result if I made the proposed new decapsualtion behaviour in Appendix C normative for standards track. Do you agree? Have I missed anything? Q2. I'm planning on splitting this into two docs as it's trying to cover two different scopes: 1/ Stand's track: define specific changes to IP in IP tunnelling of ECN 2/ Informational: give guidelines on how to design encapsulation of congestion notification by general L2 protocols (e.g. Ethernet etc). As it stands, a reader in a hurry could mistake guidelines for encapsulating IP in ethernet etc as instructions for how to implement standard IP in IP tunnelling. Do people agree I should avoid having two different scopes in the same doc? Cheers Bob >From: IETF I-D Submission Tool >To: >Subject: New Version Notification for draft-ietf-tsvwg-ecn-tunnel-01 >Date: Mon, 27 Oct 2008 11:05:28 -0700 >X-OriginalArrivalTime: 27 Oct 2008 18:05:35.0563 (UTC) >FILETIME=[9C35E9B0:01C9385E] >X-Spam-Score: 0 () >X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 > > >A new version of I-D, draft-ietf-tsvwg-ecn-tunnel-01.txt has been >successfuly submitted by Bob Briscoe and posted to the IETF repository. > >Filename: draft-ietf-tsvwg-ecn-tunnel >Revision: 01 >Title: Layered Encapsulation of Congestion Notification >Creation_date: 2008-10-27 >WG ID: tsvwg >Number_of_pages: 37 > >Abstract: >This document redefines how the explicit congestion notification >(ECN) field of the outer IP header of a tunnel should be constructed. >It brings all IP in IP tunnels (v4 or v6) into line with the way >IPsec tunnels now construct the ECN field. It includes a thorough >analysis of the reasoning for this change and the implications. It >also gives guidelines on the encapsulation of IP congestion >notification by any outer header, whether encapsulated in an IP >tunnel or in a lower layer header. Following these guidelines should >help interworking, if the IETF or other standards bodies specify any >new encapsulation of congestion notification. > > > > >The IETF Secretariat. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 27 12:14:11 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAE63A6A0D; Mon, 27 Oct 2008 12:14:11 -0700 (PDT) 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 09EB43A6975 for ; Mon, 27 Oct 2008 12:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UwKBjlRjB5V for ; Mon, 27 Oct 2008 12:14:02 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 62B703A6A0D for ; Mon, 27 Oct 2008 12:14:02 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 19:13:59 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 19:13:58 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1225134838833; Mon, 27 Oct 2008 19:13:58 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m9RJDuZi013673 for ; Mon, 27 Oct 2008 19:13:56 GMT Message-Id: <200810271913.m9RJDuZi013673@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 17:21:54 +0000 To: "PCN IETF list" From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Oct 2008 19:13:58.0944 (UTC) FILETIME=[2A042A00:01C93868] Subject: [PCN] Initial Draft: draft-briscoe-pcn-3-in-1-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I just posted this new draft-briscoe-pcn-3-in-1-encoding-00.txt documenting another proposed experimental encoding that Toby described in a slide at the Dublin IETF. I just wrote this because draft-ietf-tsvwg-ecn-tunnel-01.txt recenty became a WG item in tswvwg, so there's a chance we could finally fix ECN tunnelling behaviour. If we do, then we can have this much simpler 3-state PCN encoding in one Diffserv codepoint. I've called it the 3-in-1 PCN encoding. It's just to put a stake in the ground so people can refer to it. We won't be pushing for this to become a PCN WG item until the baseline encoding has gone thru, and until draft-ietf-tsvwg-ecn-tunnel-01.txt has got a bit further in TSVWG. Bob >From: IETF I-D Submission Tool >To: >Subject: New Version Notification for > draft-briscoe-pcn-3-in-1-encoding-00 >Date: Mon, 27 Oct 2008 08:46:29 -0700 >X-OriginalArrivalTime: 27 Oct 2008 15:46:37.0589 (UTC) >FILETIME=[32640C50:01C9384B] >X-Spam-Score: 0 () >X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 > > >A new version of I-D, draft-briscoe-pcn-3-in-1-encoding-00.txt has >been successfuly submitted by Bob Briscoe and posted to the IETF repository. > >Filename: draft-briscoe-pcn-3-in-1-encoding >Revision: 00 >Title: PCN 3-State Encoding Extension in a single DSCP >Creation_date: 2008-10-27 >WG ID: Independent Submission >Number_of_pages: 8 > >Abstract: >Pre-congestion notification (PCN) is a mechanism designed to protect >the quality of service of inelastic flows. It does this by marking >packets when traffic load on a link is approaching or has exceeded a >threshold below the physical link rate. This document specifies an >extension to the two-state PCN baseline encoding that enables three >encoding states to be carried in the IP header without using more >than one Diffserv codepoint. It presupposes a standards action has >removed the limit of two encoding states in current tunnelling >mechanisms. > > > > >The IETF Secretariat. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 30 05:26:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026E73A689B; Thu, 30 Oct 2008 05:26:00 -0700 (PDT) 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 37A6F3A67D0 for ; Thu, 30 Oct 2008 04:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 oWPh81ZNqWC4 for ; Thu, 30 Oct 2008 04:14:33 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 363A03A6858 for ; Thu, 30 Oct 2008 04:14:30 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 30 Oct 2008 12:14:27 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 12:14:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 12:14:26 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C01F0026A@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA3AC@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt Thread-Index: AckyuCZI7es/JACQRg6f8fVnLDgrFQAAKbpQAfEFWFA= References: <20081020133001.E29893A6A10@core3.amsl.com> <4A916DBC72536E419A0BD955EDECEDEC03DAA3AC@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 30 Oct 2008 11:14:27.0273 (UTC) FILETIME=[AC00D390:01C93A80] X-Mailman-Approved-At: Thu, 30 Oct 2008 05:25:59 -0700 Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, nice document, I like the separation of functional specification an appendices. Regards, Ruediger Two editorial comments: Para 2. Specified PCN-marking behaviour First Section, sentence "The informative Appendixes supplement it." Please replace the "it" by the term it refers to ("information on PCN-marking behaviour", or something similar, I guess). Para 2.5 Marking function There's an empty bullet point and a "." at the end of the section, both should be deleted. -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Monday, October 20, 2008 3:40 PM To: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt Hi I updated the doc to take account of Michael's comments (thanks!) and a few things I spotted. Changes are clarifications etc - no changes in the MUSTs etc My intent at the Minneapolis meeting is to ask for WG last call. So any comments before then appreciated. Thanks Phil http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01 { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Internet-Drafts@ietf.org { Sent: 20 October 2008 14:30 { To: i-d-announce@ietf.org { Cc: pcn@ietf.org { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.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-01.txt { Pages : 19 { Date : 2008-10-20 { { 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 its { configured rate. Excess traffic marking marks a proportion of PCN- { packets, such that the amount marked equals the traffic rate in { excess of its configured 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- { 01.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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 30 08:32:12 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403AF3A6A8D; Thu, 30 Oct 2008 08:32:12 -0700 (PDT) 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 BB6383A6A79 for ; Thu, 30 Oct 2008 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 jVlm9J9YAa+n for ; Thu, 30 Oct 2008 08:32:09 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 790EA3A6816 for ; Thu, 30 Oct 2008 08:32:09 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 15:32:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 15:32:04 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA418@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA412@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt Thread-Index: AckyuCZI7es/JACQRg6f8fVnLDgrFQAAKbpQAfEFWFAAAWhqsAAIgPWw From: To: X-OriginalArrivalTime: 30 Oct 2008 15:32:04.0236 (UTC) FILETIME=[A91234C0:01C93AA4] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Re-sending (sorry if duplicate, but something seems wrong with my email) { -----Original Message----- { From: Eardley,PL,Philip,CXR9 R { Sent: 30 October 2008 11:28 { To: 'Geib, Ruediger' { Cc: pcn@ietf.org { Subject: RE: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt { { Ruediger { { Thanks for the feedback! I'll update with your 2 editorials in the next { version { { phil { { { -----Original Message----- { { From: Geib, Ruediger [mailto:Ruediger.Geib@telekom.de] { { Sent: 30 October 2008 11:14 { { To: Eardley,PL,Philip,CXR9 R { { Cc: pcn@ietf.org { { Subject: RE: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt { { { { Hi Phil, { { { { nice document, I like the separation of functional specification an { { appendices. { { { { Regards, { { { { Ruediger { { { { { { Two editorial comments: { { { { Para 2. Specified PCN-marking behaviour { { First Section, sentence "The informative Appendixes supplement it." { { { { Please replace the "it" by the term it refers to ("information on PCN- { { marking behaviour", { { or something similar, I guess). { { { { Para 2.5 Marking function { { { { There's an empty bullet point and a "." at the end of the section, both { { should be deleted. { { { { { { -----Original Message----- { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { { philip.eardley@bt.com { { Sent: Monday, October 20, 2008 3:40 PM { { To: pcn@ietf.org { { Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt { { { { Hi { { I updated the doc to take account of Michael's comments (thanks!) and a { { few things I spotted. Changes are clarifications etc - no changes in the { { MUSTs etc { { { { My intent at the Minneapolis meeting is to ask for WG last call. So any { { comments before then appreciated. { { { { Thanks { { Phil { { { { http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01 { { { { { -----Original Message----- { { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { { { Internet-Drafts@ietf.org { { { Sent: 20 October 2008 14:30 { { { To: i-d-announce@ietf.org { { { Cc: pcn@ietf.org { { { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.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-01.txt { { { Pages : 19 { { { Date : 2008-10-20 { { { { { { 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 its { { { configured rate. Excess traffic marking marks a proportion of PCN- { { { packets, such that the amount marked equals the traffic rate in { { { excess of its configured 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- { { { 01.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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 31 00:36:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D2A3A6A39; Fri, 31 Oct 2008 00:36:00 -0700 (PDT) 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 626123A6A0F for ; Fri, 31 Oct 2008 00:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 swu8PK5NIT-C for ; Fri, 31 Oct 2008 00:35:57 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 2B2D43A67D4 for ; Fri, 31 Oct 2008 00:35:57 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Fri, 31 Oct 2008 08:35:54 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 08:35:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 08:35:53 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C01F56602@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA418@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt Thread-Index: AckyuCZI7es/JACQRg6f8fVnLDgrFQAAKbpQAfEFWFAAAWhqsAAIgPWwACGVVrA= References: <4A916DBC72536E419A0BD955EDECEDEC03DAA412@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC03DAA418@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 31 Oct 2008 07:35:54.0598 (UTC) FILETIME=[4EA72860:01C93B2B] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, my email address has changed, Ruediger.Geib is at telekom.de by now. Those = PCN participants having auto completion of email addresses running may have= to delete my older address. Regards, Ruediger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] = Sent: Thursday, October 30, 2008 4:32 PM To: Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt Re-sending (sorry if duplicate, but something seems wrong with my email) { -----Original Message----- { From: Eardley,PL,Philip,CXR9 R { Sent: 30 October 2008 11:28 { To: 'Geib, Ruediger' { Cc: pcn@ietf.org { Subject: RE: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt { = { Ruediger { = { Thanks for the feedback! I'll update with your 2 editorials in the next { version { = { phil { = { { -----Original Message----- { { From: Geib, Ruediger [mailto:Ruediger.Geib@telekom.de] { { Sent: 30 October 2008 11:14 { { To: Eardley,PL,Philip,CXR9 R { { Cc: pcn@ietf.org { { Subject: RE: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt { { { { Hi Phil, { { { { nice document, I like the separation of functional specification an { { appendices. { { { { Regards, { { { { Ruediger { { { { { { Two editorial comments: { { { { Para 2. Specified PCN-marking behaviour { { First Section, sentence "The informative Appendixes supplement it." { { { { Please replace the "it" by the term it refers to ("information on PCN- { { marking behaviour", { { or something similar, I guess). { { { { Para 2.5 Marking function { { { { There's an empty bullet point and a "." at the end of the section, both { { should be deleted. { { { { { { -----Original Message----- { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { { philip.eardley@bt.com { { Sent: Monday, October 20, 2008 3:40 PM { { To: pcn@ietf.org { { Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.txt { { { { Hi { { I updated the doc to take account of Michael's comments (thanks!) and a { { few things I spotted. Changes are clarifications etc - no changes in the { { MUSTs etc { { { { My intent at the Minneapolis meeting is to ask for WG last call. So any { { comments before then appreciated. { { { { Thanks { { Phil { { { { http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01 { { { { { -----Original Message----- { { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { { { Internet-Drafts@ietf.org { { { Sent: 20 October 2008 14:30 { { { To: i-d-announce@ietf.org { { { Cc: pcn@ietf.org { { { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-01.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-01.txt { { { Pages : 19 { { { Date : 2008-10-20 { { { { { { 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 its { { { configured rate. Excess traffic marking marks a proportion of PCN- { { { packets, such that the amount marked equals the traffic rate in { { { excess of its configured 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- { { { 01.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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn