From wwwrun@core3.amsl.com Thu Jun 4 12:08:24 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 275933A69FE; Thu, 4 Jun 2009 12:08:24 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090604190824.275933A69FE@core3.amsl.com> Date: Thu, 4 Jun 2009 12:08:24 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] Last Call: draft-ietf-pcn-marking-behaviour (Metering and marking behaviour of PCN-nodes) to Proposed Standard X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 19:08:24 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'Metering and marking behaviour of PCN-nodes ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17745&rfc_flag=0 From lars.eggert@nokia.com Tue Jun 16 06:23:07 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9073A6D6D for ; Tue, 16 Jun 2009 06:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 9NCnoVM7LIfG for ; Tue, 16 Jun 2009 06:23:06 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id DEEBE3A6D69 for ; Tue, 16 Jun 2009 06:23:05 -0700 (PDT) Received: from pc-g103.wlan.inet.fi (pc-g103.wlan.inet.fi [62.71.98.103]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5GDNBHh028184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 16 Jun 2009 16:23:12 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: pcn@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-1-563414240; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 16:23:06 +0300 References: <20090615144524.CAF833A69D9@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Tue, 16 Jun 2009 16:23:12 +0300 (EEST) Subject: [PCN] Fwd: Last Call: draft-ietf-ancp-framework (Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: IETF discussion list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 13:23:07 -0000 --Apple-Mail-1-563414240 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, FYI, this document talks quite a bit about flow admission. I suspect PCN folks would want to review it and send comments to the main IETF list (reply-to set accordingly) during its last call. Lars Begin forwarded message: > From: The IESG > Date: June 15, 2009 17:45:24 GMT+03:00 > To: IETF-Announce > Cc: "ancp@ietf.org" > Subject: Last Call: draft-ietf-ancp-framework (Framework and > Requirements for an Access Node Control Mechanism in Broadband > Multi-Service Networks) to Informational RFC > Reply-To: "ietf@ietf.org" > > The IESG has received a request from the Access Node Control > Protocol WG > (ancp) to consider the following document: > > - 'Framework and Requirements for an Access Node Control Mechanism in > Broadband Multi-Service Networks ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-06-29. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-10.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15270&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-1-563414240 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTYxMzIzMDZaMCMGCSqGSIb3DQEJBDEWBBR7VhgrJ7QfXws/ ZY0xx5mtrhy1/zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAKHbJblAssIPEsBRROjbpFC3CH5ple3KOLhol5KfHG/7Ybtbf+hPj FUKIZXRRQ6Fo8I31lexPGrbbhH+ZJxBtksHuieY4ddMCVkqfVU/PiSgcJGamlbWOSxbAPq7Votlr XhoD7qv1hoB2Fvn6NmXL836UPtwb6gxt9y6VO7G6vXTB84YRJS1bW9oddnugnJZPWQa3wZiNRh4T tXYF9RorXtw1Xn52mHQ5mZbRnzIRl/1tx0rOwXxXct7nzlJgPcacdS4S5Mgwq8xEEVDf0xdHZD4+ xboZf10IFn9NG6tms6uqMYYoKtQ0T3DMeQ9GziO5LKvyfTdGkjxUMhGdPNM6CQAAAAAAAA== --Apple-Mail-1-563414240-- From rfc-editor@rfc-editor.org Thu Jun 18 09:46:55 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313AE28C162; Thu, 18 Jun 2009 09:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.305 X-Spam-Level: X-Spam-Status: No, score=-17.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 r5TUO8ioxhq3; Thu, 18 Jun 2009 09:46:54 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id F2B9028C354; Thu, 18 Jun 2009 09:46:51 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 3E03D2D184B; Thu, 18 Jun 2009 09:45:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090618164540.3E03D2D184B@bosco.isi.edu> Date: Thu, 18 Jun 2009 09:45:40 -0700 (PDT) X-Mailman-Approved-At: Thu, 18 Jun 2009 10:05:46 -0700 Cc: pcn@ietf.org, rfc-editor@rfc-editor.org Subject: [PCN] RFC 5559 on Pre-Congestion Notification (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: , X-List-Received-Date: Thu, 18 Jun 2009 16:46:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5559 Title: Pre-Congestion Notification (PCN) Architecture Author: P. Eardley, Ed. Status: Informational Date: June 2009 Mailbox: philip.eardley@bt.com Pages: 54 Characters: 134827 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pcn-architecture-11.txt URL: http://www.rfc-editor.org/rfc/rfc5559.txt This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. This memo provides information for the Internet community. This document is a product of the Congestion and Pre-Congestion Notification Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From Black_David@emc.com Thu Jun 18 12:31:54 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCC83A6A50; Thu, 18 Jun 2009 12:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.304 X-Spam-Level: X-Spam-Status: No, score=-5.304 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+kZV1aiziCe; Thu, 18 Jun 2009 12:31:53 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B851C3A67F9; Thu, 18 Jun 2009 12:31:53 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n5IJW3ob011455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 15:32:03 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Thu, 18 Jun 2009 15:31:57 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n5IJVuNQ006467; Thu, 18 Jun 2009 15:31:57 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 15:31:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 15:31:31 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A02FE0ACB@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt Thread-Index: AcietuD6zRiwq9zOTSK6y1+D8tbCgVRffacw From: To: , X-OriginalArrivalTime: 18 Jun 2009 19:31:56.0827 (UTC) FILETIME=[71258EB0:01C9F04B] X-EMM-EM: Active X-Mailman-Approved-At: Thu, 18 Jun 2009 12:40:09 -0700 Cc: pcn@ietf.org, Black_David@emc.com Subject: [PCN] Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:31:54 -0000 I have been selected as the General Area Review Team (Gen-ART)=20 reviewer for this draft (for background on Gen-ART, please see=20 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive.=20 Document: draft-ietf-pcn-marking-behaviour-03.txt Reviewer: David L. Black Review Date: 18 June 2008 IETF LC End Date: 18 June 2008 Summary:=20 This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: This draft specified requirements on how the diffserv components in a PCN node need to behave in order to support PCN. In addition to specifying the requirements, an example algorithm (Appendix A) and extensive implementation notes (Appendix B) are provided. The implementation notes are very useful - the WG should be commended for working through the practical implementation considerations for this functionality up front as opposed to leaving them to implementers to puzzle out. All of my comments are on relatively minor points: "PCN-excess-rate" strikes me as a bad name for a configured throughput rate - I suggest choosing another term. Intuitively, I would expect PCN-excess-rate to refer to traffic that is in excess of a PCN configured rate. Section 2.1, 1st paragraph and Section B.3 need to cite a reference for how the DSCP and ECN field values are used to decide whether a packet is PCN or not. In Section 2.2, first bullet, what is "scheduling rate"? Please supply a definition. Section 2.4 - the second bullet also applies to competing non-PCN traffic (if that traffic is metered). The text needs to be adjusted to allow for this. Try: A packet SHOULD NOT be metered ... o If the PCN-packet is already .... o If this PCN-node drops the packet. Section 2.5 could use a reminder that while competing non-PCN packets may be metered, they MUST NOT be marked. This may have implications for the marking behavior that are probably most usefully discussed in Appendix B. Nits: - At the end of the first paragraph in B.1 "there needs to be" --> "there should be" The "should" is lower case. - idnits 2.11.11 noted that there is now a -04 version of the pcn-baseline-encoding draft, as was noted in the draft shepherd's writeup. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From philip.eardley@bt.com Fri Jun 19 05:56:31 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACCFD3A6A1D; Fri, 19 Jun 2009 05:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 iwi3Lt52TRDt; Fri, 19 Jun 2009 05:56:31 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A8B063A689B; Fri, 19 Jun 2009 05:56:30 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 13:56:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jun 2009 13:56:41 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7CF0@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A02FE0ACB@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt Thread-Index: AcietuD6zRiwq9zOTSK6y1+D8tbCgVRffacwACTmRAA= From: To: , X-OriginalArrivalTime: 19 Jun 2009 12:56:41.0974 (UTC) FILETIME=[6467E960:01C9F0DD] Cc: pcn@ietf.org Subject: Re: [PCN] Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:56:31 -0000 David, Thanks for your review & comments. { The implementation notes are very useful - the WG should be { commended for working through the practical implementation { considerations for this functionality up front as opposed to { leaving them to implementers to puzzle out. Thanks! { "PCN-excess-rate" strikes me as a bad name for a configured { throughput rate - I suggest choosing another term. =20 To be honest, I think it's too late to change it, as it's defined/used in the PCN architecture doc, which has just become RFC5559. { Section 2.1, 1st paragraph and Section B.3 need to cite a { reference for how the DSCP and ECN field values are used to { decide whether a packet is PCN or not. Ok, will add "For instance, the baseline encoding [ref]." {=20 { In Section 2.2, first bullet, what is "scheduling rate"? Please { supply a definition. I think the bullet needs re-phrasing. Here's what it says at the moment:-=20 <> how about the following? On all links in the PCN-domain, dropping MAY be done by: o metering all metered-packets to determine if the rate of metered- traffic on the link is greater than the rate allowed for such traffic. {=20 { Section 2.4 - the second bullet also applies to competing non-PCN { traffic (if that traffic is metered). The text needs to be adjusted { to allow for this. Try: {=20 { A packet SHOULD NOT be metered ... {=20 { o If the PCN-packet is already .... {=20 { o If this PCN-node drops the packet. Good spot, thanks {=20 { Section 2.5 could use a reminder that while competing non-PCN packets { may be metered, they MUST NOT be marked. This may have implications { for the marking behavior that are probably most usefully discussed { in Appendix B. ok, will add reminder.=20 {=20 { Nits: { - At the end of the first paragraph in B.1 { "there needs to be" --> "there should be" { The "should" is lower case. {=20 { - idnits 2.11.11 noted that there is now a -04 version of the { pcn-baseline-encoding draft, as was noted in the draft { shepherd's writeup. {=20 { Thanks, { --David { ---------------------------------------------------- { David L. Black, Distinguished Engineer { EMC Corporation, 176 South St., Hopkinton, MA 01748 { +1 (508) 293-7953 FAX: +1 (508) 293-7786 { black_david@emc.com Mobile: +1 (978) 394-7754 { ---------------------------------------------------- From menth@informatik.uni-wuerzburg.de Fri Jun 19 09:51:41 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881833A699C; Fri, 19 Jun 2009 09:51:41 -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 RUTwtD6LOC2h; Fri, 19 Jun 2009 09:51:40 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 8E0C43A6812; Fri, 19 Jun 2009 09:51:40 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 83E95A085D; Fri, 19 Jun 2009 18:51:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 74703A0882; Fri, 19 Jun 2009 18:51:50 +0200 (CEST) Received: from [192.168.1.2] (e180229055.adsl.alicedsl.de [85.180.229.55]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 2B407A0888; Fri, 19 Jun 2009 18:51:50 +0200 (CEST) Message-ID: <4A3BC227.6090003@informatik.uni-wuerzburg.de> Date: Fri, 19 Jun 2009 18:51:51 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04AD7CF0@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7CF0@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, gen-art@ietf.org, Black_David@emc.com Subject: Re: [PCN] Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 16:51:41 -0000 Hi Phil, hi David, philip.eardley@bt.com schrieb: > { "PCN-excess-rate" strikes me as a bad name for a configured > { throughput rate - I suggest choosing another term. > To be honest, I think it's too late to change it, as it's defined/used > in the PCN architecture doc, which has just become RFC5559. > An alternative is to simply talk about the reference rate of the excess/threshold meter and marker. I just want to say that there is no need to use the expression at all. The reference rates of the meters and markers are then configured with some specific values (e.g. admissible or supportable rates which were defined in the architecture draft). Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/8888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From Black_David@emc.com Fri Jun 19 12:30:46 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80903A6B76; Fri, 19 Jun 2009 12:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xodiMs+IjZk7; Fri, 19 Jun 2009 12:30:45 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 91B4A3A6B52; Fri, 19 Jun 2009 12:30:45 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n5JJUlLS009044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jun 2009 15:30:47 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Fri, 19 Jun 2009 15:30:39 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n5JJUUGo031336; Fri, 19 Jun 2009 15:30:38 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 15:30:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jun 2009 15:30:36 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0306578A@CORPUSMX80A.corp.emc.com> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7CF0@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Gen-art] Gen-ART review ofdraft-ietf-pcn-marking-behaviour-03.txt Thread-Index: AcietuD6zRiwq9zOTSK6y1+D8tbCgVRffacwACTmRAAAEutWkA== References: <9FA859626025B64FBC2AF149D97C944A02FE0ACB@CORPUSMX80A.corp.emc.com> <4A916DBC72536E419A0BD955EDECEDEC04AD7CF0@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 19 Jun 2009 19:30:37.0499 (UTC) FILETIME=[6C46D0B0:01C9F114] X-EMM-EM: Active Cc: pcn@ietf.org, Black_David@emc.com Subject: Re: [PCN] [Gen-art] Gen-ART review ofdraft-ietf-pcn-marking-behaviour-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 19:30:46 -0000 Philip, These suggested changes look fine, and I like Michael Menth's idea of rephrasing the text to discuss "reference rates of the meters and markers" instead of "PCN-excess-rate". Thanks, --David =20 > -----Original Message----- > From: gen-art-bounces@ietf.org=20 > [mailto:gen-art-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: Friday, June 19, 2009 8:57 AM > To: Black, David; gen-art@ietf.org > Cc: pcn@ietf.org; sob@harvard.edu; slblake@petri-meat.com > Subject: Re: [Gen-art] Gen-ART review=20 > ofdraft-ietf-pcn-marking-behaviour-03.txt >=20 > David, > Thanks for your review & comments. >=20 > { The implementation notes are very useful - the WG should be > { commended for working through the practical implementation > { considerations for this functionality up front as opposed to > { leaving them to implementers to puzzle out. > Thanks! >=20 > { "PCN-excess-rate" strikes me as a bad name for a configured > { throughput rate - I suggest choosing another term. =20 > To be honest, I think it's too late to change it, as it's defined/used > in the PCN architecture doc, which has just become RFC5559. >=20 > { Section 2.1, 1st paragraph and Section B.3 need to cite a > { reference for how the DSCP and ECN field values are used to > { decide whether a packet is PCN or not. > Ok, will add "For instance, the baseline encoding [ref]." >=20 > {=20 > { In Section 2.2, first bullet, what is "scheduling rate"? Please > { supply a definition. >=20 > I think the bullet needs re-phrasing. Here's what it says at the > moment:-=20 > < o metering all metered-packets to determine if the rate=20 > of metered- > traffic is greater than its scheduling rate (ie determine if any > packets are out-of-profile). > >> >=20 > how about the following? > On all links in the PCN-domain, dropping MAY be done by: > o metering all metered-packets to determine if the rate=20 > of metered- > traffic on the link is greater than the rate allowed for such > traffic. >=20 > {=20 > { Section 2.4 - the second bullet also applies to competing non-PCN > { traffic (if that traffic is metered). The text needs to be adjusted > { to allow for this. Try: > {=20 > { A packet SHOULD NOT be metered ... > {=20 > { o If the PCN-packet is already .... > {=20 > { o If this PCN-node drops the packet. >=20 > Good spot, thanks >=20 > {=20 > { Section 2.5 could use a reminder that while competing=20 > non-PCN packets > { may be metered, they MUST NOT be marked. This may have implications > { for the marking behavior that are probably most usefully discussed > { in Appendix B. >=20 > ok, will add reminder.=20 >=20 > {=20 > { Nits: > { - At the end of the first paragraph in B.1 > { "there needs to be" --> "there should be" > { The "should" is lower case. > {=20 > { - idnits 2.11.11 noted that there is now a -04 version of the > { pcn-baseline-encoding draft, as was noted in the draft > { shepherd's writeup. > {=20 > { Thanks, > { --David > { ---------------------------------------------------- > { David L. Black, Distinguished Engineer > { EMC Corporation, 176 South St., Hopkinton, MA 01748 > { +1 (508) 293-7953 FAX: +1 (508) 293-7786 > { black_david@emc.com Mobile: +1 (978) 394-7754 > { ---------------------------------------------------- >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art >=20 >=20 From sob@harvard.edu Sun Jun 21 11:53:37 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2383A6D68 for ; Sun, 21 Jun 2009 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_20=-0.74, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xxx1HM8pZek for ; Sun, 21 Jun 2009 11:53:37 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 2A41C3A6D03 for ; Sun, 21 Jun 2009 11:53:37 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id F24B318DBE40; Sun, 21 Jun 2009 14:53:51 -0400 (EDT) To: pcn@ietf.org Message-Id: <20090621185351.F24B318DBE40@newdev.eecs.harvard.edu> Date: Sun, 21 Jun 2009 14:53:51 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] 2nd call - pcn agenda topics for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 18:53:37 -0000 pcn is currently scheduled to meet thurs afternoon from 1300 to 1500 in Stockholm we requested agenda topics a month ago but did not get any (or if we did I misplaced them) - so this is a 2nd request for topics tnx Scott & Steve From menth@informatik.uni-wuerzburg.de Sun Jun 21 15:17:58 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DFFE3A68BF for ; Sun, 21 Jun 2009 15:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1vHa1fp61X6 for ; Sun, 21 Jun 2009 15:17: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 484473A6D8C for ; Sun, 21 Jun 2009 15:17:56 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id EE85E199098; Mon, 22 Jun 2009 00:18:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E17D9199092; Mon, 22 Jun 2009 00:18:07 +0200 (CEST) Received: from [85.176.246.176] (e176246176.adsl.alicedsl.de [85.176.246.176]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A648919908D; Mon, 22 Jun 2009 00:18:07 +0200 (CEST) Message-ID: <4A3EB1A2.1040005@informatik.uni-wuerzburg.de> Date: Mon, 22 Jun 2009 00:18:10 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Scott O. Bradner" References: <20090621185351.F24B318DBE40@newdev.eecs.harvard.edu> In-Reply-To: <20090621185351.F24B318DBE40@newdev.eecs.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] 2nd call - pcn agenda topics for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 22:17:58 -0000 Hi Scott, we need to define admission control and flow termination behavior more accurately and finalize the encoding issues. That's what I see is most important . Regards, Michael Scott O. Bradner schrieb: > pcn is currently scheduled to meet thurs afternoon from 1300 to 1500 > in Stockholm > > we requested agenda topics a month ago but did not get any > (or if we did I misplaced them) - > > so this is a 2nd request for topics > > tnx > > > Scott & 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/31-86644 (new), fax: (+49)-931/8888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From toby.moncaster@bt.com Mon Jun 22 02:48:11 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B943A6DBF for ; Mon, 22 Jun 2009 02:48:11 -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=[BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMKDAhclWt3g for ; Mon, 22 Jun 2009 02:48: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 1ED4C3A6DC2 for ; Mon, 22 Jun 2009 02:48:09 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 10:48:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jun 2009 10:48:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 2nd call - pcn agenda topics for Stockholm Thread-Index: AcnyoaJ9tdRgOvs8RQmGbJRnU864VAAfDb2QAAAtSuA= From: To: X-OriginalArrivalTime: 22 Jun 2009 09:48:23.0982 (UTC) FILETIME=[958464E0:01C9F31E] Subject: [PCN] FW: 2nd call - pcn agenda topics for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 09:48:11 -0000 And copying the list... -----Original Message----- From: Moncaster,T,Toby,CXR9 R=20 Sent: 22 June 2009 10:48 To: 'Scott O. Bradner' Subject: RE: [PCN] 2nd call - pcn agenda topics for Stockholm Assuming that Baseline encoding and Marking Behaviour will have both = progressed beyond IETF LC then there will need to be a session on next = steps (how to start putting things together within the overall = architecture, formalising experiments on alternative encoding schemes, = specific guidance on choice of DSCP). I also suspect the authors of the 3 approved experimental encodings = might want to have them on the agenda for discussion. I realise only one = of them has actually had a new draft version but at least one of the = others will by the draft cut-off in a fortnight... I am getting quite optimistic now that we can complete the overwhelming = majority of our charter by the end of this year... Toby ____________________________________________________________________=20 Toby Moncaster, Networks Research Centre, BT=20 B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Scott O. Bradner > Sent: 21 June 2009 19:54 > To: pcn@ietf.org > Subject: [PCN] 2nd call - pcn agenda topics for Stockholm >=20 >=20 > pcn is currently scheduled to meet thurs afternoon from 1300 to 1500 > in Stockholm >=20 > we requested agenda topics a month ago but did not get any > (or if we did I misplaced them) - >=20 > so this is a 2nd request for topics >=20 > tnx >=20 >=20 > Scott & Steve > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From tom.taylor@rogers.com Mon Jun 22 05:22:23 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D983628C1A4 for ; Mon, 22 Jun 2009 05:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsFbMS0-EVd6 for ; Mon, 22 Jun 2009 05:22:23 -0700 (PDT) Received: from smtp123.rog.mail.re2.yahoo.com (smtp123.rog.mail.re2.yahoo.com [206.190.53.28]) by core3.amsl.com (Postfix) with SMTP id F23B23A6B0C for ; Mon, 22 Jun 2009 05:22:22 -0700 (PDT) Received: (qmail 20608 invoked from network); 22 Jun 2009 12:22:36 -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=WLy90elyUx2aJ0FUhd2JxUTGBAeFBRM17dlwqmT5pKVHk+B30X8NqUpTaAeCRKHcXPbhWs9YnrPFPVjlCzcT4OzBPFu9VpDAh1ncZnj9PVAcDY9cceNReFkVEVLeu6u9LjmMH9Uo96lNLgrfXvBvJVLC7jf+37dkptTK5AKFX0k= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp123.rog.mail.re2.yahoo.com with SMTP; 22 Jun 2009 12:22:36 -0000 X-YMail-OSG: qgUf1vIVM1l9QBEjsFoSUj020a8sEpIJdiL7X5oqNjNuy6oV2gZGUjOUNPLMRw74sA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3F778D.4010406@rogers.com> Date: Mon, 22 Jun 2009 08:22:37 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Scott O. Bradner" References: <20090621185351.F24B318DBE40@newdev.eecs.harvard.edu> In-Reply-To: <20090621185351.F24B318DBE40@newdev.eecs.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] 2nd call - pcn agenda topics for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 12:22:23 -0000 We'll definitely have a CL edge behaviour draft to discuss. I can't speak for Anna on SM, but she may be waiting for me to produce a new template draft. Scott O. Bradner wrote: > pcn is currently scheduled to meet thurs afternoon from 1300 to 1500 > in Stockholm > > we requested agenda topics a month ago but did not get any > (or if we did I misplaced them) - > > so this is a 2nd request for topics > > tnx > > > Scott & Steve > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From khchan@huawei.com Mon Jun 22 07:05:31 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BFD3A6A07 for ; Mon, 22 Jun 2009 07:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXYDicf2HMtU for ; Mon, 22 Jun 2009 07:05:31 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 3655B3A6933 for ; Mon, 22 Jun 2009 07:05:31 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLN008NB8HLWX@usaga02-in.huawei.com> for pcn@ietf.org; Mon, 22 Jun 2009 07:05:45 -0700 (PDT) Received: from K73911.huawei.com ([10.192.21.55]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0KLN002RW8HAVS@usaga02-in.huawei.com> for pcn@ietf.org; Mon, 22 Jun 2009 07:05:45 -0700 (PDT) Date: Mon, 22 Jun 2009 10:05:33 -0400 From: Kwok Ho Chan In-reply-to: <20090621185351.F24B318DBE40@newdev.eecs.harvard.edu> To: sob@harvard.edu (Scott O. Bradner) Message-id: <0KLN002T38HKVS@usaga02-in.huawei.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <20090621185351.F24B318DBE40@newdev.eecs.harvard.edu> Cc: pcn@ietf.org Subject: Re: [PCN] 2nd call - pcn agenda topics for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 14:05:32 -0000 Hi Scott: I would like 10 minutes for Encoding Comparison draft. Thanks! -- Kwok -- At 02:53 PM 6/21/2009, Scott O. Bradner wrote: >pcn is currently scheduled to meet thurs afternoon from 1300 to 1500 >in Stockholm > >we requested agenda topics a month ago but did not get any >(or if we did I misplaced them) - > >so this is a 2nd request for topics > >tnx > > >Scott & Steve >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Tue Jun 23 07:37:20 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE5F3A6D1D for ; Tue, 23 Jun 2009 07:37:20 -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.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skbyVHiX0ZVA for ; Tue, 23 Jun 2009 07:37: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 7EB063A69C2 for ; Tue, 23 Jun 2009 07:37:19 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 15:37:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 15:37:34 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7CFD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <0KLN002T38HKVS@usaga02-in.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 2nd call - pcn agenda topics for Stockholm Thread-Index: AcnzQpCrXRlbcWqhSveCxIj0wmphswAzXhKg From: To: , X-OriginalArrivalTime: 23 Jun 2009 14:37:34.0740 (UTC) FILETIME=[25C9B540:01C9F410] Cc: pcn@ietf.org Subject: Re: [PCN] 2nd call - pcn agenda topics for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 14:37:20 -0000 Kwok Are you planning a revised version of this by the i-d deadline? Thanks phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Kwok { Ho Chan { Sent: 22 June 2009 15:06 { To: Scott O. Bradner { Cc: pcn@ietf.org { Subject: Re: [PCN] 2nd call - pcn agenda topics for Stockholm {=20 { Hi Scott: { I would like 10 minutes for Encoding Comparison draft. { Thanks! { -- Kwok -- {=20 { At 02:53 PM 6/21/2009, Scott O. Bradner wrote: {=20 { >pcn is currently scheduled to meet thurs afternoon from 1300 to 1500 { >in Stockholm { > { >we requested agenda topics a month ago but did not get any { >(or if we did I misplaced them) - { > { >so this is a 2nd request for topics { > { >tnx { > { > { >Scott & Steve { >_______________________________________________ { >PCN mailing list { >PCN@ietf.org { >https://www.ietf.org/mailman/listinfo/pcn {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From khchan@huawei.com Tue Jun 23 08:17:58 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38553A6ECB for ; Tue, 23 Jun 2009 08:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT+SFveaV732 for ; Tue, 23 Jun 2009 08:17:58 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 05A253A6EC3 for ; Tue, 23 Jun 2009 08:17:58 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLP00CQX6IBDV@usaga04-in.huawei.com> for pcn@ietf.org; Tue, 23 Jun 2009 10:18:12 -0500 (CDT) Received: from K73911.huawei.com ([10.192.21.55]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0KLP004Q56I9X6@usaga04-in.huawei.com> for pcn@ietf.org; Tue, 23 Jun 2009 10:18:11 -0500 (CDT) Date: Tue, 23 Jun 2009 11:18:08 -0400 From: Kwok Ho Chan To: philip.eardley@bt.com Message-id: <0KLP004Q86IAX6@usaga04-in.huawei.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <0KLN002T38HKVS@usaga02-in.huawei.com> Cc: pcn@ietf.org Subject: Re: [PCN] 2nd call - pcn agenda topics for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 15:17:58 -0000 Yes, at least one iteration. -- Kwok -- At 10:37 AM 6/23/2009, philip.eardley@bt.com wrote: >Kwok >Are you planning a revised version of this by the i-d deadline? >Thanks >phil > >{ -----Original Message----- >{ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >Kwok >{ Ho Chan >{ Sent: 22 June 2009 15:06 >{ To: Scott O. Bradner >{ Cc: pcn@ietf.org >{ Subject: Re: [PCN] 2nd call - pcn agenda topics for Stockholm >{ >{ Hi Scott: >{ I would like 10 minutes for Encoding Comparison draft. >{ Thanks! >{ -- Kwok -- >{ >{ At 02:53 PM 6/21/2009, Scott O. Bradner wrote: >{ >{ >pcn is currently scheduled to meet thurs afternoon from 1300 to 1500 >{ >in Stockholm >{ > >{ >we requested agenda topics a month ago but did not get any >{ >(or if we did I misplaced them) - >{ > >{ >so this is a 2nd request for topics >{ > >{ >tnx >{ > >{ > >{ >Scott & 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 philip.eardley@bt.com Wed Jun 24 01:24:19 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448E23A6902 for ; Wed, 24 Jun 2009 01:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 GmDwVRDhZxu5 for ; Wed, 24 Jun 2009 01:24:12 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 5EA533A6F16 for ; Wed, 24 Jun 2009 01:24:11 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 09:22:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F4A4.F2EDFCF6" Date: Wed, 24 Jun 2009 09:22:44 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Mod to draft-pcn-marking-behaviour Thread-Index: Acn0pPK4axVi3hVSTkSpkt5XAxsb8Q== From: To: X-OriginalArrivalTime: 24 Jun 2009 08:22:44.0925 (UTC) FILETIME=[F33A06D0:01C9F4A4] Subject: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:24:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F4A4.F2EDFCF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been editing in the various comments on http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03=20 In Section 2.4, both Michael and Ingemar said they found talk of MTU obscure, so have been working on phrasing this better. However I also realised another issue - S2.4 says:- =20 A PCN-node MUST implement an excess-traffic-meter that has behaviour functionally equivalent to the following. [description of 'base' excess-traffic-meter] In addition to the above, ... the meter SHOULD [do] ... packet size independent marking =20 What this says, now I read it properly, is that you MUST implement 'base' marking behaviour AND also you SHOULD implement "packet size independent marking". =20 Whereas what I think we actually wanted to say was: you MUST implement some kind of excess-traffic-marking behaviour, either the 'base' marking behaviour or "packet size independent marking" - the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you don't have to implement the 'base' marking behaviour as well. I checked with michael and toby and this is their understanding as well. =20 If this isn't your understanding, then please shout now! I'm trying to get a new version out COP tomorrow Thursday, taking account of all the comments on -03, including the ietf last call ones. Thanks. =20 =20 =20 Assuming this is ok, I'm proposing the following wording, which also gets rid of the obscure talk about MTU. =20 S2.4 now reads:- ... A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the "baseline" metering behaviour. =20 The "baseline" excess-traffic-meter has behaviour functionally equivalent to the following. =20 The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=3D0. If the token bucket is empty (Tetm =3D 0), then the meter indicates to the marking function = that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) =20 "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked. =20 =20 I also think it best to update Appendix A.2 so that it uses "packet size independent marking":- The following steps are performed when a PCN-packet arrives on a link: =20 o Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); = // add tokens to token bucket =20 o if (packet_mark !=3D excess-traffic-marked) then // do not meter packets that are already excess-traffic-marked =20 o =20 * if (Tetm < 0) then packet_mark =3D excess-traffic-marked; // do excess-traffic-marking. The algorithm ensures this is independent of packet size =20 * else Tetm =3D Tetm - packet_size; // remove tokens from token bucket if don't mark packet =20 o lastUpdate =3D now // Note: 'now' has the same value as in step 1 =20 =20 Also tweaked Appendix B.6: "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the "baseline" excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a small modification of the "baseline" excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket.=20 =20 "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). =20 =20 Thanks,=20 phil ------_=_NextPart_001_01C9F4A4.F2EDFCF6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been editing in the various = comments on h= ttp://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03

In Section 2.4, both Michael and Ingemar said = they found talk of MTU obscure, so have been working on phrasing this = better.

However I also realised another issue – = S2.4 says:-

 

   A PCN-node MUST implement an =
excess-traffic-meter that has behaviour
   functionally equivalent to the =
following.

[description of ‘base’ = excess-traffic-meter]

   In addition to the above, ... =
the meter SHOULD [do] ... packet size independent =
marking

 

What this says, now I read it properly, is = that you MUST implement ‘base’ marking behaviour AND also you SHOULD implement "packet size independent marking".

 

Whereas what I think we actually wanted to = say was: you MUST implement some kind of excess-traffic-marking behaviour, either the ‘base’ marking behaviour or "packet size independent marking" – the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you = don’t have to implement the ‘base’ marking behaviour as well. I = checked with michael and toby and this is their understanding as = well.

 

If this isn’t your understanding, then = please shout now! I’m trying to get a new version out COP tomorrow = Thursday, taking account of all the comments on -03, including the ietf last call ones. = Thanks.

 

 

 

Assuming this is ok, I’m proposing the = following wording, which also gets rid of the obscure talk about = MTU.

 

S2.4 now reads:-

...   A PCN-node MUST implement an =
excess-traffic-meter. The excess-traffic-meter SHOULD indicate =
excess-traffic-marking independent of packet size ("packet size =
independent marking") but otherwise MUST use the =
“baseline” metering behaviour.
       &nbs=
p;       
The =
“baseline” excess-traffic-meter has behaviour functionally =
equivalent to the following.
 
   The meter acts like a token =
bucket, which is sized in bits and has a configured reference =
rate.  The amount of tokens in the token bucket is termed =
Tetm.  Tokens are added at the reference rate (PCN-excess-rate), to =
a maximum value BSetm.  Tokens are removed equal to the size in =
bits of the metered-packet, to a minimum Tetm=3D0.  If the token =
bucket is empty (Tetm =3D 0), then the meter indicates to the marking =
function that the packet is to be excess-traffic-marked. (Explanation of =
abbreviations: T is short for Tokens, BS for bucket size, and etm for =
excess-traffic-meter.)
 
"Packet size independent marking" =
means that the size of the packet does not influence the decision about =
whether the meter indicates to the marking function that the packet is =
to be excess-traffic-marked.
 

 

I also think it best to update Appendix A.2 = so that it uses "packet size independent marking”:-

   The following steps are =
performed when a PCN-packet arrives on a
   =
link:
 
   o  Tetm =3D min(BSetm, Tetm =
+ (now - lastUpdate) * PCN-excess-rate); =
//
      add tokens to =
token bucket
 
   o  if (packet_mark !=3D =
excess-traffic-marked) then // do not =
meter
      packets that =
are already excess-traffic-marked
 
   o
 
      *  if =
(Tetm < 0) then packet_mark =3D excess-traffic-marked; // =
do
       &nbs=
p; excess-traffic-marking.  The algorithm ensures this =
is
       &nbs=
p; independent of packet size
 
      *  else =
Tetm =3D Tetm - packet_size; // remove tokens from =
token
       &nbs=
p; bucket if don't mark packet
 
   o  lastUpdate =3D now // =
Note: 'now' has the same value as in step 1

 

 

Also tweaked Appendix B.6:

   "Packet size independent =
marking" - excess-traffic-marking that is independent of packet =
size - is specified as a SHOULD in Section 2.4. With the =
“baseline” excess-traffic-meter behaviour, large packets are =
more likely to be excess-traffic-marked than small packets, because =
packets are marked if the number of tokens in the packet is smaller than =
the packet size. 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] [Menth09]. It can be achieved =
by a small modification of the “baseline” =
excess-traffic-meter: the number of tokens in the bucket can become =
negative; if this number is negative at a packet's arrival, the packet =
is marked; otherwise, the amount of tokens equal to the packet size is =
removed from the bucket.

 

"Packet size independent marking" =
is a 'SHOULD', rather than a 'MUST', because it may be slightly harder =
for some equipment to implement, and the impact of not doing it is =
undesirable but moderate (sufficient traffic is terminated, but flows =
with large packets are more likely to be terminated).  =

 
Thanks, =

phil
=00 ------_=_NextPart_001_01C9F4A4.F2EDFCF6-- From philip.eardley@bt.com Wed Jun 24 01:30:03 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10773A6808 for ; Wed, 24 Jun 2009 01:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_72=0.6, 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 W-GbWAXhA1Ac for ; Wed, 24 Jun 2009 01:29:56 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id A4E3E3A6829 for ; Wed, 24 Jun 2009 01:29:55 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 09:30:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F4A5.FD107B36" Date: Wed, 24 Jun 2009 09:30:10 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7D03@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Mod to draft-pcn-marking-behaviour Thread-Index: Acn0pPK4axVi3hVSTkSpkt5XAxsb8QAALvbQ From: To: , X-OriginalArrivalTime: 24 Jun 2009 08:30:11.0422 (UTC) FILETIME=[FD5C0FE0:01C9F4A5] Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:30:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F4A5.FD107B36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Btw, although this looks like a lot of text below, it is only slight wording changes to improve the clarity - but I thought it easiest to include paragraphs rather than isolated sentences. The only substantive issue is the one explained at the start.=20 =20 -----Original Message----- From: Eardley,PL,Philip,CXR9 R=20 Sent: 24 June 2009 09:23 To: pcn@ietf.org Subject: Proposed Mod to draft-pcn-marking-behaviour =20 I've been editing in the various comments on http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03=20 In Section 2.4, both Michael and Ingemar said they found talk of MTU obscure, so have been working on phrasing this better. However I also realised another issue - S2.4 says:- =20 A PCN-node MUST implement an excess-traffic-meter that has behaviour functionally equivalent to the following. [description of 'base' excess-traffic-meter] In addition to the above, ... the meter SHOULD [do] ... packet size independent marking =20 What this says, now I read it properly, is that you MUST implement 'base' marking behaviour AND also you SHOULD implement "packet size independent marking". =20 Whereas what I think we actually wanted to say was: you MUST implement some kind of excess-traffic-marking behaviour, either the 'base' marking behaviour or "packet size independent marking" - the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you don't have to implement the 'base' marking behaviour as well. I checked with michael and toby and this is their understanding as well. =20 If this isn't your understanding, then please shout now! I'm trying to get a new version out COP tomorrow Thursday, taking account of all the comments on -03, including the ietf last call ones. Thanks. =20 =20 =20 Assuming this is ok, I'm proposing the following wording, which also gets rid of the obscure talk about MTU. =20 S2.4 now reads:- ... A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the "baseline" metering behaviour. =20 The "baseline" excess-traffic-meter has behaviour functionally equivalent to the following. =20 The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=3D0. If the token bucket is empty (Tetm =3D 0), then the meter indicates to the marking function = that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) =20 "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked. =20 =20 I also think it best to update Appendix A.2 so that it uses "packet size independent marking":- The following steps are performed when a PCN-packet arrives on a link: =20 o Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); = // add tokens to token bucket =20 o if (packet_mark !=3D excess-traffic-marked) then // do not meter packets that are already excess-traffic-marked =20 o =20 * if (Tetm < 0) then packet_mark =3D excess-traffic-marked; // do excess-traffic-marking. The algorithm ensures this is independent of packet size =20 * else Tetm =3D Tetm - packet_size; // remove tokens from token bucket if don't mark packet =20 o lastUpdate =3D now // Note: 'now' has the same value as in step 1 =20 =20 Also tweaked Appendix B.6: "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the "baseline" excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a small modification of the "baseline" excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket.=20 =20 "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). =20 =20 Thanks,=20 phil ------_=_NextPart_001_01C9F4A5.FD107B36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Btw, although this looks like a lot = of text below, it is only slight wording changes to improve the clarity = – but I thought it easiest to include paragraphs rather than isolated = sentences.

The only substantive issue is the = one explained at the start.

 

-----Original Message-----
From: = Eardley,PL,Philip,CXR9 R
Sent: 24 June 2009 = 09:23
To: pcn@ietf.org
Subject: Proposed Mod to draft-pcn-marking-behaviour

 

I’ve been editing in the various = comments on h= ttp://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03

In Section 2.4, both Michael and Ingemar said = they found talk of MTU obscure, so have been working on phrasing this = better.

However I also realised another issue – = S2.4 says:-

 

   A PCN-node MUST implement an =
excess-traffic-meter that has behaviour
   functionally equivalent to the =
following.

[description of ‘base’ excess-traffic-meter]

   In addition to the above, ... =
the meter SHOULD [do] ... packet size independent =
marking

 

What this says, now I read it properly, is = that you MUST implement ‘base’ marking behaviour AND also you SHOULD implement "packet size independent marking".

 

Whereas what I think we actually wanted to = say was: you MUST implement some kind of excess-traffic-marking behaviour, either = the ‘base’ marking behaviour or "packet size independent marking" – the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you = don’t have to implement the ‘base’ marking behaviour as well. I = checked with michael and toby and this is their understanding as = well.

 

If this isn’t your understanding, then = please shout now! I’m trying to get a new version out COP tomorrow = Thursday, taking account of all the comments on -03, including the ietf last call = ones. Thanks.

 

 

 

Assuming this is ok, I’m proposing the = following wording, which also gets rid of the obscure talk about = MTU.

 

S2.4 now reads:-

...   A PCN-node MUST implement an =
excess-traffic-meter. The excess-traffic-meter SHOULD indicate =
excess-traffic-marking independent of packet size ("packet size =
independent marking") but otherwise MUST use the =
“baseline” metering behaviour.
       &nbs=
p;       
The =
“baseline” excess-traffic-meter has behaviour functionally =
equivalent to the following.
 
   The meter acts like a token =
bucket, which is sized in bits and has a configured reference =
rate.  The amount of tokens in the token bucket is termed =
Tetm.  Tokens are added at the reference rate (PCN-excess-rate), to =
a maximum value BSetm.  Tokens are removed equal to the size in =
bits of the metered-packet, to a minimum Tetm=3D0.  If the token =
bucket is empty (Tetm =3D 0), then the meter indicates to the marking =
function that the packet is to be excess-traffic-marked. (Explanation of =
abbreviations: T is short for Tokens, BS for bucket size, and etm for =
excess-traffic-meter.)
 
"Packet size independent marking" =
means that the size of the packet does not influence the decision about =
whether the meter indicates to the marking function that the packet is =
to be excess-traffic-marked.
 

 

I also think it best to update Appendix A.2 = so that it uses "packet size independent marking”:-

   The following steps are =
performed when a PCN-packet arrives on a
   =
link:
 
   o  Tetm =3D min(BSetm, Tetm =
+ (now - lastUpdate) * PCN-excess-rate); =
//
      add tokens to =
token bucket
 
   o  if (packet_mark !=3D =
excess-traffic-marked) then // do not =
meter
      packets that =
are already excess-traffic-marked
 
   o
 
      *  if =
(Tetm < 0) then packet_mark =3D excess-traffic-marked; // =
do
       &nbs=
p; excess-traffic-marking.  The algorithm ensures this =
is
       &nbs=
p; independent of packet size
 
      *  else =
Tetm =3D Tetm - packet_size; // remove tokens from =
token
       &nbs=
p; bucket if don't mark packet
 
   o  lastUpdate =3D now // =
Note: 'now' has the same value as in step 1

 

 

Also tweaked Appendix B.6:

   "Packet size independent =
marking" - excess-traffic-marking that is independent of packet =
size - is specified as a SHOULD in Section 2.4. With the =
“baseline” excess-traffic-meter behaviour, large packets are =
more likely to be excess-traffic-marked than small packets, because =
packets are marked if the number of tokens in the packet is smaller than =
the packet size. 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] [Menth09]. It can be achieved =
by a small modification of the “baseline” =
excess-traffic-meter: the number of tokens in the bucket can become =
negative; if this number is negative at a packet's arrival, the packet =
is marked; otherwise, the amount of tokens equal to the packet size is =
removed from the bucket.

 

"Packet size independent marking" =
is a 'SHOULD', rather than a 'MUST', because it may be slightly harder =
for some equipment to implement, and the impact of not doing it is =
undesirable but moderate (sufficient traffic is terminated, but flows =
with large packets are more likely to be terminated).  =

 
Thanks, =

phil
=00 ------_=_NextPart_001_01C9F4A5.FD107B36-- From toby.moncaster@bt.com Wed Jun 24 01:57:38 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA9C28C474 for ; Wed, 24 Jun 2009 01:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 Tq2ObyQ36ClF for ; Wed, 24 Jun 2009 01:57:29 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1386E28C470 for ; Wed, 24 Jun 2009 01:57:28 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 09:57:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F4A9.D673BED8" Date: Wed, 24 Jun 2009 09:57:41 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Proposed Mod to draft-pcn-marking-behaviour Thread-Index: Acn0pPK4axVi3hVSTkSpkt5XAxsb8QAA17Rw References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 24 Jun 2009 08:57:44.0585 (UTC) FILETIME=[D6B8B790:01C9F4A9] Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:57:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F4A9.D673BED8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I /think/ your new text still says you MUST implement baseline and SHOULD implement PSIM as well... =20 Suggested alternative text (though this is remarkably tricky to phrase clearly!). You also need to put the description of PSIM into the main body as this is the recommended action...: =20 A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter MUST be functionally equivalent to one of the meters described below, "Baseline" or "packet size independent marking", and SHOULD be the "packet-size independent marking" meter. To be clear, the "baseline" meter is easier to implement but it also unduly favours flows with small packets. Hence we recommend the use of the "packet-size independent marking" meter. =20 Toby =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 24 June 2009 09:23 To: pcn@ietf.org Subject: [PCN] Proposed Mod to draft-pcn-marking-behaviour =20 I've been editing in the various comments on http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03=20 In Section 2.4, both Michael and Ingemar said they found talk of MTU obscure, so have been working on phrasing this better. However I also realised another issue - S2.4 says:- =20 A PCN-node MUST implement an excess-traffic-meter that has behaviour functionally equivalent to the following. [description of 'base' excess-traffic-meter] In addition to the above, ... the meter SHOULD [do] ... packet size independent marking =20 What this says, now I read it properly, is that you MUST implement 'base' marking behaviour AND also you SHOULD implement "packet size independent marking". =20 Whereas what I think we actually wanted to say was: you MUST implement some kind of excess-traffic-marking behaviour, either the 'base' marking behaviour or "packet size independent marking" - the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you don't have to implement the 'base' marking behaviour as well. I checked with michael and toby and this is their understanding as well. =20 If this isn't your understanding, then please shout now! I'm trying to get a new version out COP tomorrow Thursday, taking account of all the comments on -03, including the ietf last call ones. Thanks. =20 =20 =20 Assuming this is ok, I'm proposing the following wording, which also gets rid of the obscure talk about MTU. =20 S2.4 now reads:- ... A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the "baseline" metering behaviour. =20 The "baseline" excess-traffic-meter has behaviour functionally equivalent to the following. =20 The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=3D0. If the token bucket is empty (Tetm =3D 0), then the meter indicates to the marking function = that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) =20 "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked. =20 =20 I also think it best to update Appendix A.2 so that it uses "packet size independent marking":- The following steps are performed when a PCN-packet arrives on a link: =20 o Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); = // add tokens to token bucket =20 o if (packet_mark !=3D excess-traffic-marked) then // do not meter packets that are already excess-traffic-marked =20 o =20 * if (Tetm < 0) then packet_mark =3D excess-traffic-marked; // do excess-traffic-marking. The algorithm ensures this is independent of packet size =20 * else Tetm =3D Tetm - packet_size; // remove tokens from token bucket if don't mark packet =20 o lastUpdate =3D now // Note: 'now' has the same value as in step 1 =20 =20 Also tweaked Appendix B.6: "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the "baseline" excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a small modification of the "baseline" excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket.=20 =20 "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). =20 =20 Thanks,=20 phil ------_=_NextPart_001_01C9F4A9.D673BED8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I /think/ your new text still says you MUST implement baseline and SHOULD = implement PSIM as well...

 

Suggested alternative text (though this is remarkably tricky to phrase clearly!). = You also need to put the description of PSIM into the main body as this is = the recommended action…:

 

A PCN-node MUST implement an excess-traffic-meter. = The excess-traffic-meter MUST be functionally equivalent to one of the = meters described below, “Baseline” or “packet size = independent marking”, and SHOULD be the “packet-size independent marking” meter. = To be clear, the “baseline” meter is easier to implement but it = also unduly favours flows with small packets. Hence we recommend the use of the = “packet-size independent marking” meter.

 

Toby

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: 24 June 2009 09:23
To: pcn@ietf.org
Subject: [PCN] Proposed Mod to = draft-pcn-marking-behaviour

 

I’ve been editing in = the various comments on h= ttp://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03

In Section 2.4, both = Michael and Ingemar said they found talk of MTU obscure, so have been working on = phrasing this better.

However I also realised = another issue – S2.4 says:-

 

   A PCN-node MUST implement an excess-traffic-meter that =
has behaviour
   functionally equivalent =
to the following.

[description of = ‘base’ excess-traffic-meter]

   In addition to the above, ... the meter SHOULD [do] =
... packet size independent marking

 

What this says, now I read = it properly, is that you MUST implement ‘base’ marking = behaviour AND also you SHOULD implement "packet size independent = marking".

 

Whereas what I think we = actually wanted to say was: you MUST implement some kind of = excess-traffic-marking behaviour, either the ‘base’ marking behaviour or = "packet size independent marking" – the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, = then you don’t have to implement the ‘base’ marking behaviour = as well. I checked with michael and toby and this is their understanding as = well.

 

If this isn’t your understanding, then please shout now! I’m trying to get a new = version out COP tomorrow Thursday, taking account of all the comments on -03, = including the ietf last call ones. Thanks.

 

 

 

Assuming this is ok, = I’m proposing the following wording, which also gets rid of the obscure talk = about MTU.

 

S2.4 now = reads:-

...   A PCN-node MUST implement an excess-traffic-meter. =
The excess-traffic-meter SHOULD indicate excess-traffic-marking =
independent of packet size ("packet size independent marking") =
but otherwise MUST use the “baseline” metering =
behaviour.
       =
;        
The =
“baseline” excess-traffic-meter has behaviour functionally =
equivalent to the =
following.
 
   =
The meter acts like a token bucket, which is sized in bits and has a =
configured reference rate.  The amount of tokens in the token =
bucket is termed Tetm.  Tokens are added at the reference rate =
(PCN-excess-rate), to a maximum value BSetm.  Tokens are removed =
equal to the size in bits of the metered-packet, to a minimum =
Tetm=3D0.  If the token bucket is empty (Tetm =3D 0), then the =
meter indicates to the marking function that the packet is to be =
excess-traffic-marked. (Explanation of abbreviations: T is short for =
Tokens, BS for bucket size, and etm for =
excess-traffic-meter.)
 
&=
quot;Packet size independent marking" means that the size of the =
packet does not influence the decision about whether the meter indicates =
to the marking function that the packet is to be =
excess-traffic-marked.
 

 

I also think it best to = update Appendix A.2 so that it uses "packet size independent = marking”:-

   The following steps are performed when a PCN-packet =
arrives on a
   =
link:
 
   =
o  Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * =
PCN-excess-rate); //
      =
add tokens to token =
bucket
 
   =
o  if (packet_mark !=3D excess-traffic-marked) then // do not =
meter
      packets that =
are already =
excess-traffic-marked
 
&n=
bsp;  =
o
 
   &nbs=
p;  *  if (Tetm < 0) then packet_mark =3D =
excess-traffic-marked; // =
do
         =
excess-traffic-marking.  The algorithm ensures this =
is
         =
independent of packet =
size
 
   &=
nbsp;  *  else Tetm =3D Tetm - packet_size; // remove tokens =
from =
token
       &nbs=
p; bucket if don't mark =
packet
 
   =
o  lastUpdate =3D now // Note: 'now' has the same value as in step =
1

 

 

Also tweaked Appendix B.6:

   "Packet size independent marking" - =
excess-traffic-marking that is independent of packet size - is specified =
as a SHOULD in Section 2.4. With the “baseline” =
excess-traffic-meter behaviour, large packets are more likely to be =
excess-traffic-marked than small packets, because packets are marked if =
the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a =
small modification of the “baseline” excess-traffic-meter: =
the number of tokens in the bucket can become negative; if this number =
is negative at a packet's arrival, the packet is marked; otherwise, the =
amount of tokens equal to the packet size is removed from the bucket. =

 

"Packet size independent marking" is a 'SHOULD', rather =
than a 'MUST', because it may be slightly harder for some equipment to =
implement, and the impact of not doing it is undesirable but moderate =
(sufficient traffic is terminated, but flows with large packets are more =
likely to be terminated).  =

 
Thanks, =

phil
------_=_NextPart_001_01C9F4A9.D673BED8-- From menth@informatik.uni-wuerzburg.de Wed Jun 24 02:00:23 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E99228C47D for ; Wed, 24 Jun 2009 02:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=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 sE3FPaCJWLcA for ; Wed, 24 Jun 2009 02:00:21 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 547653A6A38 for ; Wed, 24 Jun 2009 02:00:21 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3891FA0810; Wed, 24 Jun 2009 11:00:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2C59DA080F; Wed, 24 Jun 2009 11:00:37 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 0E01DA07CB; Wed, 24 Jun 2009 11:00:37 +0200 (CEST) Message-ID: <4A41EB36.5010003@informatik.uni-wuerzburg.de> Date: Wed, 24 Jun 2009 11:00:38 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: philip.eardley@bt.com, pcn , Toby Moncaster References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D02@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 09:00:23 -0000 Hi Phil, hi Toby, I still find the text somewhat hard to read and reformulated it a bit without changing its contents. Also the cryptic variables make the text hard to read. Moreover, I believe the following version clearly says what excess marking is and that it is a must, but PSIM is a preferred option but is only a SHOULD. A PCN-node MUST implement an excess-traffic-meter and marker. This algorithm has a reference rate which indicates the PCN packet rate that can remain unmarked after passing this function. Various implementations are possible. * A simple implementation uses a token bucket [here we need a reference] with bucket size S (bits) and reference rate R (bits/sec). Its current fill state is denoted by F (bits). The bucket is continuously filled with tokens at rate R, and passing packets remove the amount of tokens equal to their size from the current fill state F. If F is smaller than the packet size B (F > I’ve been editing in the various comments on > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03 > > In Section 2.4, both Michael and Ingemar said they found talk of MTU > obscure, so have been working on phrasing this better. > > However I also realised another issue – S2.4 says:- > > A PCN-node MUST implement an excess-traffic-meter that has behaviour > functionally equivalent to the following. > > [description of ‘base’ excess-traffic-meter] > > In addition to the above, ... the meter SHOULD [do] ... packet size independent marking > > What this says, now I read it properly, is that you MUST implement > ‘base’ marking behaviour AND also you SHOULD implement "packet size > independent marking". > > Whereas what I think we actually wanted to say was: you MUST implement > some kind of excess-traffic-marking behaviour, either the ‘base’ > marking behaviour or "packet size independent marking" – the latter is > suggested ie you SHOULD implement "packet size independent marking" > and if you do, then you don’t have to implement the ‘base’ marking > behaviour as well. I checked with michael and toby and this is their > understanding as well. > > If this isn’t your understanding, then please shout now! I’m trying to > get a new version out COP tomorrow Thursday, taking account of all the > comments on -03, including the ietf last call ones. Thanks. > > Assuming this is ok, I’m proposing the following wording, which also > gets rid of the obscure talk about MTU. > > S2.4 now reads:- > > ... A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the “baseline” metering behaviour. > > The “baseline” excess-traffic-meter has behaviour functionally equivalent to the following. > > The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=0. If the token bucket is empty (Tetm = 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) > > "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked. > > > I also think it best to update Appendix A.2 so that it uses "packet > size independent marking”:- > > The following steps are performed when a PCN-packet arrives on a > link: > > o Tetm = min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); // > add tokens to token bucket > > o if (packet_mark != excess-traffic-marked) then // do not meter > packets that are already excess-traffic-marked > > o > > * if (Tetm < 0) then packet_mark = excess-traffic-marked; // do > excess-traffic-marking. The algorithm ensures this is > independent of packet size > > * else Tetm = Tetm - packet_size; // remove tokens from token > bucket if don't mark packet > > o lastUpdate = now // Note: 'now' has the same value as in step 1 > > Also tweaked Appendix B.6: > > "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the “baseline” excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a small modification of the “baseline” excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket. > > "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). > > Thanks, > phil > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From toby.moncaster@bt.com Wed Jun 24 05:36:33 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BBA3A68D2 for ; Wed, 24 Jun 2009 05:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 e4663Z9NT6TK for ; Wed, 24 Jun 2009 05:36:23 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 54C2E3A683F for ; Wed, 24 Jun 2009 05:36:23 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 13:35:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F4C8.3403F7DC" Date: Wed, 24 Jun 2009 13:35:03 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Proposed Mod to draft-pcn-marking-behaviour Thread-Index: Acn0pPK4axVi3hVSTkSpkt5XAxsb8QAA17RwAAJ3t7AABX+aAA== References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 24 Jun 2009 12:35:08.0554 (UTC) FILETIME=[35886EA0:01C9F4C8] Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 12:36:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F4C8.3403F7DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems fine to me... =20 Toby =20 From: Eardley,PL,Philip,CXR9 R=20 Sent: 24 June 2009 12:58 To: Moncaster,T,Toby,CXR9 R; 'pcn@ietf.org' Subject: RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour =20 1. how about this? <> 2. ok, so a fuller description of "packet size independent marking" needs to be in the main body:- =20 For "packet size independent marking" the excess-traffic-meter has behaviour functionally equivalent to the following. =20 The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed F_etm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BS_etm. If the token bucket is negative (F_etm < 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. If the token bucket is not negative, then tokens are removed equal to the size in bits of the metered-packet (and the meter does not indicate to the marking function that the packet is to be excess-traffic-marked). (Explanation of abbreviations: F is short for Fill of the token bucket, BS for bucket size, and etm for excess-traffic-meter.) =20 =20 =20 -----Original Message----- From: Moncaster,T,Toby,CXR9 R=20 Sent: 24 June 2009 09:58 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour =20 I /think/ your new text still says you MUST implement baseline and SHOULD implement PSIM as well... =20 Suggested alternative text (though this is remarkably tricky to phrase clearly!). You also need to put the description of PSIM into the main body as this is the recommended action...: =20 A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter MUST be functionally equivalent to one of the meters described below, "Baseline" or "packet size independent marking", and SHOULD be the "packet-size independent marking" meter. To be clear, the "baseline" meter is easier to implement but it also unduly favours flows with small packets. Hence we recommend the use of the "packet-size independent marking" meter. =20 Toby =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 24 June 2009 09:23 To: pcn@ietf.org Subject: [PCN] Proposed Mod to draft-pcn-marking-behaviour =20 I've been editing in the various comments on http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03=20 In Section 2.4, both Michael and Ingemar said they found talk of MTU obscure, so have been working on phrasing this better. However I also realised another issue - S2.4 says:- =20 A PCN-node MUST implement an excess-traffic-meter that has behaviour functionally equivalent to the following. [description of 'base' excess-traffic-meter] In addition to the above, ... the meter SHOULD [do] ... packet size independent marking =20 What this says, now I read it properly, is that you MUST implement 'base' marking behaviour AND also you SHOULD implement "packet size independent marking". =20 Whereas what I think we actually wanted to say was: you MUST implement some kind of excess-traffic-marking behaviour, either the 'base' marking behaviour or "packet size independent marking" - the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you don't have to implement the 'base' marking behaviour as well. I checked with michael and toby and this is their understanding as well. =20 If this isn't your understanding, then please shout now! I'm trying to get a new version out COP tomorrow Thursday, taking account of all the comments on -03, including the ietf last call ones. Thanks. =20 =20 =20 Assuming this is ok, I'm proposing the following wording, which also gets rid of the obscure talk about MTU. =20 S2.4 now reads:- ... A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the "baseline" metering behaviour. =20 The "baseline" excess-traffic-meter has behaviour functionally equivalent to the following. =20 The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=3D0. If the token bucket is empty (Tetm =3D 0), then the meter indicates to the marking function = that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) =20 "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked. =20 =20 I also think it best to update Appendix A.2 so that it uses "packet size independent marking":- The following steps are performed when a PCN-packet arrives on a link: =20 o Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); = // add tokens to token bucket =20 o if (packet_mark !=3D excess-traffic-marked) then // do not meter packets that are already excess-traffic-marked =20 o =20 * if (Tetm < 0) then packet_mark =3D excess-traffic-marked; // do excess-traffic-marking. The algorithm ensures this is independent of packet size =20 * else Tetm =3D Tetm - packet_size; // remove tokens from token bucket if don't mark packet =20 o lastUpdate =3D now // Note: 'now' has the same value as in step 1 =20 =20 Also tweaked Appendix B.6: "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the "baseline" excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a small modification of the "baseline" excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket.=20 =20 "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). =20 =20 Thanks,=20 phil ------_=_NextPart_001_01C9F4C8.3403F7DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems fine to me…

 

Toby

 

From: Eardley,PL,Philip,CXR9 R
Sent: 24 June 2009 12:58
To: Moncaster,T,Toby,CXR9 R; 'pcn@ietf.org'
Subject: RE: [PCN] Proposed Mod to = draft-pcn-marking-behaviour

 

  1. how about this? <<PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking = independent of packet size ("packet size independent marking"); if = "packet size independent marking" is not implemented then the excess-traffic-meter MUST use the “baseline” metering behaviour.>>
  2. ok, so a fuller description of "packet size independent marking" needs to = be in the main body:-

 

For "packet size independent marking" the =
excess-traffic-meter has behaviour functionally equivalent to the =
following.
 
The meter =
acts like a token bucket, which is sized in bits and has a configured =
reference rate.  The amount of tokens in the token bucket is termed =
F_etm.  Tokens are added at the reference rate (PCN-excess-rate), =
to a maximum value BS_etm. If the token bucket is negative (F_etm =
< 0), then the meter indicates to the marking function that the =
packet is to be excess-traffic-marked. If the token bucket is not =
negative, then tokens are removed equal to the size in bits of the =
metered-packet (and the meter does not indicate to the marking function =
that the packet is to be excess-traffic-marked).  (Explanation of =
abbreviations: F is short for Fill of the token bucket, BS for bucket =
size, and etm for =
excess-traffic-meter.)
 
&=
nbsp;

 

-----Origina= l Message-----
From: Moncaster,T,Toby,CXR9 R
Sent: 24 June 2009 09:58
To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] Proposed Mod to = draft-pcn-marking-behaviour

 

I /think/ your new text still says you MUST implement baseline and SHOULD implement PSIM as well...

 <= /o:p>

Suggested alternative text (though this is remarkably tricky to phrase clearly!). = You also need to put the description of PSIM into the main body as this is = the recommended action…:

 <= /o:p>

A PCN-node MUST implement an excess-traffic-meter. = The excess-traffic-meter MUST be functionally equivalent to one of the = meters described below, “Baseline” or “packet size = independent marking”, and SHOULD be the “packet-size independent = marking” meter. To be clear, the “baseline” meter is easier to = implement but it also unduly favours flows with small packets. Hence we recommend the = use of the “packet-size independent marking” meter.

 

Toby

 <= /o:p>

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: 24 June 2009 09:23
To: pcn@ietf.org
Subject: [PCN] Proposed Mod to = draft-pcn-marking-behaviour

 

I’ve been editing in = the various comments on h= ttp://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03

In Section 2.4, both = Michael and Ingemar said they found talk of MTU obscure, so have been working on = phrasing this better.

However I also realised = another issue – S2.4 says:-

 

   A PCN-node MUST implement an excess-traffic-meter that =
has behaviour
   functionally equivalent =
to the following.

[description of = ‘base’ excess-traffic-meter]

   In addition to the above, ... the meter SHOULD [do] =
... packet size independent marking

 

What this says, now I read = it properly, is that you MUST implement ‘base’ marking = behaviour AND also you SHOULD implement "packet size independent = marking".

 

Whereas what I think we = actually wanted to say was: you MUST implement some kind of = excess-traffic-marking behaviour, either the ‘base’ marking behaviour or = "packet size independent marking" – the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, = then you don’t have to implement the ‘base’ marking behaviour = as well. I checked with michael and toby and this is their understanding as = well.

 

If this isn’t your understanding, then please shout now! I’m trying to get a new = version out COP tomorrow Thursday, taking account of all the comments on -03, = including the ietf last call ones. Thanks.

 

 

 

Assuming this is ok, = I’m proposing the following wording, which also gets rid of the obscure talk = about MTU.

 

S2.4 now = reads:-

...   A PCN-node MUST implement an excess-traffic-meter. =
The excess-traffic-meter SHOULD indicate excess-traffic-marking =
independent of packet size ("packet size independent marking") =
but otherwise MUST use the “baseline” metering =
behaviour.
       =
;        
The =
“baseline” excess-traffic-meter has behaviour functionally =
equivalent to the =
following.
 
   =
The meter acts like a token bucket, which is sized in bits and has a =
configured reference rate.  The amount of tokens in the token =
bucket is termed Tetm.  Tokens are added at the reference rate =
(PCN-excess-rate), to a maximum value BSetm.  Tokens are removed =
equal to the size in bits of the metered-packet, to a minimum =
Tetm=3D0.  If the token bucket is empty (Tetm =3D 0), then the =
meter indicates to the marking function that the packet is to be =
excess-traffic-marked. (Explanation of abbreviations: T is short for =
Tokens, BS for bucket size, and etm for =
excess-traffic-meter.)
 
&=
quot;Packet size independent marking" means that the size of the =
packet does not influence the decision about whether the meter indicates =
to the marking function that the packet is to be =
excess-traffic-marked.
 

 

I also think it best to = update Appendix A.2 so that it uses "packet size independent = marking”:-

   The following steps are performed when a PCN-packet =
arrives on a
   =
link:
 
   =
o  Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * =
PCN-excess-rate); //
      =
add tokens to token =
bucket
 
   =
o  if (packet_mark !=3D excess-traffic-marked) then // do not =
meter
      packets that =
are already =
excess-traffic-marked
 
&n=
bsp;  =
o
 
   &nbs=
p;  *  if (Tetm < 0) then packet_mark =3D =
excess-traffic-marked; // =
do
         =
excess-traffic-marking.  The algorithm ensures this =
is
         =
independent of packet =
size
 
   &=
nbsp;  *  else Tetm =3D Tetm - packet_size; // remove tokens =
from =
token
       &nbs=
p; bucket if don't mark =
packet
 
   =
o  lastUpdate =3D now // Note: 'now' has the same value as in step =
1

 

 

Also tweaked Appendix B.6:

   "Packet size independent marking" - =
excess-traffic-marking that is independent of packet size - is specified =
as a SHOULD in Section 2.4. With the “baseline” =
excess-traffic-meter behaviour, large packets are more likely to be =
excess-traffic-marked than small packets, because packets are marked if =
the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a =
small modification of the “baseline” excess-traffic-meter: =
the number of tokens in the bucket can become negative; if this number =
is negative at a packet's arrival, the packet is marked; otherwise, the =
amount of tokens equal to the packet size is removed from the bucket. =

 

"Packet size independent marking" is a 'SHOULD', rather =
than a 'MUST', because it may be slightly harder for some equipment to =
implement, and the impact of not doing it is undesirable but moderate =
(sufficient traffic is terminated, but flows with large packets are more =
likely to be terminated).  =

 
Thanks, =

phil
------_=_NextPart_001_01C9F4C8.3403F7DC-- From philip.eardley@bt.com Wed Jun 24 06:26:09 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7B33A6C71 for ; Wed, 24 Jun 2009 06:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_35=0.6, 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 31wKvaNvRRZi for ; Wed, 24 Jun 2009 06:26: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 633813A6B14 for ; Wed, 24 Jun 2009 06:26:04 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 12:41:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 12:41:36 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0A@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A41EB36.5010003@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Proposed Mod to draft-pcn-marking-behaviour Thread-Index: Acn0qkEMbr4krEH0Q2OzbPDuiLj5aAAFgJig From: To: , , X-OriginalArrivalTime: 24 Jun 2009 11:41:37.0055 (UTC) FILETIME=[BB5492F0:01C9F4C0] Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 13:26:10 -0000 Note that the doc is structured so that normative text is in the main body, and informative explanations are in the Appendix (your words include both) Will alter the abbreviation for the nu,ber of tokens in the bucket from T to F. Also Toby suggested changing in abbreviations from etm to _etm - so for instance instead of Tetm it will now say F_etm. { -----Original Message----- { From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] { Sent: 24 June 2009 10:01 { To: Eardley,PL,Philip,CXR9 R; pcn; Moncaster,T,Toby,CXR9 R { Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour {=20 { Hi Phil, hi Toby, {=20 { I still find the text somewhat hard to read and reformulated it a bit { without changing its contents. Also the cryptic variables make the text { hard to read. Moreover, I believe the following version clearly says { what excess marking is and that it is a must, but PSIM is a preferred { option but is only a SHOULD. {=20 { A PCN-node MUST implement an excess-traffic-meter and marker. This { algorithm has a reference rate which indicates the PCN packet rate that { can remain unmarked after passing this function. Various implementations { are possible. { * A simple implementation uses a token bucket [here we need a reference] { with bucket size S (bits) and reference rate R (bits/sec). Its current { fill state is denoted by F (bits). The bucket is continuously filled { with tokens at rate R, and passing packets remove the amount of tokens { equal to their size from the current fill state F. If F is smaller than { the packet size B (F { > I've been editing in the various comments on { > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03 { > { > In Section 2.4, both Michael and Ingemar said they found talk of MTU { > obscure, so have been working on phrasing this better. { > { > However I also realised another issue - S2.4 says:- { > { > A PCN-node MUST implement an excess-traffic-meter that has behaviour { > functionally equivalent to the following. { > { > [description of 'base' excess-traffic-meter] { > { > In addition to the above, ... the meter SHOULD [do] ... packet size { independent marking { > { > What this says, now I read it properly, is that you MUST implement { > 'base' marking behaviour AND also you SHOULD implement "packet size { > independent marking". { > { > Whereas what I think we actually wanted to say was: you MUST implement { > some kind of excess-traffic-marking behaviour, either the 'base' { > marking behaviour or "packet size independent marking" - the latter is { > suggested ie you SHOULD implement "packet size independent marking" { > and if you do, then you don't have to implement the 'base' marking { > behaviour as well. I checked with michael and toby and this is their { > understanding as well. { > { > If this isn't your understanding, then please shout now! I'm trying to { > get a new version out COP tomorrow Thursday, taking account of all the { > comments on -03, including the ietf last call ones. Thanks. { > { > Assuming this is ok, I'm proposing the following wording, which also { > gets rid of the obscure talk about MTU. { > { > S2.4 now reads:- { > { > ... A PCN-node MUST implement an excess-traffic-meter. The excess- { traffic-meter SHOULD indicate excess-traffic-marking independent of packet { size ("packet size independent marking") but otherwise MUST use the { "baseline" metering behaviour. { > { > The "baseline" excess-traffic-meter has behaviour functionally { equivalent to the following. { > { > The meter acts like a token bucket, which is sized in bits and has a { configured reference rate. The amount of tokens in the token bucket is { termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to { a maximum value BSetm. Tokens are removed equal to the size in bits of { the metered-packet, to a minimum Tetm=3D0. If the token bucket is = empty { (Tetm =3D 0), then the meter indicates to the marking function that = the { packet is to be excess-traffic-marked. (Explanation of abbreviations: T is { short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) { > { > "Packet size independent marking" means that the size of the packet does { not influence the decision about whether the meter indicates to the { marking function that the packet is to be excess-traffic-marked. { > { > { > I also think it best to update Appendix A.2 so that it uses "packet { > size independent marking":- { > { > The following steps are performed when a PCN-packet arrives on a { > link: { > { > o Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); // { > add tokens to token bucket { > { > o if (packet_mark !=3D excess-traffic-marked) then // do not = meter { > packets that are already excess-traffic-marked { > { > o { > { > * if (Tetm < 0) then packet_mark =3D excess-traffic-marked; = // do { > excess-traffic-marking. The algorithm ensures this is { > independent of packet size { > { > * else Tetm =3D Tetm - packet_size; // remove tokens from = token { > bucket if don't mark packet { > { > o lastUpdate =3D now // Note: 'now' has the same value as in = step 1 { > { > Also tweaked Appendix B.6: { > { > "Packet size independent marking" - excess-traffic-marking that is { independent of packet size - is specified as a SHOULD in Section 2.4. With { the "baseline" excess-traffic-meter behaviour, large packets are more { likely to be excess-traffic-marked than small packets, because packets are { marked if the number of tokens in the packet is smaller than the packet { size. 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] [Menth09]. It can be achieved by a small { modification of the "baseline" excess-traffic-meter: the number of tokens { in the bucket can become negative; if this number is negative at a { packet's arrival, the packet is marked; otherwise, the amount of tokens { equal to the packet size is removed from the bucket. { > { > "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', { because it may be slightly harder for some equipment to implement, and the { impact of not doing it is undesirable but moderate (sufficient traffic is { terminated, but flows with large packets are more likely to be terminated). { > { > Thanks, { > phil { > ------------------------------------------------------------------------ { > { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { > {=20 { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn From philip.eardley@bt.com Wed Jun 24 06:26:22 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57EA13A6C71 for ; Wed, 24 Jun 2009 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, 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 ktcK2PGi-liG for ; Wed, 24 Jun 2009 06:26:10 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 53B523A6C4E for ; Wed, 24 Jun 2009 06:26:05 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 12:57:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F4C3.025ADD8A" Date: Wed, 24 Jun 2009 12:57:55 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Proposed Mod to draft-pcn-marking-behaviour Thread-Index: Acn0pPK4axVi3hVSTkSpkt5XAxsb8QAA17RwAAJ3t7A= From: To: , X-OriginalArrivalTime: 24 Jun 2009 11:57:55.0821 (UTC) FILETIME=[02B869D0:01C9F4C3] Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 13:26:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F4C3.025ADD8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. how about this? <> 2. ok, so a fuller description of "packet size independent marking" needs to be in the main body:- =20 For "packet size independent marking" the excess-traffic-meter has behaviour functionally equivalent to the following. =20 The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed F_etm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BS_etm. If the token bucket is negative (F_etm < 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. If the token bucket is not negative, then tokens are removed equal to the size in bits of the metered-packet (and the meter does not indicate to the marking function that the packet is to be excess-traffic-marked). (Explanation of abbreviations: F is short for Fill of the token bucket, BS for bucket size, and etm for excess-traffic-meter.) =20 =20 =20 -----Original Message----- From: Moncaster,T,Toby,CXR9 R=20 Sent: 24 June 2009 09:58 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour =20 I /think/ your new text still says you MUST implement baseline and SHOULD implement PSIM as well... =20 Suggested alternative text (though this is remarkably tricky to phrase clearly!). You also need to put the description of PSIM into the main body as this is the recommended action...: =20 A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter MUST be functionally equivalent to one of the meters described below, "Baseline" or "packet size independent marking", and SHOULD be the "packet-size independent marking" meter. To be clear, the "baseline" meter is easier to implement but it also unduly favours flows with small packets. Hence we recommend the use of the "packet-size independent marking" meter. =20 Toby =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 24 June 2009 09:23 To: pcn@ietf.org Subject: [PCN] Proposed Mod to draft-pcn-marking-behaviour =20 I've been editing in the various comments on http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03=20 In Section 2.4, both Michael and Ingemar said they found talk of MTU obscure, so have been working on phrasing this better. However I also realised another issue - S2.4 says:- =20 A PCN-node MUST implement an excess-traffic-meter that has behaviour functionally equivalent to the following. [description of 'base' excess-traffic-meter] In addition to the above, ... the meter SHOULD [do] ... packet size independent marking =20 What this says, now I read it properly, is that you MUST implement 'base' marking behaviour AND also you SHOULD implement "packet size independent marking". =20 Whereas what I think we actually wanted to say was: you MUST implement some kind of excess-traffic-marking behaviour, either the 'base' marking behaviour or "packet size independent marking" - the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you don't have to implement the 'base' marking behaviour as well. I checked with michael and toby and this is their understanding as well. =20 If this isn't your understanding, then please shout now! I'm trying to get a new version out COP tomorrow Thursday, taking account of all the comments on -03, including the ietf last call ones. Thanks. =20 =20 =20 Assuming this is ok, I'm proposing the following wording, which also gets rid of the obscure talk about MTU. =20 S2.4 now reads:- ... A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the "baseline" metering behaviour. =20 The "baseline" excess-traffic-meter has behaviour functionally equivalent to the following. =20 The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=3D0. If the token bucket is empty (Tetm =3D 0), then the meter indicates to the marking function = that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) =20 "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked. =20 =20 I also think it best to update Appendix A.2 so that it uses "packet size independent marking":- The following steps are performed when a PCN-packet arrives on a link: =20 o Tetm =3D min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); = // add tokens to token bucket =20 o if (packet_mark !=3D excess-traffic-marked) then // do not meter packets that are already excess-traffic-marked =20 o =20 * if (Tetm < 0) then packet_mark =3D excess-traffic-marked; // do excess-traffic-marking. The algorithm ensures this is independent of packet size =20 * else Tetm =3D Tetm - packet_size; // remove tokens from token bucket if don't mark packet =20 o lastUpdate =3D now // Note: 'now' has the same value as in step 1 =20 =20 Also tweaked Appendix B.6: "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the "baseline" excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a small modification of the "baseline" excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket.=20 =20 "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). =20 =20 Thanks,=20 phil ------_=_NextPart_001_01C9F4C3.025ADD8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
  1. how about this? <<PCN-node MUST = implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet = size independent marking"); if "packet size independent = marking" is not implemented then the excess-traffic-meter MUST use the “baseline” metering = behaviour.>>
  2. ok, so a fuller description of = "packet size independent marking" needs to be in the main = body:-

 

For "packet size independent =
marking" the excess-traffic-meter has behaviour functionally =
equivalent to the following.
 
The meter =
acts like a token bucket, which is sized in bits and has a configured =
reference rate.  The amount of tokens in the token bucket is termed =
F_etm.  Tokens are added at the reference rate (PCN-excess-rate), =
to a maximum value BS_etm. If the token bucket is negative (F_etm =
< 0), then the meter indicates to the marking function that the =
packet is to be excess-traffic-marked. If the token bucket is not =
negative, then tokens are removed equal to the size in bits of the =
metered-packet (and the meter does not indicate to the marking function =
that the packet is to be excess-traffic-marked).  (Explanation of =
abbreviations: F is short for Fill of the token bucket, BS for bucket =
size, and etm for excess-traffic-meter.)
 
 

 

-----Original Message-----
From: = Moncaster,T,Toby,CXR9 R
Sent: 24 June 2009 = 09:58
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] = Proposed Mod to draft-pcn-marking-behaviour

 

I /think/ your new text still says = you MUST implement baseline and SHOULD implement PSIM as = well...

 

Suggested alternative text (though = this is remarkably tricky to phrase clearly!). You also need to put the = description of PSIM into the main body as this is the recommended = action…:

 

A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter MUST be functionally equivalent to one of the = meters described below, “Baseline” or “packet size = independent marking”, and SHOULD be the “packet-size independent = marking” meter. To be clear, the “baseline” meter is easier to = implement but it also unduly favours flows with small packets. Hence we recommend the = use of the “packet-size independent marking” = meter.

 

Toby

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 24 June 2009 09:23
To: pcn@ietf.org
Subject: [PCN] Proposed = Mod to draft-pcn-marking-behaviour

 

I’ve been editing in the various = comments on h= ttp://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03

In Section 2.4, both Michael and Ingemar said = they found talk of MTU obscure, so have been working on phrasing this = better.

However I also realised another issue – = S2.4 says:-

 

   A PCN-node MUST implement an =
excess-traffic-meter that has behaviour
   functionally equivalent to the =
following.

[description of ‘base’ excess-traffic-meter]

   In addition to the above, ... =
the meter SHOULD [do] ... packet size independent =
marking

 

What this says, now I read it properly, is = that you MUST implement ‘base’ marking behaviour AND also you SHOULD = implement "packet size independent marking".

 

Whereas what I think we actually wanted to = say was: you MUST implement some kind of excess-traffic-marking behaviour, either = the ‘base’ marking behaviour or "packet size independent marking" – the latter is suggested ie you SHOULD implement "packet size independent marking" and if you do, then you = don’t have to implement the ‘base’ marking behaviour as well. I = checked with michael and toby and this is their understanding as = well.

 

If this isn’t your understanding, then = please shout now! I’m trying to get a new version out COP tomorrow = Thursday, taking account of all the comments on -03, including the ietf last call = ones. Thanks.

 

 

 

Assuming this is ok, I’m proposing the = following wording, which also gets rid of the obscure talk about = MTU.

 

S2.4 now reads:-

...   A PCN-node MUST implement an =
excess-traffic-meter. The excess-traffic-meter SHOULD indicate =
excess-traffic-marking independent of packet size ("packet size =
independent marking") but otherwise MUST use the =
“baseline” metering behaviour.
       &nbs=
p;       
The =
“baseline” excess-traffic-meter has behaviour functionally =
equivalent to the following.
 
   The meter acts like a token =
bucket, which is sized in bits and has a configured reference =
rate.  The amount of tokens in the token bucket is termed =
Tetm.  Tokens are added at the reference rate (PCN-excess-rate), to =
a maximum value BSetm.  Tokens are removed equal to the size in =
bits of the metered-packet, to a minimum Tetm=3D0.  If the token =
bucket is empty (Tetm =3D 0), then the meter indicates to the marking =
function that the packet is to be excess-traffic-marked. (Explanation of =
abbreviations: T is short for Tokens, BS for bucket size, and etm for =
excess-traffic-meter.)
 
"Packet size independent marking" =
means that the size of the packet does not influence the decision about =
whether the meter indicates to the marking function that the packet is =
to be excess-traffic-marked.
 

 

I also think it best to update Appendix A.2 = so that it uses "packet size independent marking”:-

   The following steps are =
performed when a PCN-packet arrives on a
   =
link:
 
   o  Tetm =3D min(BSetm, Tetm =
+ (now - lastUpdate) * PCN-excess-rate); =
//
      add tokens to =
token bucket
 
   o  if (packet_mark !=3D =
excess-traffic-marked) then // do not =
meter
      packets that =
are already excess-traffic-marked
 
   o
 
      *  if =
(Tetm < 0) then packet_mark =3D excess-traffic-marked; // =
do
       &nbs=
p; excess-traffic-marking.  The algorithm ensures this =
is
       &nbs=
p; independent of packet size
 
      *  else =
Tetm =3D Tetm - packet_size; // remove tokens from =
token
       &nbs=
p; bucket if don't mark packet
 
   o  lastUpdate =3D now // =
Note: 'now' has the same value as in step 1

 

 

Also tweaked Appendix B.6:

   "Packet size independent =
marking" - excess-traffic-marking that is independent of packet =
size - is specified as a SHOULD in Section 2.4. With the =
“baseline” excess-traffic-meter behaviour, large packets are =
more likely to be excess-traffic-marked than small packets, because =
packets are marked if the number of tokens in the packet is smaller than =
the packet size. 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] [Menth09]. It can be achieved =
by a small modification of the “baseline” =
excess-traffic-meter: the number of tokens in the bucket can become =
negative; if this number is negative at a packet's arrival, the packet =
is marked; otherwise, the amount of tokens equal to the packet size is =
removed from the bucket.

 

"Packet size independent marking" =
is a 'SHOULD', rather than a 'MUST', because it may be slightly harder =
for some equipment to implement, and the impact of not doing it is =
undesirable but moderate (sufficient traffic is terminated, but flows =
with large packets are more likely to be terminated).  =

 
Thanks, =

phil
=00 ------_=_NextPart_001_01C9F4C3.025ADD8A-- From menth@informatik.uni-wuerzburg.de Wed Jun 24 11:03:24 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8843A6BE3 for ; Wed, 24 Jun 2009 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6, 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 T0xR0v17El9q for ; Wed, 24 Jun 2009 11:03:23 -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 B585F3A6819 for ; Wed, 24 Jun 2009 11:03:22 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C6A341990E2; Wed, 24 Jun 2009 17:19:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B8B27199138; Wed, 24 Jun 2009 17:19:35 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 9451F1990DF; Wed, 24 Jun 2009 17:19:35 +0200 (CEST) Message-ID: <4A424408.3040001@informatik.uni-wuerzburg.de> Date: Wed, 24 Jun 2009 17:19:36 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 18:03:24 -0000 Him philip.eardley@bt.com schrieb: > > 1. how about this? < excess-traffic-meter. The excess-traffic-meter SHOULD indicate > excess-traffic-marking independent of packet size ("packet size > independent marking"); > indicate packets to be marked by the marker independent of their size. > 1. if "packet size independent marking" is not implemented then the > excess-traffic-meter MUST use the “baseline” metering behaviour.>> > I would not term the normal token bucket "baseline" metering behavior for two reasons: 1) this sounds like the preferred mechanism 2) the nomenclature clashes with baseline encoding Regards, Michael > 1. ok, so a fuller description of "packet size independent marking" > needs to be in the main body:- > > For "packet size independent marking" the excess-traffic-meter has behaviour functionally equivalent to the following. > > The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed F_etm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BS_etm. If the token bucket is negative (F_etm < 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. If the token bucket is not negative, then tokens are removed equal to the size in bits of the metered-packet (and the meter does not indicate to the marking function that the packet is to be excess-traffic-marked). (Explanation of abbreviations: F is short for Fill of the token bucket, BS for bucket size, and etm for excess-traffic-meter.) > > > > -----Original Message----- > *From:* Moncaster,T,Toby,CXR9 R > *Sent:* 24 June 2009 09:58 > *To:* Eardley,PL,Philip,CXR9 R; pcn@ietf.org > *Subject:* RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour > > I /think/ your new text still says you MUST implement baseline and > SHOULD implement PSIM as well... > > Suggested alternative text (though this is remarkably tricky to phrase > clearly!). You also need to put the description of PSIM into the main > body as this is the recommended action…: > > A PCN-node MUST implement an excess-traffic-meter. The > excess-traffic-meter MUST be functionally equivalent to one of the > meters described below, “Baseline” or “packet size independent > marking”, and SHOULD be the “packet-size independent marking” meter. > To be clear, the “baseline” meter is easier to implement but it also > unduly favours flows with small packets. Hence we recommend the use of > the “packet-size independent marking” meter. > > Toby > > *From:* pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] *On Behalf > Of *philip.eardley@bt.com > *Sent:* 24 June 2009 09:23 > *To:* pcn@ietf.org > *Subject:* [PCN] Proposed Mod to draft-pcn-marking-behaviour > > I’ve been editing in the various comments on > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03 > > In Section 2.4, both Michael and Ingemar said they found talk of MTU > obscure, so have been working on phrasing this better. > > However I also realised another issue – S2.4 says:- > > A PCN-node MUST implement an excess-traffic-meter that has behaviour > functionally equivalent to the following. > > [description of ‘base’ excess-traffic-meter] > > In addition to the above, ... the meter SHOULD [do] ... packet size independent marking > > What this says, now I read it properly, is that you MUST implement > ‘base’ marking behaviour AND also you SHOULD implement "packet size > independent marking". > > Whereas what I think we actually wanted to say was: you MUST implement > some kind of excess-traffic-marking behaviour, either the ‘base’ > marking behaviour or "packet size independent marking" – the latter is > suggested ie you SHOULD implement "packet size independent marking" > and if you do, then you don’t have to implement the ‘base’ marking > behaviour as well. I checked with michael and toby and this is their > understanding as well. > > If this isn’t your understanding, then please shout now! I’m trying to > get a new version out COP tomorrow Thursday, taking account of all the > comments on -03, including the ietf last call ones. Thanks. > > Assuming this is ok, I’m proposing the following wording, which also > gets rid of the obscure talk about MTU. > > S2.4 now reads:- > > ... A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate excess-traffic-marking independent of packet size ("packet size independent marking") but otherwise MUST use the “baseline” metering behaviour. > > The “baseline” excess-traffic-meter has behaviour functionally equivalent to the following. > > The meter acts like a token bucket, which is sized in bits and has a configured reference rate. The amount of tokens in the token bucket is termed Tetm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=0. If the token bucket is empty (Tetm = 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.) > > "Packet size independent marking" means that the size of the packet does not influence the decision about whether the meter indicates to the marking function that the packet is to be excess-traffic-marked. > > > I also think it best to update Appendix A.2 so that it uses "packet > size independent marking”:- > > The following steps are performed when a PCN-packet arrives on a > link: > > o Tetm = min(BSetm, Tetm + (now - lastUpdate) * PCN-excess-rate); // > add tokens to token bucket > > o if (packet_mark != excess-traffic-marked) then // do not meter > packets that are already excess-traffic-marked > > o > > * if (Tetm < 0) then packet_mark = excess-traffic-marked; // do > excess-traffic-marking. The algorithm ensures this is > independent of packet size > > * else Tetm = Tetm - packet_size; // remove tokens from token > bucket if don't mark packet > > o lastUpdate = now // Note: 'now' has the same value as in step 1 > > Also tweaked Appendix B.6: > > "Packet size independent marking" - excess-traffic-marking that is independent of packet size - is specified as a SHOULD in Section 2.4. With the “baseline” excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets, because packets are marked if the number of tokens in the packet is smaller than the packet size. 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] [Menth09]. It can be achieved by a small modification of the “baseline” excess-traffic-meter: the number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket. > > "Packet size independent marking" is a 'SHOULD', rather than a 'MUST', because it may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). > > Thanks, > phil > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From karagian@cs.utwente.nl Thu Jun 25 06:52:49 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648F028C1AA for ; Thu, 25 Jun 2009 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.296 X-Spam-Level: * X-Spam-Status: No, score=1.296 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_35=0.6, 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 WlU6piOjNurS for ; Thu, 25 Jun 2009 06:52: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 76CEC28C151 for ; Thu, 25 Jun 2009 06:52:47 -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 n5PDYwbi023045; Thu, 25 Jun 2009 15:35:01 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D0B@E03MVB1-UKBR.domain1.systemhost.net> <4A424408.3040001@informatik.uni-wuerzburg.de> Date: Thu, 25 Jun 2009 15:34:53 +0200 Message-ID: <002801c9f599$bbd79900$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acn09iNpilzMlvVUROaGRAcKrkEV0AAo2C2g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A424408.3040001@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]); Thu, 25 Jun 2009 15:35:02 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 13:52:49 -0000 Hi all I think that Michael is right! Please rephrase the text accordingly! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: woensdag 24 juni 2009 17:20 > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Proposed Mod to draft-pcn-marking-behaviour > > Him > > philip.eardley@bt.com schrieb: > > > > 1. how about this? < > excess-traffic-meter. The excess-traffic-meter SHOULD indicate > > excess-traffic-marking independent of packet size > ("packet size > > independent marking"); > > > indicate packets to be marked by the marker independent of their size. > > > > 1. if "packet size independent marking" is not > implemented then the > > excess-traffic-meter MUST use the "baseline" metering > > behaviour.>> > > > I would not term the normal token bucket "baseline" metering > behavior for two reasons: > 1) this sounds like the preferred mechanism > 2) the nomenclature clashes with baseline encoding > > Regards, > > Michael > > > 1. ok, so a fuller description of "packet size > independent marking" > > needs to be in the main body:- > > > > For "packet size independent marking" the > excess-traffic-meter has behaviour functionally equivalent to > the following. > > > > The meter acts like a token bucket, which is sized in bits > and has a > > configured reference rate. The amount of tokens in the > token bucket > > is termed F_etm. Tokens are added at the reference rate > > (PCN-excess-rate), to a maximum value BS_etm. If the token > bucket is > > negative (F_etm < 0), then the meter indicates to the > marking function > > that the packet is to be excess-traffic-marked. If the > token bucket is > > not negative, then tokens are removed equal to the size in > bits of the > > metered-packet (and the meter does not indicate to the marking > > function that the packet is to be excess-traffic-marked). > > (Explanation of abbreviations: F is short for Fill of the token > > bucket, BS for bucket size, and etm for excess-traffic-meter.) > > > > > > > > -----Original Message----- > > *From:* Moncaster,T,Toby,CXR9 R > > *Sent:* 24 June 2009 09:58 > > *To:* Eardley,PL,Philip,CXR9 R; pcn@ietf.org > > *Subject:* RE: [PCN] Proposed Mod to draft-pcn-marking-behaviour > > > > I /think/ your new text still says you MUST implement baseline and > > SHOULD implement PSIM as well... > > > > Suggested alternative text (though this is remarkably > tricky to phrase > > clearly!). You also need to put the description of PSIM > into the main > > body as this is the recommended action.: > > > > A PCN-node MUST implement an excess-traffic-meter. The > > excess-traffic-meter MUST be functionally equivalent to one of the > > meters described below, "Baseline" or "packet size independent > > marking", and SHOULD be the "packet-size independent marking" meter. > > To be clear, the "baseline" meter is easier to implement > but it also > > unduly favours flows with small packets. Hence we recommend > the use of > > the "packet-size independent marking" meter. > > > > Toby > > > > *From:* pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > *On Behalf > > Of *philip.eardley@bt.com > > *Sent:* 24 June 2009 09:23 > > *To:* pcn@ietf.org > > *Subject:* [PCN] Proposed Mod to draft-pcn-marking-behaviour > > > > I've been editing in the various comments on > > http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-03 > > > > In Section 2.4, both Michael and Ingemar said they found > talk of MTU > > obscure, so have been working on phrasing this better. > > > > However I also realised another issue - S2.4 says:- > > > > A PCN-node MUST implement an excess-traffic-meter that > has behaviour > > functionally equivalent to the following. > > > > [description of 'base' excess-traffic-meter] > > > > In addition to the above, ... the meter SHOULD [do] ... > packet size > > independent marking > > > > What this says, now I read it properly, is that you MUST implement > > 'base' marking behaviour AND also you SHOULD implement "packet size > > independent marking". > > > > Whereas what I think we actually wanted to say was: you > MUST implement > > some kind of excess-traffic-marking behaviour, either the 'base' > > marking behaviour or "packet size independent marking" - > the latter is > > suggested ie you SHOULD implement "packet size independent marking" > > and if you do, then you don't have to implement the 'base' marking > > behaviour as well. I checked with michael and toby and this > is their > > understanding as well. > > > > If this isn't your understanding, then please shout now! > I'm trying to > > get a new version out COP tomorrow Thursday, taking account > of all the > > comments on -03, including the ietf last call ones. Thanks. > > > > Assuming this is ok, I'm proposing the following wording, > which also > > gets rid of the obscure talk about MTU. > > > > S2.4 now reads:- > > > > ... A PCN-node MUST implement an excess-traffic-meter. > The excess-traffic-meter SHOULD indicate > excess-traffic-marking independent of packet size ("packet > size independent marking") but otherwise MUST use the > "baseline" metering behaviour. > > > > The "baseline" excess-traffic-meter has behaviour > functionally equivalent to the following. > > > > The meter acts like a token bucket, which is sized in > bits and has > > a configured reference rate. The amount of tokens in the > token bucket > > is termed Tetm. Tokens are added at the reference rate > > (PCN-excess-rate), to a maximum value BSetm. Tokens are > removed equal > > to the size in bits of the metered-packet, to a minimum Tetm=0. If > > the token bucket is empty (Tetm = 0), then the meter > indicates to the > > marking function that the packet is to be excess-traffic-marked. > > (Explanation of abbreviations: T is short for Tokens, BS for bucket > > size, and etm for excess-traffic-meter.) > > > > "Packet size independent marking" means that the size of > the packet does not influence the decision about whether the > meter indicates to the marking function that the packet is to > be excess-traffic-marked. > > > > > > I also think it best to update Appendix A.2 so that it uses "packet > > size independent marking":- > > > > The following steps are performed when a PCN-packet arrives on a > > link: > > > > o Tetm = min(BSetm, Tetm + (now - lastUpdate) * > PCN-excess-rate); // > > add tokens to token bucket > > > > o if (packet_mark != excess-traffic-marked) then // do not meter > > packets that are already excess-traffic-marked > > > > o > > > > * if (Tetm < 0) then packet_mark = > excess-traffic-marked; // do > > excess-traffic-marking. The algorithm ensures this is > > independent of packet size > > > > * else Tetm = Tetm - packet_size; // remove tokens from token > > bucket if don't mark packet > > > > o lastUpdate = now // Note: 'now' has the same value as > in step 1 > > > > Also tweaked Appendix B.6: > > > > "Packet size independent marking" - > excess-traffic-marking that is independent of packet size - > is specified as a SHOULD in Section 2.4. With the "baseline" > excess-traffic-meter behaviour, large packets are more likely > to be excess-traffic-marked than small packets, because > packets are marked if the number of tokens in the packet is > smaller than the packet size. 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] [Menth09]. It can be > achieved by a small modification of the "baseline" > excess-traffic-meter: the number of tokens in the bucket can > become negative; if this number is negative at a packet's > arrival, the packet is marked; otherwise, the amount of > tokens equal to the packet size is removed from the bucket. > > > > "Packet size independent marking" is a 'SHOULD', rather > than a 'MUST', because it may be slightly harder for some > equipment to implement, and the impact of not doing it is > undesirable but moderate (sufficient traffic is terminated, > but flows with large packets are more likely to be terminated). > > > > Thanks, > > phil > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From root@core3.amsl.com Thu Jun 25 08:30:02 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0B99B3A6C76; Thu, 25 Jun 2009 08: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: <20090625153002.0B99B3A6C76@core3.amsl.com> Date: Thu, 25 Jun 2009 08:30:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Metering and marking behaviour of PCN-nodes Author(s) : P. Eardley Filename : draft-ietf-pcn-marking-behaviour-04.txt Pages : 23 Date : 2009-06-25 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable, and robust fashion. This document specifies the two metering and marking behaviours of PCN-nodes. Threshold- metering and -marking marks all PCN-packets if the rate of PCN- traffic is greater than a configured rate ("PCN-threshold-rate"). Excess-traffic-metering and -marking marks a proportion of PCN- packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-marking-behaviour-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-25082640.I-D@ietf.org> --NextPart-- From philip.eardley@bt.com Thu Jun 25 08:39:30 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F2A3A6F37 for ; Thu, 25 Jun 2009 08:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=0.892, 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 QzMA2OtM27ph for ; Thu, 25 Jun 2009 08:39: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 42FC93A6DE7 for ; Thu, 25 Jun 2009 08:39:09 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 16:34:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 16:34:23 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7D28@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20090625153002.0B99B3A6C76@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-04.txt Thread-Index: Acn1qes82Bf+WeHOQq+NvgalEMqeogAADwNg From: To: X-OriginalArrivalTime: 25 Jun 2009 15:34:24.0368 (UTC) FILETIME=[6AE92700:01C9F5AA] Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:39:30 -0000 New version that deals with the comments on v3, including those during the IETF last call. 6.1. Changes to -04 from -03 Updates to take account of IETF last call comments, including a Gen- ART review from David Black, as follows: o re-phrased of S2.2 first bullet for clarity o S2.4 re-phrased, so that competing-non-PCN-packets that are metered are covered by the "SHOULD NOT be metered ..." text o S2.4 o "Packet size independent (excess-traffic-)marking": re-phrased the para in 2.4 for clarity; altered the algorithm in Appendix A so it does PSIM; clarified the explanation in Appendix B.6 in light of this. Clarified that if packet size independent marking (the SHOULD behaviour) is implemented, then the 'classic' marking doesn't have to be (ie it's only a MUST if PSIM isn't implemented). Also added info on 'functionally equivalent' behaviour for PSIM. o added Security Considerations, based on material from RFC5559 o other minor typos and clarifications { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Internet-Drafts@ietf.org { Sent: 25 June 2009 16:30 { To: i-d-announce@ietf.org { Cc: pcn@ietf.org { Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-04.txt {=20 { 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. {=20 {=20 { Title : Metering and marking behaviour of PCN-nodes { Author(s) : P. Eardley { Filename : draft-ietf-pcn-marking-behaviour-04.txt { Pages : 23 { Date : 2009-06-25 {=20 { The objective of Pre-Congestion Notification (PCN) is to protect the { quality of service (QoS) of inelastic flows within a Diffserv domain, { in a simple, scalable, and robust fashion. This document specifies { the two metering and marking behaviours of PCN-nodes. Threshold- { metering and -marking marks all PCN-packets if the rate of PCN- { traffic is greater than a configured rate ("PCN-threshold-rate"). { Excess-traffic-metering and -marking marks a proportion of PCN- { packets, such that the amount marked equals the rate of PCN-traffic { in excess of a configured rate ("PCN-excess-rate"). The level of { marking allows PCN-boundary-nodes to make decisions about whether to { admit or terminate PCN-flows. {=20 { A URL for this Internet-Draft is: { http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour- { 04.txt {=20 { Internet-Drafts are also available by anonymous FTP at: { ftp://ftp.ietf.org/internet-drafts/ {=20 { Below is the data which will enable a MIME compliant mail reader { implementation to automatically retrieve the ASCII version of the { Internet-Draft. From slblake@petri-meat.com Thu Jun 25 10:04:11 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780AA3A6DE4 for ; Thu, 25 Jun 2009 10:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV+ZIjdHKDUU for ; Thu, 25 Jun 2009 10:04:10 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 0A69628C13B for ; Thu, 25 Jun 2009 10:03:42 -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 1MJrEM-00069X-Jm; Thu, 25 Jun 2009 11:51:18 -0400 MIME-Version: 1.0 Date: Thu, 25 Jun 2009 11:51:18 -0400 From: To: philip.eardley@bt.com In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7D28@E03MVB1-UKBR.domain1.systemhost.net> References: <4A916DBC72536E419A0BD955EDECEDEC04AD7D28@E03MVB1-UKBR.domain1.systemhost.net> Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 17:04:11 -0000 On Thu, 25 Jun 2009 16:34:23 +0100, wrote: > New version that deals with the comments on v3, including those during > the IETF last call. > > 6.1. Changes to -04 from -03 > > Updates to take account of IETF last call comments, including a Gen- > ART review from David Black, as follows: > > o re-phrased of S2.2 first bullet for clarity > > o S2.4 re-phrased, so that competing-non-PCN-packets that are > metered are covered by the "SHOULD NOT be metered ..." text > > o S2.4 > > o "Packet size independent (excess-traffic-)marking": re-phrased the > para in 2.4 for clarity; altered the algorithm in Appendix A so it > does PSIM; clarified the explanation in Appendix B.6 in light of > this. Clarified that if packet size independent marking (the > SHOULD behaviour) is implemented, then the 'classic' marking > doesn't have to be (ie it's only a MUST if PSIM isn't > implemented). Also added info on 'functionally equivalent' > behaviour for PSIM. > > o added Security Considerations, based on material from RFC5559 > > o other minor typos and clarifications Diffs from -03 can be viewed at: http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-04 Regards, // Steve From menth@informatik.uni-wuerzburg.de Thu Jun 25 16:13:26 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C464A3A68C3 for ; Thu, 25 Jun 2009 16:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_05=-1.11, 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 JJQHQcFKvv11 for ; Thu, 25 Jun 2009 16:13:26 -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 D97003A6A03 for ; Thu, 25 Jun 2009 16:13:25 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E8DC0199186; Fri, 26 Jun 2009 00:39:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DAB02199181; Fri, 26 Jun 2009 00:39:17 +0200 (CEST) Received: from [132.187.246.46] (wvpn046.vpn.uni-wuerzburg.de [132.187.246.46]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A4F6D199176; Fri, 26 Jun 2009 00:39:17 +0200 (CEST) Message-ID: <4A43FC96.9040803@informatik.uni-wuerzburg.de> Date: Fri, 26 Jun 2009 00:39:18 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: "Dr. Daiasuke Satoh" Subject: [PCN] Problems with flow termination due to different RTTs X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:13:26 -0000 Hi all, Daisuke Satoh implemented the flow termination of CL and observed overtermination when IEAs within a PCN domain have different RTTs. We should be aware of his findings and possibly also give guidelines that help to avoid overtermination in such cases. I have described the problem in Section 4.3 of http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9b.pdf and proposed some workarounds trying to mitigate the overtermination. Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From tom.taylor@rogers.com Thu Jun 25 18:29:48 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14DC3A6845 for ; Thu, 25 Jun 2009 18:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 UifdH1Xwd1LS for ; Thu, 25 Jun 2009 18:29:47 -0700 (PDT) Received: from smtp111.rog.mail.re2.yahoo.com (smtp111.rog.mail.re2.yahoo.com [206.190.37.1]) by core3.amsl.com (Postfix) with SMTP id 557303A6452 for ; Thu, 25 Jun 2009 18:29:47 -0700 (PDT) Received: (qmail 16927 invoked from network); 26 Jun 2009 01:16:20 -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=MtX4KA7g/bHbtS8G5mxcXy5lCGggEsHOsUEwgFwAG0yTAF7Jt+jnJqDyP3/3tXbcNsJi2KT4f2d0+3m1TffZZ0XN8jLGCRQ0LFSAu+x4GcvmUjKxeCzWFdg2EOXSelNolSgPrNJbu5nGCI/bRIJHOoHY2Iyc8UtXhJQxBhrruRM= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp111.rog.mail.re2.yahoo.com with SMTP; 26 Jun 2009 01:16:20 -0000 X-YMail-OSG: A38izsgVM1nCRm6IYSxHPYcLMJan_GPvybBvgHiSj3VzF_yHb0KKWCj.TMXmkEbEeQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A442164.6010903@rogers.com> Date: Thu, 25 Jun 2009 21:16:20 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <4A43FC96.9040803@informatik.uni-wuerzburg.de> In-Reply-To: <4A43FC96.9040803@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn , "Dr. Daiasuke Satoh" Subject: Re: [PCN] Problems with flow termination due to different RTTs X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 01:29:48 -0000 Possibly the statistical material I had in the original CL draft (removed by the time it was published) could have some relevance here. Indirectly the estimations discussed in that material were estimations of RTT for specific IEAs. I'll see if I can put something together that makes more sense to people than my last attempt. Michael Menth wrote: > Hi all, > > Daisuke Satoh implemented the flow termination of CL and observed > overtermination when IEAs within a PCN domain have different RTTs. We > should be aware of his findings and possibly also give guidelines that > help to avoid overtermination in such cases. I have described the > problem in Section 4.3 of > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9b.pdf > > and proposed some workarounds trying to mitigate the overtermination. > > Regards, > > Michael > From tom.taylor@rogers.com Sun Jun 28 16:21:34 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75C93A6CA4 for ; Sun, 28 Jun 2009 16:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVJLIPlMU4a4 for ; Sun, 28 Jun 2009 16:21:34 -0700 (PDT) Received: from smtp107.rog.mail.re2.yahoo.com (smtp107.rog.mail.re2.yahoo.com [68.142.225.205]) by core3.amsl.com (Postfix) with SMTP id E1ED23A6824 for ; Sun, 28 Jun 2009 16:21:33 -0700 (PDT) Received: (qmail 37711 invoked from network); 28 Jun 2009 23:21:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=OJCc2/d4+hYR8yublM7mlGOAg+CBcvru5kB+W7pa8xBQImywnUsJxpq7c1237/CE/bxZnvRjr/Xq8uORJ+p6zPBtAUN8xy4FcxKC3vOfIWvDtueG7K5pnd7R1E1EARQKqiVbNUA8r/45cZF7HdtieM8UWzCsxKJtMXahgM8/364= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp107.rog.mail.re2.yahoo.com with SMTP; 28 Jun 2009 23:21:51 -0000 X-YMail-OSG: rmTN.lIVM1n0om3Hn5G45xjB5PBVwXuxRGnB4Scrv.rzxo3KK.bI_18wkxxsqw6N0g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A47FB0F.1070807@rogers.com> Date: Sun, 28 Jun 2009 19:21:51 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] Defining per domain behaviour per RFC 3086 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 23:21:34 -0000 I was looking over RFC 3086 prior to assimilating its requirements into our edge behaviour drafts. At one point it mentions that remarking should not occur in the interior of a domain. More precisely, in the second paragraph of section 4.1.2 it says: "DSCPs should not change in the interior of a DS domain as there is no traffic conditioning being applied." I leave it to people more familiar with Diffserv rules to say whether this is a general rule in Diffserv. In our case, draft-ietf-pcn-3-state-encoding-00.txt mandates remarking when recording excess traffic marking. We clearly have a good reason to do the remarking, so I don't expect we have to worry about it. Editorially I suppose the PDB template should be a section similar to the IANA section. For quantitative analysis I guess we refer to published simulation results. Tom From Ruediger.Geib@telekom.de Sun Jun 28 23:55:56 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EC63A6D29 for ; Sun, 28 Jun 2009 23:55:56 -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 KMnPZDPJHXEB for ; Sun, 28 Jun 2009 23:55:55 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 8023A3A6A0A for ; Sun, 28 Jun 2009 23:55:53 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 29 Jun 2009 08:56:11 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 08:56:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 08:56:10 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5018345A1@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <4A47FB0F.1070807@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Defining per domain behaviour per RFC 3086 Thread-Index: Acn4RzwZKBxQtYziQhOibSIwzFmQTQAPsyMg References: <4A47FB0F.1070807@rogers.com> From: To: X-OriginalArrivalTime: 29 Jun 2009 06:56:11.0554 (UTC) FILETIME=[AFCD4020:01C9F886] Cc: pcn@ietf.org Subject: Re: [PCN] Defining per domain behaviour per RFC 3086 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 06:55:56 -0000 Tom, thorough work. Your statement might also apply to ECN for MPLS, where a=20 MPLS TC marking is changed within a domain.=20 Advice from chairs/ADs on how to handle this is probalby a good way to = proceed. Regards, Ruediger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Tom Taylor Sent: Monday, June 29, 2009 1:22 AM To: pcn Subject: [PCN] Defining per domain behaviour per RFC 3086 I was looking over RFC 3086 prior to assimilating its requirements into = our edge=20 behaviour drafts. At one point it mentions that remarking should not = occur in=20 the interior of a domain. More precisely, in the second paragraph of = section=20 4.1.2 it says: "DSCPs should not change in the interior of a DS domain as there is no traffic conditioning being applied." I leave it to people more familiar with Diffserv rules to say whether = this is a=20 general rule in Diffserv. In our case, = draft-ietf-pcn-3-state-encoding-00.txt=20 mandates remarking when recording excess traffic marking. We clearly = have a good=20 reason to do the remarking, so I don't expect we have to worry about it. Editorially I suppose the PDB template should be a section similar to = the IANA=20 section. For quantitative analysis I guess we refer to published = simulation results. Tom _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From toby.moncaster@bt.com Mon Jun 29 01:22:59 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBD528C1A0 for ; Mon, 29 Jun 2009 01:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.645, 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 nKQ6XxXjYD6X for ; Mon, 29 Jun 2009 01:22:58 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 8EE6828C19D for ; Mon, 29 Jun 2009 01:22:58 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 09:23:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 09:23:17 +0100 Message-ID: In-Reply-To: <151C164FE2E066418D8D44D0801543A5018345A1@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Defining per domain behaviour per RFC 3086 Thread-Index: Acn4RzwZKBxQtYziQhOibSIwzFmQTQAPsyMgAAMqMIA= References: <4A47FB0F.1070807@rogers.com> <151C164FE2E066418D8D44D0801543A5018345A1@S4DE8PSAAQA.mitte.t-com.de> From: To: , X-OriginalArrivalTime: 29 Jun 2009 08:23:17.0579 (UTC) FILETIME=[DAC161B0:01C9F892] Cc: pcn@ietf.org Subject: Re: [PCN] Defining per domain behaviour per RFC 3086 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:22:59 -0000 If this does apply I would make the argument that the change (which = occurs when we start to indicate termination marking) is tantamount to = traffic conditioning, in that as a result of the change some traffic is = going to subsequently get terminated... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Ruediger.Geib@telekom.de > Sent: 29 June 2009 07:56 > To: tom.taylor@rogers.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Defining per domain behaviour per RFC 3086 >=20 > Tom, >=20 > thorough work. Your statement might also apply to ECN for MPLS, where = a > MPLS TC marking is changed within a domain. >=20 > Advice from chairs/ADs on how to handle this is probalby a good way to > proceed. >=20 > Regards, >=20 > Ruediger >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Technik Internet Backbone, TE142-19 > R=FCdiger Geib > Heinrich Hertz Str. 3-7 > 64297 Darmstadt > Tel.: 06151/6282747 > Fax: 0251/7985109 >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus > Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 >=20 >=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Tom Taylor > Sent: Monday, June 29, 2009 1:22 AM > To: pcn > Subject: [PCN] Defining per domain behaviour per RFC 3086 >=20 > I was looking over RFC 3086 prior to assimilating its requirements = into > our edge > behaviour drafts. At one point it mentions that remarking should not > occur in > the interior of a domain. More precisely, in the second paragraph of > section > 4.1.2 it says: >=20 > "DSCPs should not change in the interior of a DS domain as there is no > traffic conditioning being applied." >=20 > I leave it to people more familiar with Diffserv rules to say whether > this is a > general rule in Diffserv. In our case, = draft-ietf-pcn-3-state-encoding- > 00.txt > mandates remarking when recording excess traffic marking. We clearly > have a good > reason to do the remarking, so I don't expect we have to worry about > it. >=20 > Editorially I suppose the PDB template should be a section similar to > the IANA > section. For quantitative analysis I guess we refer to published > simulation results. >=20 > Tom > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Mon Jun 29 05:37:47 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6FF28C256 for ; Mon, 29 Jun 2009 05:37:47 -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 PBxcxKMkZ256 for ; Mon, 29 Jun 2009 05:37:47 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 8BCB928C25A for ; Mon, 29 Jun 2009 05:37:45 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 29 Jun 2009 14:37:40 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 14:37:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 14:37:39 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501834DB5@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: Last Call: draft-ietf-ancp-framework (Framework andRequirements for an Access Node Control Mechanism inBroadband Multi-Service Networks) to Informational RFC Thread-Index: AcnuhaHT05Oa1OI/REOrSQuUmMtqzgKLmmWQ References: <20090615144524.CAF833A69D9@core3.amsl.com> From: To: X-OriginalArrivalTime: 29 Jun 2009 12:37:40.0369 (UTC) FILETIME=[64165010:01C9F8B6] Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: Last Call: draft-ietf-ancp-framework (Framework andRequirements for an Access Node Control Mechanism inBroadband Multi-Service Networks) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 12:37:48 -0000 Lars, thanks for the hint. I read through the document. Leaving admission control decisions to an = Access Node (DSLAM) is an option discussed there. A PCN relation would = result, if the DSLAM is PCN aware on its interface towards the Broadband = Access Router. PCN makes sense on this interface, if the aggregated QoS = traffic received on this link requires to stop admission of new traffic. I don't think that this applies for the multicast admission control, the = document discusses, at least it doesn't if the DSLAM receives a = multicast signal from the BRAS (I think multicast is more of a traffic = engineering or network planning issue). The document mentions unicast admission control, but doesn't discuss = this in detail. In this context, some text about PCN functionalities = related to the interface beween DSLAM and aggregation network may be = useful. If we start this, we will pretty sure have to introduce PCN in = the Broadband Forum, as the BBF is the starting point of the ANCP work = if I understand correctly.=20 Did anybody else read the document and has an opinion? Regards, -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Lars Eggert Sent: Tuesday, June 16, 2009 3:23 PM To: pcn@ietf.org Subject: [PCN] Fwd: Last Call: draft-ietf-ancp-framework (Framework = andRequirements for an Access Node Control Mechanism inBroadband = Multi-Service Networks) to Informational RFC Hi, FYI, this document talks quite a bit about flow admission. I suspect =20 PCN folks would want to review it and send comments to the main IETF =20 list (reply-to set accordingly) during its last call. Lars Begin forwarded message: > From: The IESG > Date: June 15, 2009 17:45:24 GMT+03:00 > To: IETF-Announce > Cc: "ancp@ietf.org" > Subject: Last Call: draft-ietf-ancp-framework (Framework and =20 > Requirements for an Access Node Control Mechanism in Broadband =20 > Multi-Service Networks) to Informational RFC > Reply-To: "ietf@ietf.org" > > The IESG has received a request from the Access Node Control =20 > Protocol WG > (ancp) to consider the following document: > > - 'Framework and Requirements for an Access Node Control Mechanism in > Broadband Multi-Service Networks ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to =20 > the > ietf@ietf.org mailing lists by 2009-06-29. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-10.txt > > > IESG discussion can be tracked via > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D15270&rfc_flag=3D0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From tena@huawei.com Mon Jun 29 05:48:04 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F0428C27A for ; Mon, 29 Jun 2009 05:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.755 X-Spam-Level: X-Spam-Status: No, score=0.755 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_RECV_IP_219128=1.666] 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 cDJZ7LEahGiL for ; Mon, 29 Jun 2009 05:48:03 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7695628C276 for ; Mon, 29 Jun 2009 05:48:03 -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 <0KM000HVL3JIH3@szxga01-in.huawei.com> for pcn@ietf.org; Mon, 29 Jun 2009 20:47:42 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM000I303JI5A@szxga01-in.huawei.com> for pcn@ietf.org; Mon, 29 Jun 2009 20:47:42 +0800 (CST) Received: from [192.168.1.3] (120.217.133.219.broad.sz.gd.dynamic.163data.com.cn [219.133.217.120]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM000E383JBMN@szxml01-in.huawei.com>; Mon, 29 Jun 2009 20:47:37 +0800 (CST) Date: Mon, 29 Jun 2009 20:47:35 +0800 From: Tina TSOU In-reply-to: <151C164FE2E066418D8D44D0801543A501834DB5@S4DE8PSAAQA.mitte.t-com.de> To: Ruediger.Geib@telekom.de Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <20090615144524.CAF833A69D9@core3.amsl.com> <151C164FE2E066418D8D44D0801543A501834DB5@S4DE8PSAAQA.mitte.t-com.de> Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: Last Call: draft-ietf-ancp-framework (Framework andRequirements for an Access Node Control Mechanism inBroadband Multi-Service Networks) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 12:48:04 -0000 Hi, In that document, the multicast bandwidth admission control is performed in the Access Node, and the unicast bandwidth admission control is performed in the Policy Server. B. R. Tina http://tinatsou.weebly.com/contact.html On Jun 29, 2009, at 8:37 PM, Ruediger.Geib@telekom.de wrote: > Lars, > > thanks for the hint. > > I read through the document. Leaving admission control decisions to > an Access Node (DSLAM) is an option discussed there. A PCN relation > would result, if the DSLAM is PCN aware on its interface towards the > Broadband Access Router. PCN makes sense on this interface, if the > aggregated QoS traffic received on this link requires to stop > admission of new traffic. > > I don't think that this applies for the multicast admission control, > the document discusses, at least it doesn't if the DSLAM receives a > multicast signal from the BRAS (I think multicast is more of a > traffic engineering or network planning issue). > > The document mentions unicast admission control, but doesn't discuss > this in detail. In this context, some text about PCN functionalities > related to the interface beween DSLAM and aggregation network may be > useful. If we start this, we will pretty sure have to introduce PCN > in the Broadband Forum, as the BBF is the starting point of the ANCP > work if I understand correctly. > > Did anybody else read the document and has an opinion? > > Regards, > > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of Lars Eggert > Sent: Tuesday, June 16, 2009 3:23 PM > To: pcn@ietf.org > Subject: [PCN] Fwd: Last Call: draft-ietf-ancp-framework (Framework > andRequirements for an Access Node Control Mechanism inBroadband > Multi-Service Networks) to Informational RFC > > Hi, > > FYI, this document talks quite a bit about flow admission. I suspect > PCN folks would want to review it and send comments to the main IETF > list (reply-to set accordingly) during its last call. > > Lars > > Begin forwarded message: > >> From: The IESG >> Date: June 15, 2009 17:45:24 GMT+03:00 >> To: IETF-Announce >> Cc: "ancp@ietf.org" >> Subject: Last Call: draft-ietf-ancp-framework (Framework and >> Requirements for an Access Node Control Mechanism in Broadband >> Multi-Service Networks) to Informational RFC >> Reply-To: "ietf@ietf.org" >> >> The IESG has received a request from the Access Node Control >> Protocol WG >> (ancp) to consider the following document: >> >> - 'Framework and Requirements for an Access Node Control Mechanism in >> Broadband Multi-Service Networks ' >> as an Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the >> ietf@ietf.org mailing lists by 2009-06-29. Exceptionally, >> comments may be sent to iesg@ietf.org instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-10.txt >> >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15270&rfc_flag=0 >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From slblake@petri-meat.com Mon Jun 29 12:42:50 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8413A6DD6 for ; Mon, 29 Jun 2009 12:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9j+uNu-YTcnt for ; Mon, 29 Jun 2009 12:42:50 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 31E4D3A69C0 for ; Mon, 29 Jun 2009 12:42:50 -0700 (PDT) Received: from cpe-066-057-118-226.nc.res.rr.com ([66.57.118.226]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MLMks-0002rv-7V; Mon, 29 Jun 2009 15:43:06 -0400 From: Steven Blake To: Tom Taylor In-Reply-To: <4A47FB0F.1070807@rogers.com> References: <4A47FB0F.1070807@rogers.com> Content-Type: text/plain Date: Mon, 29 Jun 2009 15:43:08 -0400 Message-Id: <1246304588.2987.9.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn Subject: Re: [PCN] Defining per domain behaviour per RFC 3086 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:42:51 -0000 On Sun, 2009-06-28 at 19:21 -0400, Tom Taylor wrote: > I was looking over RFC 3086 prior to assimilating its requirements into our edge > behaviour drafts. At one point it mentions that remarking should not occur in > the interior of a domain. More precisely, in the second paragraph of section > 4.1.2 it says: > > "DSCPs should not change in the interior of a DS domain as there is no > traffic conditioning being applied." > > I leave it to people more familiar with Diffserv rules to say whether this is a > general rule in Diffserv. In our case, draft-ietf-pcn-3-state-encoding-00.txt > mandates remarking when recording excess traffic marking. We clearly have a good > reason to do the remarking, so I don't expect we have to worry about it. > > Editorially I suppose the PDB template should be a section similar to the IANA > section. For quantitative analysis I guess we refer to published simulation results. Don't worry about it. :) // Steve From tom.taylor@rogers.com Tue Jun 30 17:34:31 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DE83A6EF8 for ; Tue, 30 Jun 2009 17:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdrGYQeS3PxN for ; Tue, 30 Jun 2009 17:34:30 -0700 (PDT) Received: from smtp121.rog.mail.re2.yahoo.com (smtp121.rog.mail.re2.yahoo.com [206.190.53.26]) by core3.amsl.com (Postfix) with SMTP id 6381D3A65A5 for ; Tue, 30 Jun 2009 17:33:43 -0700 (PDT) Received: (qmail 60632 invoked from network); 1 Jul 2009 00:33:13 -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=wLY9nL+ca8khn89Z9V+YUOLpHyHc1mxk2qw/TUEyEHUmOOWLklhZgQ/XNKscJGvTlH0OfVvAcOR7k/jQyCE+4RMSj+yLRapfl6WMkT8uZT4rQd0Z12fFX15DvEZraL0K84ZdsWpodmqRiOLKKguI9JbxiKNLrEJ79Verj4B84mc= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp121.rog.mail.re2.yahoo.com with SMTP; 1 Jul 2009 00:33:13 -0000 X-YMail-OSG: H0sFVDAVM1m2R.X4IkuYYRSSekpWUFNtGuEJjTo_0eIGogiXwPl72yfWS_EjhWlL9g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4AAEC7.8060900@rogers.com> Date: Tue, 30 Jun 2009 20:33:11 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] Editorial note on baseline encoding document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 00:34:31 -0000 This is a quick editorial note which has been causing me some uncertainty. The last sentence of section 6 of draft-ietf-pcn-baseline-encoding-04 is a bit garbled. I'm assuming the sentence was begun then rebegun. Tom