From pcn-bounces@ietf.org Tue Jan 6 11:01:22 2009 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 96D3F28C165; Tue, 6 Jan 2009 11:01:22 -0800 (PST) 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 D945928C165 for ; Tue, 6 Jan 2009 11:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 CsO-Nx3Tyt1n for ; Tue, 6 Jan 2009 11:01:21 -0800 (PST) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id E74F13A67EA for ; Tue, 6 Jan 2009 11:00:51 -0800 (PST) Received: (qmail 90327 invoked from network); 6 Jan 2009 19:00:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=JOGqWx6INgba0vvCYS5fkdfsaDbEOzE1eWsLaZvDy+2Wzv3sxAOgULWzEERpQTVExwpGG9tp7xeKBKH5GqN0xUenIegpnr7YJSIihbY3gxY/eZFBCQH4R/b6JkoMo/WHKs+yTme1MWKUuGTd+YIS2sp872+ggZyi1uvSC1PyLf4= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 6 Jan 2009 19:00:38 -0000 X-YMail-OSG: 5GKiXFwVM1k23ULyBvq7yBO1tbGzifN6jEld4mxjtCJBavsQk85d2xTN13kj9JyLaQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4963AA54.2050300@rogers.com> Date: Tue, 06 Jan 2009 14:00:36 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: pcn Subject: [PCN] [Fwd: Posting of IPR Disclosure] (re draft-tsou-pcn-racf-applic-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 The formalities having been completed, here is an informal notice. -------- Original Message -------- Subject: Posting of IPR Disclosure Date: Tue, 6 Jan 2009 10:08:59 -0800 (PST) From: IETF Secretariat To: tom.taylor@rogers.com,tena@huawei.com,fqhuang@huawei.com CC: housley@vigilsec.com Dear Tom Taylor, Tina Tsou, Fortune Huang: An IPR disclosure that pertains to your Internet-Draft entitled "Applicability Statement for the Use of Pre-Congestion Notification in a Resource-Controlled Network" (draft-tsou-pcn-racf-applic) was submitted to the IETF Secretariat on 2009-01-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to draft-bernstein-ccamp-wson-signaling-03, draft-ietf-pce-global-concurrent-optimization-05, and draft-tsou-pcn-racf-applic-01." The IETF Secretariat _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 14 03:15:02 2009 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 6B2EF3A6923; Wed, 14 Jan 2009 03:15:02 -0800 (PST) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9649A3A6923; Wed, 14 Jan 2009 03:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090114111501.9649A3A6923@core3.amsl.com> Date: Wed, 14 Jan 2009 03:15:01 -0800 (PST) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-09.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-09.txt Pages : 55 Date : 2009-01-14 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-14030524.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 Wed Jan 14 03:32:56 2009 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 132623A687E; Wed, 14 Jan 2009 03:32:56 -0800 (PST) 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 E3DA23A6834 for ; Wed, 14 Jan 2009 03:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.716, 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 SPMOtruMpBQ6 for ; Wed, 14 Jan 2009 03:32:54 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D42523A6827 for ; Wed, 14 Jan 2009 03:32:53 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jan 2009 11:32:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 11:32:37 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD779A@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20090114111501.9649A3A6923@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-architecture-09.txt Thread-Index: Acl2OVPkk7GdPTjeTo+14a5mCVIungAAjbQw From: To: X-OriginalArrivalTime: 14 Jan 2009 11:32:38.0273 (UTC) FILETIME=[CDAF3710:01C9763B] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-architecture-09.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 I uploaded a new version of the architecture draft to deal with some comments that Scott sent me - to make sure that it will pass ietf process scrutiny. I also managed to battle through the new ietf boilerplague Scott, hope this deals with your comments Lars, hope this version is now OK for IETF last call? Thanks Phil http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-09.txt *** Small changes to deal with WG Chair comments: o tweak language in various places to make it more RFC-like and less that of a scholarly work, for instance from "we propose" to "this document describes" o tweak language in various places to make it a stand alone architecture document rather than a discussion of the PCN WG. Now only mentions WG at start of Annex. o References: IDs are no longer referenced to by the draft name o References: removed some of less important references to IDs { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Internet-Drafts@ietf.org { Sent: 14 January 2009 11:15 { To: i-d-announce@ietf.org { Cc: pcn@ietf.org { Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-09.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-09.txt { Pages : 55 { Date : 2009-01-14 { { 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. { { A URL for this Internet-Draft is: { http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-09.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 Fri Jan 16 00:43:32 2009 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 356B73A6985; Fri, 16 Jan 2009 00:43:32 -0800 (PST) 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 262693A6985 for ; Fri, 16 Jan 2009 00:43:31 -0800 (PST) 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 tZsVE1vwGJ-z for ; Fri, 16 Jan 2009 00:43:30 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C81003A683E for ; Fri, 16 Jan 2009 00:43:29 -0800 (PST) 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 n0G8h91i011229; Fri, 16 Jan 2009 09:43:10 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 16 Jan 2009 08:43:08 +0000 To: "philip.eardley@bt.com" , "pcn@ietf.org" Date: Fri, 16 Jan 2009 08:43:08 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <7myNFgt4.1232095388.4371510.karagian@ewi.utwente.nl> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA594@E03MVB1-UKBR.domain1.systemhost.net> 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]); Fri, 16 Jan 2009 09:43:11 +0100 (MET) Subject: Re: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour (including preferential dropping) 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 agree with the proposed changes! Best regards, Georgios On 12/9/2008, "philip.eardley@bt.com" wrote: >We agreed in Minneapolis, & on the list, to keep the preferential >dropping behaviour as a SHOULD, but add some brief explanation in the >Appendix about why this isn't a MUST, >http://www.ietf.org/mail-archive/web/pcn/current/msg01876.html. I've >drafted some text below. >Also, it made me think that we should similarly have some brief >explanation about our 3 other SHOULDs or SHOULD NOTs. This is also >below. >The proposals only affect the informative appendix - normative text is >unaltered. > >Comments please >Thanks >phil > >=== Preferential dropping == >S2.2 says: >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; > > > >Informative explanation in Appendix B4: > >[existing text] > > Preferential dropping of excess-traffic-marked packets: Section 2.3 >2.3> > specifies: "If the PCN-node drops PCN-packets then ... PCN-packets > that arrive at the PCN-node already excess-traffic-marked SHOULD be > preferentially dropped". Exactly what "preferentially dropped" means >is left to the > implementation. It is also left to the implementation what to do if > there are no excess-traffic-marked PCN-packets available at a > particular instant. > >[proposed new text] >The optimal dropping behaviour depends on the particular edge behaviour >[ref-Menth08]. A single dropping behaviour is defined, as it is simpler >to standardise, implement and operate. The standardised dropping >behaviour is at least adequate for all edge behaviours (and good for >some), whereas others are not (for example with tail dropping far too >much traffic may be terminated with the CL/SM edge behaviour, in the >event of multiple bottlenecks in the PCN-domain >[I-D.charny-pcn-comparison >charny-pcn-comparison> ]). The dropping behaviour is defined as a >'SHOULD', rather than a 'MUST', in recognition that other dropping >behaviour may be preferred in particular circumstances, for example: (1) >with the marked flow termination edge behaviour, preferential dropping >of unmarked packets may be better; (2) tail dropping may make PCN >marking behaviour easier to implement on current routers. > > >== Packets not metered == >A PCN-packet SHOULD NOT be metered (by this excess traffic meter > function) in the following two cases: > > o If the packet is already excess-traffic-marked on arrival at the > PCN-node; > > o If this PCN-node drops the packet. > > >Informative explanation in Appendix B6: > >[existing text] > > Section 2.4 >2.4> specifies: "A packet SHOULD NOT be metered (by this > excess traffic meter function) ... If the packet is already excess- > traffic-marked on arrival at the PCN-node". This avoids over- > termination (with some edge behaviours) in the event that the PCN- > traffic passes through multiple bottlenecks in the PCN-domain > [I-D.charny-pcn-comparison >charny-pcn-comparison> ]. Note that an implementation could > determine whether the packet is already excess-traffic-marked as an > integral part of its Classification function. > > > >[proposed new text] > >The behaviour is defined as a 'SHOULD NOT', rather than a 'MUST NOT', >because it may be slightly harder to implement than a metering function >that is blind to previous packet markings. > > > >[existing text] > > Section 2.4 >2.4> specifies: "A packet SHOULD NOT be metered (by this > excess traffic meter function) ... If this PCN-node drops the > packet." This avoids over-termination [Menth >h> ]. (A similar statement > could also be made for the threshold meter function, but is > irrelevant, as a link that is overloaded will already be > substantially pre-congested and hence PCN-marking all packets.) > >[proposed new text] >It seems natural to do traffic conditioning before the metering >functions, although for some equipment it may be harder to implement; >hence the behaviour is defined as a 'SHOULD NOT', rather than a 'MUST >NOT'. > > >== Packet size independent marking == > 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 ("packet size independent marking"). > > >Informative explanation in Appendix B6: > >[existing text] > > Packet size independent marking is specified as a SHOULD in Section > 2.4 ( "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".) Without it, large packets are more likely to be > excess-traffic-marked than small packets and this means that, with > some edge behaviours, flows with large packets are more likely to be > terminated than flows with small packets > [I-D.briscoe-tsvwg-byte-pkt-mark >briscoe-tsvwg-byte-pkt-mark> ] [Menth >h> ]. > >[proposed new text] >The behaviour is a 'SHOULD', rather than a 'MUST', because packet size >independent marking may be slightly harder for some equipment to >implement, and the impact of not doing it is moderate (sufficient >traffic is terminated, but flows with large packets are more likely to >be terminated). > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 16 00:50:26 2009 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 B1E103A69CE; Fri, 16 Jan 2009 00:50:26 -0800 (PST) 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 2A52B3A69CE for ; Fri, 16 Jan 2009 00:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.368, 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 QetnOAF126qd for ; Fri, 16 Jan 2009 00:50:23 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 2C1733A69C6 for ; Fri, 16 Jan 2009 00:50:23 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 08:50:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jan 2009 08:50:06 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD77C9@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <7myNFgt4.1232095388.4371510.karagian@ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour (including preferential dropping) Thread-Index: Acl3tnvFqsv3I1y8RV2mfsnMP3XWDAAAGICQ From: To: , X-OriginalArrivalTime: 16 Jan 2009 08:50:06.0910 (UTC) FILETIME=[6E3ECDE0:01C977B7] Subject: Re: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour (including preferential dropping) 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 Great - thanks! I think basically this marking draft [& the baseline encoding] is ready for WG last call - but I think we have to wait for the architecture to go through IETF last call?(am hoping the 09 version I sent earlier this week will be OK for that) best wishes phil { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 16 January 2009 08:43 { To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org { Subject: Re: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking- { behaviour (including preferential dropping) { { Hi Phil { { I agree with the proposed changes! { { Best regards, { Georgios { { { On 12/9/2008, "philip.eardley@bt.com" wrote: { { >We agreed in Minneapolis, & on the list, to keep the preferential { >dropping behaviour as a SHOULD, but add some brief explanation in the { >Appendix about why this isn't a MUST, { >http://www.ietf.org/mail-archive/web/pcn/current/msg01876.html. I've { >drafted some text below. { >Also, it made me think that we should similarly have some brief { >explanation about our 3 other SHOULDs or SHOULD NOTs. This is also { >below. { >The proposals only affect the informative appendix - normative text is { >unaltered. { > { >Comments please { >Thanks { >phil { > { >=== Preferential dropping == { >S2.2 says: { >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; { > { > { > { >Informative explanation in Appendix B4: { > { >[existing text] { > { > Preferential dropping of excess-traffic-marked packets: Section 2.3 { >2.3> { > specifies: "If the PCN-node drops PCN-packets then ... PCN-packets { > that arrive at the PCN-node already excess-traffic-marked SHOULD be { > preferentially dropped". Exactly what "preferentially dropped" means { >is left to the { > implementation. It is also left to the implementation what to do if { > there are no excess-traffic-marked PCN-packets available at a { > particular instant. { > { >[proposed new text] { >The optimal dropping behaviour depends on the particular edge behaviour { >[ref-Menth08]. A single dropping behaviour is defined, as it is simpler { >to standardise, implement and operate. The standardised dropping { >behaviour is at least adequate for all edge behaviours (and good for { >some), whereas others are not (for example with tail dropping far too { >much traffic may be terminated with the CL/SM edge behaviour, in the { >event of multiple bottlenecks in the PCN-domain { >[I-D.charny-pcn-comparison { >charny-pcn-comparison> ]). The dropping behaviour is defined as a { >'SHOULD', rather than a 'MUST', in recognition that other dropping { >behaviour may be preferred in particular circumstances, for example: (1) { >with the marked flow termination edge behaviour, preferential dropping { >of unmarked packets may be better; (2) tail dropping may make PCN { >marking behaviour easier to implement on current routers. { > { > { >== Packets not metered == { >A PCN-packet SHOULD NOT be metered (by this excess traffic meter { > function) in the following two cases: { > { > o If the packet is already excess-traffic-marked on arrival at the { > PCN-node; { > { > o If this PCN-node drops the packet. { > { > { >Informative explanation in Appendix B6: { > { >[existing text] { > { > Section 2.4 { >2.4> specifies: "A packet SHOULD NOT be metered (by this { > excess traffic meter function) ... If the packet is already excess- { > traffic-marked on arrival at the PCN-node". This avoids over- { > termination (with some edge behaviours) in the event that the PCN- { > traffic passes through multiple bottlenecks in the PCN-domain { > [I-D.charny-pcn-comparison { >charny-pcn-comparison> ]. Note that an implementation could { > determine whether the packet is already excess-traffic-marked as an { > integral part of its Classification function. { > { > { > { >[proposed new text] { > { >The behaviour is defined as a 'SHOULD NOT', rather than a 'MUST NOT', { >because it may be slightly harder to implement than a metering function { >that is blind to previous packet markings. { > { > { > { >[existing text] { > { > Section 2.4 { >2.4> specifies: "A packet SHOULD NOT be metered (by this { > excess traffic meter function) ... If this PCN-node drops the { > packet." This avoids over-termination [Menth { >h> ]. (A similar statement { > could also be made for the threshold meter function, but is { > irrelevant, as a link that is overloaded will already be { > substantially pre-congested and hence PCN-marking all packets.) { > { >[proposed new text] { >It seems natural to do traffic conditioning before the metering { >functions, although for some equipment it may be harder to implement; { >hence the behaviour is defined as a 'SHOULD NOT', rather than a 'MUST { >NOT'. { > { > { >== Packet size independent marking == { > 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 ("packet size independent marking"). { > { > { >Informative explanation in Appendix B6: { > { >[existing text] { > { > Packet size independent marking is specified as a SHOULD in Section { > 2.4 ( "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".) Without it, large packets are more likely to be { > excess-traffic-marked than small packets and this means that, with { > some edge behaviours, flows with large packets are more likely to be { > terminated than flows with small packets { > [I-D.briscoe-tsvwg-byte-pkt-mark { >briscoe-tsvwg-byte-pkt-mark> ] [Menth { >h> ]. { > { >[proposed new text] { >The behaviour is a 'SHOULD', rather than a 'MUST', because packet size { >independent marking may be slightly harder for some equipment to { >implement, and the impact of not doing it is moderate (sufficient { >traffic is terminated, but flows with large packets are more likely to { >be terminated). { > { > { > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 16 00:55:56 2009 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 5FE313A69B4; Fri, 16 Jan 2009 00:55:56 -0800 (PST) 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 9DD4A3A6808 for ; Fri, 16 Jan 2009 00:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_51=0.6, 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 Ne2DrvORpIhi for ; Fri, 16 Jan 2009 00:55:54 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 72D693A69B4 for ; Fri, 16 Jan 2009 00:55:54 -0800 (PST) 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 n0G8tbcw015806; Fri, 16 Jan 2009 09:55:37 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 16 Jan 2009 08:55:36 +0000 To: "philip.eardley@bt.com" , "pcn@ietf.org" Date: Fri, 16 Jan 2009 08:55:35 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA5A7@E03MVB1-UKBR.domain1.systemhost.net> 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]); Fri, 16 Jan 2009 09:55:37 +0100 (MET) Subject: Re: [PCN] FW: PCN - co-authors regarding edge node monitoring functionssearched 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 for the comments! I will have to discuss them with the co-authors of the LC-PCN draft! Best regards, Georgios On 12/10/2008, "philip.eardley@bt.com" wrote: >Great! > >One thing that's probably worth getting some discussion on the list >before you write too much, is what exactly you will include. >Eg LC-PCN includes lots of options, would the draft cover just the main >one or several? (personally I favour the former or something at this end >of the spectrum. Across the set of edge behaviour drafts, I think our >objective should be to give a few, good, likely examples of pcn usage, >rather than to exhaustively cover all possibilities >Eg clearly the assumed PCN-node behaviour needs to be what's in the >marking draft, with guidance where that doc allows flexibility. >Eg does it use baseline encoding or experimental extension? (in which >case I guess a draft to describe that is needed, or at least a table >with the encoding) > >phil > >{ -----Original Message----- >{ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >{ Sent: 10 December 2008 09:59 >{ To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org >{ Subject: RE: [PCN] FW: PCN - co-authors regarding edge node monitoring >{ functionssearched >{ >{ Hi Phil >{ >{ I am willing to get the lead on writing the LC-PCN edge behaviour! >{ >{ Best regards, >{ Georgios >{ >{ >{ > -----Original Message----- >{ > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >{ > Behalf Of philip.eardley@bt.com >{ > Sent: dinsdag 9 december 2008 12:21 >{ > To: pcn@ietf.org >{ > Subject: [PCN] FW: PCN - co-authors regarding edge node >{ > monitoring functionssearched >{ > >{ > Ruediger >{ > Good question, hope you don't mind me sending the answer to the >list. >{ > >{ > We had a corridor meeting about this in Minneapolis. There >{ > were several people willing to help with reviews etc, >{ > although I'm sure the leaders would welcome more! >{ > - Tom volunteered to edit a CL-style edge behaviour draft >{ > - Anna volunteered to edit an SM-style edge behaviour draft >{ > >{ > Both trying for (off-list?) outline drafts in Jan, so that a >{ > reasonable I-D is in place before the next IETF draft >{ > deadline - expect they will be closely based on existing documents. >{ > >{ > Aiming to have a common structure something like: >{ > - intro >{ > - ingress behaviour >{ > - egress behaviour >{ > - info transported between the two >{ > - assumed core behaviour >{ > >{ > it would be great if anyone wanted to write draft(s) for >{ > other edge behaviour(s). >{ > >{ > best wishes, >{ > phil >{ > >{ > -----Original Message----- >{ > From: Geib, Ruediger [mailto:Ruediger.Geib@telekom.de] >{ > Sent: 09 December 2008 10:44 >{ > To: Eardley,PL,Philip,CXR9 R >{ > Subject: PCN - co-authors regarding edge node monitoring >{ > functions searched >{ > >{ > Hi Phil, >{ > >{ > if I recall right, someone (maybe you) mentioned, that >{ > authors drafting an edge node monitoring document are >{ > searched. Are you the one organising this effort or are you >{ > at least involved in the activity? I'd be willing to >{ > contribute my thoughts to start a discussion. If there#s >{ > already a group of authors active, I'm happy to wait for >{ > their results. >{ > >{ > Regards, >{ > >{ > Ruediger >{ > _______________________________________________ >{ > 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 Jan 20 22:29:05 2009 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 352EA3A6893; Tue, 20 Jan 2009 22:29:05 -0800 (PST) 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 600A63A6893 for ; Tue, 20 Jan 2009 22:29:04 -0800 (PST) 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=2.534, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=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 BTVjWHyPnOLc for ; Tue, 20 Jan 2009 22:29:03 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id E90343A6800 for ; Tue, 20 Jan 2009 22:29:02 -0800 (PST) Received: (qmail 54362 invoked by alias); 21 Jan 2009 06:28:46 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 21 Jan 2009 06:28:46 -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 n0L6Sjj1008572 for ; Wed, 21 Jan 2009 15:28:45 +0900 Received: from gwall1.bb.ntt-at.co.jp (gwall1.bb.ntt-at.co.jp [192.168.5.201]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n0L6Skln008809 for ; Wed, 21 Jan 2009 15:28:46 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id n0L6SjIK021438 for pcn@ietf.org; Wed, 21 Jan 2009 15:28:45 +0900 Received: from mercury.tec.ntt-at.co.jp [192.168.22.39] by gwall1.bb.ntt-at.co.jp with ESMTP id RAA21437; Wed, 21 Jan 2009 15:28:45 +0900 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 CF4BB53F61; Wed, 21 Jan 2009 15:28:45 +0900 (JST) Date: Wed, 21 Jan 2009 15:27:55 +0900 From: SATOH Daisuke To: pcn@ietf.org In-Reply-To: <20090121150833.A4CD.26AD349@ntt-at.co.jp> References: <20090121150833.A4CD.26AD349@ntt-at.co.jp> Message-Id: <20090121152515.A4D5.26AD349@ntt-at.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] Cc: daisuke.satoh@ntt-at.co.jp Subject: Re: [PCN] Please modify the marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, If you received this e-mail again, I'm sorry. I would like you to modify draft-ietf-pcn-marking-behaviour-01. I made an example of modification as follows. I understand I have to show you the performance of our algorithm. So I have to update draft-satoh-pcn-st-marking-00. We have simulated our algorithm in extreme cases for both admission and termination. Now we are simulating it. Please wait for performance evaluation awhile. --- 2.3. Threshold meter function 2.3.1 Threshold meter function with One threshold A PCN-node MUST implement a Threshold Meter that has behaviour functionally equivalent to the following. The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBthreshold.fill=0. The token bucket has a configured intermediate depth, termed TBthreshold.threshold. If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not. 2.3.2 Threshold meter function with two threshold A PCN-node MUST implement a Threshold Meter that has behaviour functionally equivalent to the following. The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBthreshold.fill=0. The token bucket has two configured intermediate depths, termed TBthreshold.shallow.threshold and TBthreshold.threshold, where TBthreshold.shallow.threshold is greater than TBthreshold.threshold. If (TBthreshold.fill < TBthreshold.shallow.threshold) and (TBthreshold.fill >= TBthreshold.threshold), then the meter indicates to the Marking function that one-N-th packets are threshold-marked. If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not. 2.5 Combination of the meter functions A PCN-node MAY implement combination of Threshold and Excess traffic meters. The meter is composed of two tandem meters of Threshold and Excess traffic meters or two Threshold meters or two Excess traffic meters. The former meter is used for marking switch and the latter meter is used for marking. The combined meter has behaviour functionally equivalent to the following. If TBthreshold.fill >= TBthreshold.threshold (when the former meter is the Threshold meter) or if the token bucket is not empty (the former meter is the Excess traffic meter), the combined meter indicates to the Marking function that the packet is not to be marked even if the latter meter indicates to the Marking function that the packet is to be marked. Otherwise, the combined meter indicates the same result as the latter meter's indication to the Marking function. A.3 Combined metering and marking The combined meter by using two Threshold meters is introduced. The two combined token buckets with the following parameters: o TBthreshold.PCN-threshold-rate.former: token rate of the former token bucket (bits/second) o TBthreshold.PCN-threshold-rate.latter: token rate of the latter token bucket (bits/second) o TBthreshold.max.former: depth of the former token bucket (bits) o TBthreshold.max.latter: depth of the latter token bucket (bits) o TBthreshold.threshold.former: marking threshold of the former token bucket (bits) o TBthreshold.shallow.threshold.latter: One-Nth marking threshold of the latter token bucket (bits) o TBthreshold.threshold.latter: marking threshold of the latter token bucket (bits) o TBthreshold.lastUpdate: time both token buckets were last updated (seconds) o TBthreshold.fill.former: amount of tokens in the former token bucket (bits) o TBthreshold.fill.latter: amount of tokens in the latter token bucket (bits) A PCN-packet has the following parameters: o packet.size: the size of the PCN-packet (bits) o packet.mark: the PCN encoding state of the packet In addition there is the parameter: o now: the current time (seconds) The following steps are performed when a PCN-packet arrives on a link: o TBthreshold.fill.former = min(TBthreshold.max.former, TBthreshold.fill.former + TBthreshold.PCN-threshold-rate.former*(now - TBthreshold.lastUpdate)); // add tokens to the former token bucket o TBthreshold.fill.latter = min(TBthreshold.max.latter, TBthreshold.fill.latter + TBthreshold.PCN-threshold-rate.latter*(now - TBthreshold.lastUpdate));// add tokens to the latter token bucket o TBthreshold.fill.former = max(0, TBthreshold.fill.former - packet.size); //remove tokens from the former token bucket o TBthreshold.fill.latter = max(0, TBthreshold.fill.latter - packet.size); //remove tokens from the latter token bucket o if (TBthreshold.fill.former < TBthreshold.threshold.former) then if (TBthreshold.fill.latter < TBthreshold.shallow.threshold.latter) then if (TBthreshold.fill.latter >= TBthreshold.threshold.latter) then one-Nth packets are threshold-marked else packet.mark = threshold-marked; //do threshold marking with two thresholds only when TBthreshold.fill.former <= TBthreshold.threshold.former o TBthreshold.lastUpdate = now --- Best regards, Daisuke _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 20 22:49:34 2009 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 D84E03A6800; Tue, 20 Jan 2009 22:49:34 -0800 (PST) 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 8A62E3A6800 for ; Tue, 20 Jan 2009 22:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.537 X-Spam-Level: ** X-Spam-Status: No, score=2.537 tagged_above=-999 required=5 tests=[AWL=2.027, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=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 2YWFGwb6vpNv for ; Tue, 20 Jan 2009 22:49:32 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id DC9E03A67CC for ; Tue, 20 Jan 2009 22:49:31 -0800 (PST) Received: (qmail 56334 invoked by alias); 21 Jan 2009 06:49:15 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 21 Jan 2009 06:49: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 n0L6nEj1011001 for ; Wed, 21 Jan 2009 15:49:14 +0900 Received: from gwall2.bb.ntt-at.co.jp (gwall2.bb.ntt-at.co.jp [192.168.5.202]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n0L6nEDc011293 for ; Wed, 21 Jan 2009 15:49:14 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: (from root@localhost) by gwall2.bb.ntt-at.co.jp (8.13.1/8.13.1) id n0L6nENY023207 for pcn@ietf.org; Wed, 21 Jan 2009 15:49:14 +0900 Received: from mercury.tec.ntt-at.co.jp [192.168.22.39] by gwall2.bb.ntt-at.co.jp with ESMTP id RAA23206; Wed, 21 Jan 2009 15:49:14 +0900 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 8C61253F61; Wed, 21 Jan 2009 15:49:14 +0900 (JST) Date: Wed, 21 Jan 2009 15:48:24 +0900 From: SATOH Daisuke To: pcn@ietf.org Message-Id: <20090121154735.A4DA.26AD349@ntt-at.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] Cc: daisuke.satoh@ntt-at.co.jp Subject: [PCN] Please modify the marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, If you received this e-mail again, I'm sorry. I would like you to modify draft-ietf-pcn-marking-behaviour-01. I made an example of modification as follows. I understand I have to show you the performance of our algorithm. So I have to update draft-satoh-pcn-st-marking-00. We have simulated our algorithm in extreme cases for both admission and termination. Now we are simulating it. Please wait for performance evaluation awhile. --- 2.3. Threshold meter function 2.3.1 Threshold meter function with One threshold A PCN-node MUST implement a Threshold Meter that has behaviour functionally equivalent to the following. The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBthreshold.fill=0. The token bucket has a configured intermediate depth, termed TBthreshold.threshold. If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not. 2.3.2 Threshold meter function with two threshold A PCN-node MUST implement a Threshold Meter that has behaviour functionally equivalent to the following. The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBthreshold.fill=0. The token bucket has two configured intermediate depths, termed TBthreshold.shallow.threshold and TBthreshold.threshold, where TBthreshold.shallow.threshold is greater than TBthreshold.threshold. If (TBthreshold.fill < TBthreshold.shallow.threshold) and (TBthreshold.fill >= TBthreshold.threshold), then the meter indicates to the Marking function that one-N-th packets are threshold-marked. If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not. 2.5 Combination of the meter functions A PCN-node MAY implement combination of Threshold and Excess traffic meters. The meter is composed of two tandem meters of Threshold and Excess traffic meters or two Threshold meters or two Excess traffic meters. The former meter is used for marking switch and the latter meter is used for marking. The combined meter has behaviour functionally equivalent to the following. If TBthreshold.fill >= TBthreshold.threshold (when the former meter is the Threshold meter) or if the token bucket is not empty (the former meter is the Excess traffic meter), the combined meter indicates to the Marking function that the packet is not to be marked even if the latter meter indicates to the Marking function that the packet is to be marked. Otherwise, the combined meter indicates the same result as the latter meter's indication to the Marking function. A.3 Combined metering and marking The combined meter by using two Threshold meters is introduced. The two combined token buckets with the following parameters: o TBthreshold.PCN-threshold-rate.former: token rate of the former token bucket (bits/second) o TBthreshold.PCN-threshold-rate.latter: token rate of the latter token bucket (bits/second) o TBthreshold.max.former: depth of the former token bucket (bits) o TBthreshold.max.latter: depth of the latter token bucket (bits) o TBthreshold.threshold.former: marking threshold of the former token bucket (bits) o TBthreshold.shallow.threshold.latter: One-Nth marking threshold of the latter token bucket (bits) o TBthreshold.threshold.latter: marking threshold of the latter token bucket (bits) o TBthreshold.lastUpdate: time both token buckets were last updated (seconds) o TBthreshold.fill.former: amount of tokens in the former token bucket (bits) o TBthreshold.fill.latter: amount of tokens in the latter token bucket (bits) A PCN-packet has the following parameters: o packet.size: the size of the PCN-packet (bits) o packet.mark: the PCN encoding state of the packet In addition there is the parameter: o now: the current time (seconds) The following steps are performed when a PCN-packet arrives on a link: o TBthreshold.fill.former = min(TBthreshold.max.former, TBthreshold.fill.former + TBthreshold.PCN-threshold-rate.former*(now - TBthreshold.lastUpdate)); // add tokens to the former token bucket o TBthreshold.fill.latter = min(TBthreshold.max.latter, TBthreshold.fill.latter + TBthreshold.PCN-threshold-rate.latter*(now - TBthreshold.lastUpdate));// add tokens to the latter token bucket o TBthreshold.fill.former = max(0, TBthreshold.fill.former - packet.size); //remove tokens from the former token bucket o TBthreshold.fill.latter = max(0, TBthreshold.fill.latter - packet.size); //remove tokens from the latter token bucket o if (TBthreshold.fill.former < TBthreshold.threshold.former) then if (TBthreshold.fill.latter < TBthreshold.shallow.threshold.latter) then if (TBthreshold.fill.latter >= TBthreshold.threshold.latter) then one-Nth packets are threshold-marked else packet.mark = threshold-marked; //do threshold marking with two thresholds only when TBthreshold.fill.former <= TBthreshold.threshold.former o TBthreshold.lastUpdate = now --- Best regards, Daisuke _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 20 23:47:22 2009 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 0E38E3A6A46; Tue, 20 Jan 2009 23:47:22 -0800 (PST) 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 73E163A6A1A for ; Tue, 20 Jan 2009 23:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.199 X-Spam-Level: ** X-Spam-Status: No, score=2.199 tagged_above=-999 required=5 tests=[AWL=1.689, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=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 3SFspy-S0VQe for ; Tue, 20 Jan 2009 23:47:19 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 0FEDD3A69D4 for ; Tue, 20 Jan 2009 23:47:18 -0800 (PST) Received: (qmail 63234 invoked by alias); 21 Jan 2009 07:47:02 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 21 Jan 2009 07:47:02 -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 n0L7l1j1019196 for ; Wed, 21 Jan 2009 16:47:01 +0900 Received: from gwall2.bb.ntt-at.co.jp (gwall2.bb.ntt-at.co.jp [192.168.5.202]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n0L7l1ja021163 for ; Wed, 21 Jan 2009 16:47:01 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: (from root@localhost) by gwall2.bb.ntt-at.co.jp (8.13.1/8.13.1) id n0L7kt9e025692 for pcn@ietf.org; Wed, 21 Jan 2009 16:46:55 +0900 Received: from mercury.tec.ntt-at.co.jp [192.168.22.39] by gwall2.bb.ntt-at.co.jp with ESMTP id SAA25691; Wed, 21 Jan 2009 16:46:55 +0900 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 714CD53F61; Wed, 21 Jan 2009 16:46:56 +0900 (JST) Date: Wed, 21 Jan 2009 16:46:00 +0900 From: SATOH Daisuke To: pcn@ietf.org Message-Id: <20090121164504.0EC9.26AD349@ntt-at.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] Subject: [PCN] Please modify the marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, If you received this e-mail again, I'm sorry. I would like you to modify draft-ietf-pcn-marking-behaviour-01. I made an example of modification as follows. I understand I have to show you the performance of our algorithm. So I have to update draft-satoh-pcn-st-marking-00. We have simulated our algorithm in extreme cases for both admission and termination. Now we are simulating it. Please wait for performance evaluation awhile. --- 2.3. Threshold meter function 2.3.1 Threshold meter function with One threshold A PCN-node MUST implement a Threshold Meter that has behaviour functionally equivalent to the following. The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBthreshold.fill=0. The token bucket has a configured intermediate depth, termed TBthreshold.threshold. If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not. 2.3.2 Threshold meter function with two threshold A PCN-node MUST implement a Threshold Meter that has behaviour functionally equivalent to the following. The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBthreshold.fill=0. The token bucket has two configured intermediate depths, termed TBthreshold.shallow.threshold and TBthreshold.threshold, where TBthreshold.shallow.threshold is greater than TBthreshold.threshold. If (TBthreshold.fill < TBthreshold.shallow.threshold) and (TBthreshold.fill >= TBthreshold.threshold), then the meter indicates to the Marking function that one-N-th packets are threshold-marked. If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not. 2.5 Combination of the meter functions A PCN-node MAY implement combination of Threshold and Excess traffic meters. The meter is composed of two tandem meters of Threshold and Excess traffic meters or two Threshold meters or two Excess traffic meters. The former meter is used for marking switch and the latter meter is used for marking. The combined meter has behaviour functionally equivalent to the following. If TBthreshold.fill >= TBthreshold.threshold (when the former meter is the Threshold meter) or if the token bucket is not empty (the former meter is the Excess traffic meter), the combined meter indicates to the Marking function that the packet is not to be marked even if the latter meter indicates to the Marking function that the packet is to be marked. Otherwise, the combined meter indicates the same result as the latter meter's indication to the Marking function. A.3 Combined metering and marking The combined meter by using two Threshold meters is introduced. The two combined token buckets with the following parameters: o TBthreshold.PCN-threshold-rate.former: token rate of the former token bucket (bits/second) o TBthreshold.PCN-threshold-rate.latter: token rate of the latter token bucket (bits/second) o TBthreshold.max.former: depth of the former token bucket (bits) o TBthreshold.max.latter: depth of the latter token bucket (bits) o TBthreshold.threshold.former: marking threshold of the former token bucket (bits) o TBthreshold.shallow.threshold.latter: One-Nth marking threshold of the latter token bucket (bits) o TBthreshold.threshold.latter: marking threshold of the latter token bucket (bits) o TBthreshold.lastUpdate: time both token buckets were last updated (seconds) o TBthreshold.fill.former: amount of tokens in the former token bucket (bits) o TBthreshold.fill.latter: amount of tokens in the latter token bucket (bits) A PCN-packet has the following parameters: o packet.size: the size of the PCN-packet (bits) o packet.mark: the PCN encoding state of the packet In addition there is the parameter: o now: the current time (seconds) The following steps are performed when a PCN-packet arrives on a link: o TBthreshold.fill.former = min(TBthreshold.max.former, TBthreshold.fill.former + TBthreshold.PCN-threshold-rate.former*(now - TBthreshold.lastUpdate)); // add tokens to the former token bucket o TBthreshold.fill.latter = min(TBthreshold.max.latter, TBthreshold.fill.latter + TBthreshold.PCN-threshold-rate.latter*(now - TBthreshold.lastUpdate));// add tokens to the latter token bucket o TBthreshold.fill.former = max(0, TBthreshold.fill.former - packet.size); //remove tokens from the former token bucket o TBthreshold.fill.latter = max(0, TBthreshold.fill.latter - packet.size); //remove tokens from the latter token bucket o if (TBthreshold.fill.former < TBthreshold.threshold.former) then if (TBthreshold.fill.latter < TBthreshold.shallow.threshold.latter) then if (TBthreshold.fill.latter >= TBthreshold.threshold.latter) then one-Nth packets are threshold-marked else packet.mark = threshold-marked; //do threshold marking with two thresholds only when TBthreshold.fill.former <= TBthreshold.threshold.former o TBthreshold.lastUpdate = now --- Best regards, Daisuke _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 21 01:10:42 2009 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 75EF83A67F0; Wed, 21 Jan 2009 01:10:42 -0800 (PST) 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 BCF7D3A67F0 for ; Wed, 21 Jan 2009 01:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, J_CHICKENPOX_64=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 zJuxgQ4mVEmv for ; Wed, 21 Jan 2009 01:10:38 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 0BF793A67B6 for ; Wed, 21 Jan 2009 01:10:37 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 09:10:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 09:10:19 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD780B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20090121164504.0EC9.26AD349@ntt-at.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Please modify the marking behaviour draft Thread-Index: Acl7nHcy8IUIMrIQQzmIn/mg3iMF1QAC0kpw From: To: , X-OriginalArrivalTime: 21 Jan 2009 09:10:20.0765 (UTC) FILETIME=[15D320D0:01C97BA8] Subject: Re: [PCN] Please modify the marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Daisuke Got your email! Yes, will wait to see your evaluation data. Best wishes phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { SATOH Daisuke { Sent: 21 January 2009 07:46 { To: pcn@ietf.org { Subject: [PCN] Please modify the marking behaviour draft { { { { Hi Phil, { { { If you received this e-mail again, I'm sorry. { { { I would like you to modify draft-ietf-pcn-marking-behaviour-01. I made { an example of modification as follows. { I understand I have to show you the performance of our algorithm. So I { have to update draft-satoh-pcn-st-marking-00. We have simulated our { algorithm { in extreme cases for both admission and termination. Now we are { simulating it. Please wait for performance evaluation awhile. { { { { --- { 2.3. Threshold meter function { { 2.3.1 Threshold meter function with One threshold { A PCN-node MUST implement a Threshold Meter that has behaviour { functionally { equivalent to the following. The meter acts like a token bucket, which { is sized in bits and has a configured bit rate, termed { PCN-threshold-rate. The amount of tokens in the token bucket is termed { TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a { maximum value TBthreshold.max. Tokens are removed equal to the size in { bits of the metered-packet, to a minimum TBthreshold.fill=0. The token { bucket has a configured intermediate depth, termed TBthreshold.threshold. { If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to { the Marking function that the packet is to be threshold-marked; { otherwise it does not. { { { 2.3.2 Threshold meter function with two threshold { A PCN-node MUST implement a Threshold Meter that has behaviour { functionally { equivalent to the following. { { The meter acts like a token bucket, which is sized in bits and has a { configured { bit rate, termed PCN-threshold-rate. The amount of tokens in the token { bucket is termed TBthreshold.fill. Tokens are added at the { PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are { removed equal to the size in bits of the metered-packet, to a minimum { TBthreshold.fill=0. The token bucket has two configured intermediate { depths, termed TBthreshold.shallow.threshold and TBthreshold.threshold, { where TBthreshold.shallow.threshold is greater than { TBthreshold.threshold. If (TBthreshold.fill < { TBthreshold.shallow.threshold) and (TBthreshold.fill >= { TBthreshold.threshold), then the meter indicates to the Marking function { that one-N-th packets are threshold-marked. If TBthreshold.fill < { TBthreshold.threshold, then the meter indicates to the Marking function { that the packet is to be threshold-marked; otherwise it does not. { { { { 2.5 Combination of the meter functions { A PCN-node MAY implement combination of Threshold and Excess traffic { meters. The { meter is composed of two tandem meters of Threshold and Excess traffic { meters or two Threshold meters or two Excess traffic meters. The former { meter is used for marking switch and the latter meter is used for { marking. { { The combined meter has behaviour functionally equivalent to the following. { { { If TBthreshold.fill >= TBthreshold.threshold (when the former meter is the { Threshold { meter) or if the token bucket is not empty (the former meter is the { Excess traffic meter), the combined meter indicates to the Marking { function that the packet is not to be marked even if the latter meter { indicates to the Marking function that the packet is to be marked. { Otherwise, the combined meter indicates the same result as the latter { meter's indication to the Marking function. { { { { A.3 Combined metering and marking { The combined meter by using two Threshold meters is introduced. The two { combined { token buckets with the following parameters: { { o TBthreshold.PCN-threshold-rate.former: token rate of the former token { bucket (bits/second) { { o TBthreshold.PCN-threshold-rate.latter: token rate of the latter token { bucket (bits/second) { { o TBthreshold.max.former: depth of the former token bucket (bits) { { o TBthreshold.max.latter: depth of the latter token bucket (bits) { { o TBthreshold.threshold.former: marking threshold of the former token { bucket (bits) { { o TBthreshold.shallow.threshold.latter: One-Nth marking threshold of the { latter token bucket (bits) { { o TBthreshold.threshold.latter: marking threshold of the latter token { bucket (bits) { { o TBthreshold.lastUpdate: time both token buckets were last updated { (seconds) { { o TBthreshold.fill.former: amount of tokens in the former token bucket { (bits) { { o TBthreshold.fill.latter: amount of tokens in the latter token bucket { (bits) { { { A PCN-packet has the following parameters: { { o packet.size: the size of the PCN-packet (bits) { { o packet.mark: the PCN encoding state of the packet { { In addition there is the parameter: { { o now: the current time (seconds) { { { The following steps are performed when a PCN-packet arrives on a link: { { o TBthreshold.fill.former = min(TBthreshold.max.former, { TBthreshold.fill.former + { TBthreshold.PCN-threshold-rate.former*(now - TBthreshold.lastUpdate)); { // add tokens to the former token bucket { { o TBthreshold.fill.latter = min(TBthreshold.max.latter, { TBthreshold.fill.latter + { TBthreshold.PCN-threshold-rate.latter*(now - TBthreshold.lastUpdate));// { add tokens to the latter token bucket { { { o TBthreshold.fill.former = max(0, TBthreshold.fill.former - packet.size); { //remove { tokens from the former token bucket { { { o TBthreshold.fill.latter = max(0, TBthreshold.fill.latter - packet.size); { //remove { tokens from the latter token bucket { { { o if (TBthreshold.fill.former < TBthreshold.threshold.former) then { if (TBthreshold.fill.latter < TBthreshold.shallow.threshold.latter) { then { if (TBthreshold.fill.latter >= TBthreshold.threshold.latter) then { one-Nth packets are threshold-marked { else { packet.mark = threshold-marked; { //do threshold marking with two thresholds only when { TBthreshold.fill.former <= TBthreshold.threshold.former { { o TBthreshold.lastUpdate = now { --- { Best regards, { { Daisuke { { _______________________________________________ { 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