From slblake@petri-meat.com Sat Aug 1 20:35: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 AE33E3A6767 for ; Sat, 1 Aug 2009 20:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 nRHFXYkALjVr for ; Sat, 1 Aug 2009 20:35:59 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 13C283A659C for ; Sat, 1 Aug 2009 20:35:58 -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 1MXRrb-0005o9-JH for pcn@ietf.org; Sat, 01 Aug 2009 23:35:59 -0400 MIME-Version: 1.0 Date: Sat, 01 Aug 2009 23:35:59 -0400 From: To: pcn@ietf.org Message-ID: <8376254de9eef3a0e2f2156e887a5b37@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] IETF 75 meeting draft minutes 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, 02 Aug 2009 03:35:59 -0000 I've uploaded the draft meeting minutes to: http://www.ietf.org/proceedings/75/minutes/pcn.txt Please review and send comments/corrections to the list. Thanks to Andrew for volunteering to be minute taker! Regards, // Steve From tom.taylor@rogers.com Sun Aug 2 04:52:21 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 3D6973A6BD5 for ; Sun, 2 Aug 2009 04:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 DgYuF47vYuxE for ; Sun, 2 Aug 2009 04:52:20 -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 4B6903A6885 for ; Sun, 2 Aug 2009 04:52:20 -0700 (PDT) Received: (qmail 60435 invoked from network); 2 Aug 2009 11:52: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=FROJQ3dD7itEuNceZhM7Q9YYNxaOFSG6uwVbDyo6mYigVDC+V0wQ7QwADcabVxLpHsBNk+jAGe6gU43Vlrq9aUPkRN1+wkdvL5PK1FzFgyDJRK+bp/PNqr1yk5A0ze7/1SIswkSJhxOSZH703uyaboC931wPD5nSe8TOBR9tONw= ; 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; 2 Aug 2009 11:52:20 -0000 X-YMail-OSG: gZj_pf4VM1mAJIdBsS9ABnK78g4iYrGpq5QGckinpIvhQMtT3Bup.z5BuqeObDI5vA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A757DF4.5010402@rogers.com> Date: Sun, 02 Aug 2009 07:52:20 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: slblake@petri-meat.com References: <8376254de9eef3a0e2f2156e887a5b37@petri-meat.com> In-Reply-To: <8376254de9eef3a0e2f2156e887a5b37@petri-meat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] IETF 75 meeting draft minutes 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, 02 Aug 2009 11:52:21 -0000 The minutes look good to me. slblake@petri-meat.com wrote: > I've uploaded the draft meeting minutes to: > http://www.ietf.org/proceedings/75/minutes/pcn.txt > > Please review and send comments/corrections to the list. Thanks to Andrew > for volunteering to be minute taker! > > > Regards, > > // Steve > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From root@core3.amsl.com Mon Aug 3 06: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 01B9F3A6DCC; Mon, 3 Aug 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090803133002.01B9F3A6DCC@core3.amsl.com> Date: Mon, 3 Aug 2009 06:30:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13: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-05.txt Pages : 25 Date : 2009-08-03 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 defines 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-marking-behaviour-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-03061732.I-D@ietf.org> --NextPart-- From lars.eggert@nokia.com Wed Aug 5 07:20:08 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 BEA1228C591 for ; Wed, 5 Aug 2009 07:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYhTWrp1YkiB for ; Wed, 5 Aug 2009 07:20:07 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 3EA8928C593 for ; Wed, 5 Aug 2009 07:19:33 -0700 (PDT) Received: from [192.168.0.198] (funet-wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n75EJJKN042794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 5 Aug 2009 17:19:19 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> From: Lars Eggert To: pcn@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-30-591814684; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 17:19:14 +0300 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]); Wed, 05 Aug 2009 17:19:19 +0300 (EEST) Subject: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 05 Aug 2009 14:20:08 -0000 --Apple-Mail-30-591814684 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, this document is ready, except for one issue: Section 7., paragraph 1: > This document makes no direct request to IANA. However this document > allows for a set of Diffserv Codepoints to be assigned different ECN > semantics within a controlled domain as described in [RFC4774]. A > list of such DSCPs will be maintained by the PCN working group. DISCUSS: This text isn't aligned with appendix A.1. The text here says "the WG will maintain a list of DSCPs that are OK", while the beginning of appendix A.1 says "the WG decided to not define with which DSCPs PCN can be used" (but then the end of A.1 talks about maintaining a list again.) Which is it? If there is to be a list, you need to create an IANA registry, write management procedures for it (see RFC5226) and populate it with some initial values. (WGs are ephemeral, which is why the PCN WG can't be the maintainer of this list, IANA has to be.) If you want to leave it fully open for deployments, you need to remove this confusion from the text. Lars Nits: Section 4., paragraph 3: > to prevent future compatability issues. Nit: s/compatability/compatibility/ Section 4.2., paragraph 1: > that is guaranteeed to be copied down into the inner header upon Nit: s/guaranteeed/guaranteed/ Section 6., paragraph 1: > always copy the CE codepoint from teh outer header into the inner Nit: s/teh/the/ Section 6., paragraph 2: > header in decapsulation (unless the inner packet is not-ECT). If an > operator it is essential that any operator wishing to allow ECN to > exist end-to-end ensures there are no tunnel end-points within the > PCN-domain. "If an operator it is essential that any operator..." - wording Section 12., paragraph 0: > 12. References Should be updated; see idnits report. Appendix A., paragraph 2: > a given PCN-domain is dependant on the nature of the traffic entering Nit: s/dependant/dependent/ --Apple-Mail-30-591814684 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDUxNDE5MTRaMCMGCSqGSIb3DQEJBDEWBBTv6kn+oNdSFnwp XoeAb5uTLduatDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAltj5Nm+ym/Ok7rUJfZQEt2WgsbWnp/g1+Zv1nREU6D/OWNKbb+uY 02nQ+iz0pz1BwReTDPjHOY65IGc0iMJJzXQMx1s56d/n3M2DTylkHbHjRKvCh1dJr86PYaUL1eH7 7n6HXO4CIE8R2A8qvft86zPkNj3E/44D+iYVtzjLFAcDWJCuLOsfQH0g/Gu95VuKeR4td4Q+WpxF L29icX3upH+hgPYG2aTd6QHzFjdceHV4Ze+6ac+vt3oiaZ0GHohrrmK9MuFl+og31rfwsDVvKW+g W1SBGBwB5mhxAKRCgjsxbyhWCbjhamYFpGB9JRTBUv+DFSnQjUJbx+Wxr46YrwAAAAAAAA== --Apple-Mail-30-591814684-- From lars.eggert@nokia.com Fri Aug 14 05:16:52 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 CE5313A68C5 for ; Fri, 14 Aug 2009 05:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 5njF-wamQ8r4 for ; Fri, 14 Aug 2009 05:16:47 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 1B86F3A68F7 for ; Fri, 14 Aug 2009 05:16:46 -0700 (PDT) Received: from [10.180.41.33] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7EBQijW067790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Aug 2009 14:27:20 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: pcn@ietf.org In-Reply-To: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> Content-Type: multipart/signed; boundary=Apple-Mail-53--788382507; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 14:27:20 +0300 References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [212.213.221.39]); Fri, 14 Aug 2009 14:27:20 +0300 (EEST) Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 14 Aug 2009 12:16:52 -0000 --Apple-Mail-53--788382507 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I'm waiting to hear from the authors/WG. Lars On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: > Hi, > > this document is ready, except for one issue: > > Section 7., paragraph 1: >> This document makes no direct request to IANA. However this > document >> allows for a set of Diffserv Codepoints to be assigned different > ECN >> semantics within a controlled domain as described in [RFC4774]. A >> list of such DSCPs will be maintained by the PCN working group. > > DISCUSS: This text isn't aligned with appendix A.1. The text here > says > "the WG will maintain a list of DSCPs that are OK", while the > beginning of appendix A.1 says "the WG decided to not define with > which DSCPs PCN can be used" (but then the end of A.1 talks about > maintaining a list again.) Which is it? If there is to be a list, > you > need to create an IANA registry, write management procedures for it > (see RFC5226) and populate it with some initial values. (WGs are > ephemeral, which is why the PCN WG can't be the maintainer of this > list, IANA has to be.) If you want to leave it fully open for > deployments, you need to remove this confusion from the text. > > Lars > > > Nits: > > Section 4., paragraph 3: >> to prevent future compatability issues. > > Nit: s/compatability/compatibility/ > > > Section 4.2., paragraph 1: >> that is guaranteeed to be copied down into the inner header upon > > Nit: s/guaranteeed/guaranteed/ > > > Section 6., paragraph 1: >> always copy the CE codepoint from teh outer header into the inner > > Nit: s/teh/the/ > > > Section 6., paragraph 2: >> header in decapsulation (unless the inner packet is not-ECT). > If an >> operator it is essential that any operator wishing to allow ECN to >> exist end-to-end ensures there are no tunnel end-points within the >> PCN-domain. > > "If an operator it is essential that any operator..." - wording > > > Section 12., paragraph 0: >> 12. References > > Should be updated; see idnits report. > > > Appendix A., paragraph 2: >> a given PCN-domain is dependant on the nature of the traffic > entering > > Nit: s/dependant/dependent/ > > --Apple-Mail-53--788382507 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTQxMTI3MjFaMCMGCSqGSIb3DQEJBDEWBBSwZqFIlqkeNWNe MQEcRbOk2LZDlzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEASrNEvqITG1BDA+6tHN0CAznVGPaZ8cdiPt/GgGWgDcqSpbmdQudm LRlV9vDVFMyehpfgXQgZyEf0JD6ct2AL8KKyXZMLHVg0B1Z3tOMrn/QuDwTdFmC/F8c1iBcuSiD5 dZ43WTdW6+36xZozBHTDBkHtFnphUKbkO0ABmXG0iXPL4LM1ANY4nORxjYW+WEPeHd2FH/xqnhio R5dmXktqQ+X3Ka72t3/VnMP29C21sc4qUURupQP6YFzGNUmGd0KxQPrqMZoKxZNj90AtOkGrGmMU Ep83NUw/UwBtXdmn9AX+qkYS2ZK15w5y3Kznr79wKmF0mQMgSlRt6oXivR68WgAAAAAAAA== --Apple-Mail-53--788382507-- From toby.moncaster@bt.com Fri Aug 14 07:39:51 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 936F23A68D2 for ; Fri, 14 Aug 2009 07:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyUIiOZ7KMtV for ; Fri, 14 Aug 2009 07:39:50 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 4E4AF3A6951 for ; Fri, 14 Aug 2009 07:39:49 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 14:06:25 +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, 14 Aug 2009 14:05:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: Acoc2SIdh0b1ygh5TSyje6dp2oIklwAA7z+Q References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> From: To: , X-OriginalArrivalTime: 14 Aug 2009 13:06:25.0532 (UTC) FILETIME=[075DCBC0:01CA1CE0] Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 14 Aug 2009 14:39:51 -0000 Hi Lars, Sorry not to get back to you earlier - been busy at work so this went on a back-burner for a few days.=20 The original intention of having registration was to avoid confusion during any early experimental adoption of PCN however that could be done purely unofficially by having a list of DSCPs on the IETF wiki and just politely asking developers to consult it and add any new ones they are using. But there will need in future to be a process to formally register certain standards (pool 1) DSCPs as PCN-compatible since this effectively replaces ECN as the default behaviour for such DSCPs. So my suggestion is: Change the IANA section to say something along the following lines (I will get IANA assistance with crafting exact text): "IANA will be asked to set up a registry of PCN-compatible Diffserv codepoints. The decision as to whether to enable PCN for a given pool 1 codepoint must be made by the appropriate IETF Transport Area Working Group (TSVWG?) which will then request IANA to add this to the registry." Clarify at start of A.1 that the decision of which DSCPs to apply PCN to has to be made by TSVWG and is separate to this document which just defines the process and the encoding. Change the last sentence of A.1 to "IANA will maintain a list of PCN-compatible Diffserv Codepoints." Would this cover things appropriately? I did wonder about asking IANA to maintain the experimental registry but I am not sure if they are able to do that sort of thing? If so the following could be added to the IANA section: "During the early stages of adoption it is envisaged that PCN will be used experimentally using pool 2 or 3 DSCPs (experimental or local use). Whilst these DSCPs are not controlled by IANA normally, a request will be made to maintain a list of PCN experiments along with the DSCPs these experiments are using." Once I get the nod from WG I will release a new version of the I-D with these updates... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 14 August 2009 12:27 > To: pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm waiting to hear from the authors/WG. >=20 > Lars >=20 > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, > > > > this document is ready, except for one issue: > > > > Section 7., paragraph 1: > >> This document makes no direct request to IANA. However this > > document > >> allows for a set of Diffserv Codepoints to be assigned different > > ECN > >> semantics within a controlled domain as described in [RFC4774]. A > >> list of such DSCPs will be maintained by the PCN working group. > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > says > > "the WG will maintain a list of DSCPs that are OK", while the > > beginning of appendix A.1 says "the WG decided to not define with > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > maintaining a list again.) Which is it? If there is to be a list, > > you > > need to create an IANA registry, write management procedures for it > > (see RFC5226) and populate it with some initial values. (WGs are > > ephemeral, which is why the PCN WG can't be the maintainer of this > > list, IANA has to be.) If you want to leave it fully open for > > deployments, you need to remove this confusion from the text. > > > > Lars > > > > > > Nits: > > > > Section 4., paragraph 3: > >> to prevent future compatability issues. > > > > Nit: s/compatability/compatibility/ > > > > > > Section 4.2., paragraph 1: > >> that is guaranteeed to be copied down into the inner header upon > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > Section 6., paragraph 1: > >> always copy the CE codepoint from teh outer header into the inner > > > > Nit: s/teh/the/ > > > > > > Section 6., paragraph 2: > >> header in decapsulation (unless the inner packet is not-ECT). > > If an > >> operator it is essential that any operator wishing to allow ECN to > >> exist end-to-end ensures there are no tunnel end-points within the > >> PCN-domain. > > > > "If an operator it is essential that any operator..." - wording > > > > > > Section 12., paragraph 0: > >> 12. References > > > > Should be updated; see idnits report. > > > > > > Appendix A., paragraph 2: > >> a given PCN-domain is dependant on the nature of the traffic > > entering > > > > Nit: s/dependant/dependent/ > > > > From menth@informatik.uni-wuerzburg.de Sat Aug 15 03:34: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 CBC783A6E3B for ; Sat, 15 Aug 2009 03:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.642 X-Spam-Level: X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHKf1f1nlLG2 for ; Sat, 15 Aug 2009 03:34:33 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 7EFF53A6DD9 for ; Sat, 15 Aug 2009 03:34:33 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 99BAD199811 for ; Sat, 15 Aug 2009 12:34:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8CAB71997E6 for ; Sat, 15 Aug 2009 12:34:35 +0200 (CEST) Received: from [132.187.246.102] (wvpn102.vpn.uni-wuerzburg.de [132.187.246.102]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 620BB1997E4 for ; Sat, 15 Aug 2009 12:34:35 +0200 (CEST) Message-ID: <4A868F1C.70702@informatik.uni-wuerzburg.de> Date: Sat, 15 Aug 2009 12:34:04 +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 Subject: [PCN] Paper on Measured Rate Termination 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: Sat, 15 Aug 2009 10:34:34 -0000 Dear colleagues, we finally managed to revise our paper on "PCN-Based Measured Rate Termination (MRT)". http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf It is important for the WG for several reasons: 1) It documents pitfalls with different MRT versions. We should take them into account in the edge behavior drafts. E.g., inter-measurment times (IMT) are required at the egress node also for MRT-ITR (MRT with indirectly calculated termination rates) to avoid overtermination in the presence of IEAs with significantly different RTTs. That's the issue Daisuke brought up on the list. 2) It shows how many termination steps are required with MRT-DTR (MRT with directly calculated termination rates) in case of packet loss. 3) It introduces proportional flow termination policies that allow CL to terminate flows without overtermination even if there are only a very few flows per ingress-egress-aggregate (IEA) and multiple IEAs on a bottleneck link. 4) It shows that SM poorly performs for small IEAs even if flow termination policies respect safety margins for termination. This is probably one of the most important reasons why SM is not good enough and CL is standardized as a second system, but the issue was nowhere documented so far. These are the major issues. A summary of all findings is provided in Section 4.9. Thanks a lot for all your comments so far, they greatly improved the contents and the readability of the paper. Further comments are welcome. Kind 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 Ruediger.Geib@telekom.de Tue Aug 18 01:02: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 A9E723A69AF for ; Tue, 18 Aug 2009 01:02:55 -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 PIOc2xIYF+JV for ; Tue, 18 Aug 2009 01:02:54 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id DB2533A6B2C for ; Tue, 18 Aug 2009 01:02:52 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 18 Aug 2009 09:55:13 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 09:55:13 +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: Tue, 18 Aug 2009 09:55:10 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: Acoc2SIdh0b1ygh5TSyje6dp2oIklwAA7z+QALyoVnA= References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> From: To: X-OriginalArrivalTime: 18 Aug 2009 07:55:13.0157 (UTC) FILETIME=[376A7B50:01CA1FD9] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 18 Aug 2009 08:02:55 -0000 Toby, PCN should express to the IANA, whether one or more new DSCP is=20 required to operate or carry out experiments on PCN. As soon as IANA maintains a list of DSCPs for any purpose, this=20 will have the status of a standard.=20 "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs=20 per traffic class (DSCP bit 0-2, let's call them traffic class=20 in this email) for PCN, that's 32 DSCPs in all. If possible, PCN should limit the number of traffic classes,=20 where to apply PCN. I don't think PCN will be applied in traffic classes 0 and 6. I'd expect PCN to be used within traffic classes 5 and 4,=20 may be also 3 or 2. Traffic classes 1 and 7 may be excluded too. The above clearly expresses personal views, but informational=20 RFC5127 to some extent backs these personal views. I'm aware that PCN WG shouldn't standardise traffic class usage=20 or come close to that. I however want to avoid repeating the biggest=20 flaw of the AF specification, which in my eyes is to reserve=20 12 DSCPs for 4 traffic classes. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com Sent: Friday, August 14, 2009 3:06 PM To: lars.eggert@nokia.com; pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Hi Lars, Sorry not to get back to you earlier - been busy at work so this went on a back-burner for a few days.=20 The original intention of having registration was to avoid confusion during any early experimental adoption of PCN however that could be done purely unofficially by having a list of DSCPs on the IETF wiki and just politely asking developers to consult it and add any new ones they are using. But there will need in future to be a process to formally register certain standards (pool 1) DSCPs as PCN-compatible since this effectively replaces ECN as the default behaviour for such DSCPs. So my suggestion is: Change the IANA section to say something along the following lines (I will get IANA assistance with crafting exact text): "IANA will be asked to set up a registry of PCN-compatible Diffserv codepoints. The decision as to whether to enable PCN for a given pool 1 codepoint must be made by the appropriate IETF Transport Area Working Group (TSVWG?) which will then request IANA to add this to the registry." Clarify at start of A.1 that the decision of which DSCPs to apply PCN to has to be made by TSVWG and is separate to this document which just defines the process and the encoding. Change the last sentence of A.1 to "IANA will maintain a list of PCN-compatible Diffserv Codepoints." Would this cover things appropriately? I did wonder about asking IANA to maintain the experimental registry but I am not sure if they are able to do that sort of thing? If so the following could be added to the IANA section: "During the early stages of adoption it is envisaged that PCN will be used experimentally using pool 2 or 3 DSCPs (experimental or local use). Whilst these DSCPs are not controlled by IANA normally, a request will be made to maintain a list of PCN experiments along with the DSCPs these experiments are using." Once I get the nod from WG I will release a new version of the I-D with these updates... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 14 August 2009 12:27 > To: pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm waiting to hear from the authors/WG. >=20 > Lars >=20 > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, > > > > this document is ready, except for one issue: > > > > Section 7., paragraph 1: > >> This document makes no direct request to IANA. However this > > document > >> allows for a set of Diffserv Codepoints to be assigned different > > ECN > >> semantics within a controlled domain as described in [RFC4774]. A > >> list of such DSCPs will be maintained by the PCN working group. > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > says > > "the WG will maintain a list of DSCPs that are OK", while the > > beginning of appendix A.1 says "the WG decided to not define with > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > maintaining a list again.) Which is it? If there is to be a list, > > you > > need to create an IANA registry, write management procedures for it > > (see RFC5226) and populate it with some initial values. (WGs are > > ephemeral, which is why the PCN WG can't be the maintainer of this > > list, IANA has to be.) If you want to leave it fully open for > > deployments, you need to remove this confusion from the text. > > > > Lars > > > > > > Nits: > > > > Section 4., paragraph 3: > >> to prevent future compatability issues. > > > > Nit: s/compatability/compatibility/ > > > > > > Section 4.2., paragraph 1: > >> that is guaranteeed to be copied down into the inner header upon > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > Section 6., paragraph 1: > >> always copy the CE codepoint from teh outer header into the inner > > > > Nit: s/teh/the/ > > > > > > Section 6., paragraph 2: > >> header in decapsulation (unless the inner packet is not-ECT). > > If an > >> operator it is essential that any operator wishing to allow ECN to > >> exist end-to-end ensures there are no tunnel end-points within the > >> PCN-domain. > > > > "If an operator it is essential that any operator..." - wording > > > > > > Section 12., paragraph 0: > >> 12. References > > > > Should be updated; see idnits report. > > > > > > Appendix A., paragraph 2: > >> a given PCN-domain is dependant on the nature of the traffic > > entering > > > > Nit: s/dependant/dependent/ > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From rbriscoe@jungle.bt.co.uk Tue Aug 18 10:36:43 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B7F28C18F for ; Tue, 18 Aug 2009 10:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 OJpXCyrITbdM for ; Tue, 18 Aug 2009 10:36:36 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id DBB363A6B31 for ; Tue, 18 Aug 2009 10:36:35 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 18:36:40 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 18:36:40 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1250616999264; Tue, 18 Aug 2009 18:36:39 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7IHaZjk032639; Tue, 18 Aug 2009 18:36:35 +0100 Message-Id: <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Aug 2009 18:36:31 +0100 To: , From: Bob Briscoe In-Reply-To: <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte .t-com.de> References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 18 Aug 2009 17:36:40.0373 (UTC) FILETIME=[71D12E50:01CA202A] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 18 Aug 2009 17:36:43 -0000 Ruediger,

The draft as it stands holds two inconsistent opinions:
i) "
the aim is for PCN to re-use existing DSCPs
" (S.4.3.1)
ii) the second half of Appx A.1, repeated below.

Similarly, your posting, talks about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for PCN.

I believe we should scrub (ii) and only have (i). In place of ii) we should list the classes that might be appropriate to associate with PCN marking.

In other words, we should only say that an operator _applies_ PCN marking to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that would waste DSCPs just to get a different marking behaviour for packets requiring the same scheduling behaviour as a pre-existing DSCP. The non-wasteful way to do this is to use one DSCP for a certain scheduling behaviour, but set the ECN field to a non-zero value to turn on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the efficient way is different. Then RFC5129 describes how you would do it.]

To be absolutely sure it's clear what I mean, here's an example:

                            hi stat mux subnet
                            ___________________
                           |            same   |
                           |           marking |
                           |   _____  ____:___ |
                           |  |     ||        ||
-------DSCPA--Not-ECT----------DSCPA--NM-------------DSCPA--Not-ECT-----------
                           |  |     ||        ||
-------DSCPB--Not-ECT----------DSCPB--NM-------------DSCPB--Not-ECT-----------
                           |  |     ||________||
                           |  |     |          |
-------DSCPC--Not-ECT----------DSCPC--Not-PCN--------DSCPC--Not-ECT-----------
                           |  |_____|          |
                           |   _____           |
                           |  |     |          |
-------DSCPD--ECT--------------DSCPD--ECT------------DSCPD--ECT---------------
                           |  |     |          |
-------DSCPE--Not-ECT----------DSCPE--Not-PCN--------DSCPE--Not-ECT-----------
                           |  |_____|          |
                           |     :             |
                           |   same            |
                           | scheduling        |
                           |   (BA)            |
                           |___________________|

- The text on each flow shows the DSCP-ECN combination used for that segment
- The boxes around DSCPA/B/C and around DSCPD/E represent the same scheduling behaviour applied to multiple DSCPs in the aggregated region (a behaviour aggregate).
- The box around NM for the first two flows represents the same marking behaviour (PCN) applied to multiple DSCPs.
- The flows keep the same DSCP* along their whole path, so when they pop out into the lo-stat-mux region on the other side, the DSCP is preserved.
- In practice, traffic might be tunnelled across the hi-stat mux region, and at the same time common scheduling behaviours might be mapped to a single DSCP in the outer headers. The diagram merely shows everything can be done without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually stay the same along the whole path. It might be mapped to local DSCPs that are each used for the same class at different points along the path.


Here's a copy of the 2nd half of Appx A.1, that I think needs to be
removed (sorry, I know I'm a co-author, but...):
"  The choice of which DSCP is most suitable for
   a given PCN-domain is dependant on the nature of the traffic
entering
   that domain and the link rates of all the links making up
that
   domain.  In PCN-domains with uniformly high link rates,
the
   appropriate DSCPs would currently be those for the Real Time
Traffic
   Class
[RFC5127].  If the
PCN domain includes lower speed links it
   would also be appropriate to use the DSCPs of the other
traffic
   classes that
[
Voice-Admit] defines for use with admission control,
   such as the three video classes CS4, CS3 and AF4 and the
Admitted
   Telephony Class.  The PCN working group will maintain a
list of PCN-
   compatible Diffserv Codepoints.
"

At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:
Toby,

PCN should express to the IANA, whether one or more new DSCP is
required to operate or carry out experiments on PCN.

As soon as IANA maintains a list of DSCPs for any purpose, this
will have the status of a standard.

"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs
per traffic class (DSCP bit 0-2, let's call them traffic class
in this email) for PCN, that's 32 DSCPs in all.

If possible, PCN should limit the number of traffic classes,
where to apply PCN.

I don't think PCN will be applied in traffic classes 0 and 6.

I'd expect PCN to be used within traffic classes 5 and 4,
may be also 3 or 2.

Traffic classes 1 and 7 may be excluded too.

The above clearly expresses personal views, but informational
RFC5127 to some extent backs these personal views.

I'm aware that PCN WG shouldn't standardise traffic class usage
or come close to that. I however want to avoid repeating the biggest
flaw of the AF specification, which in my eyes is to reserve
12 DSCPs for 4 traffic classes.

Regards,

Ruediger



-----Original Message-----
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com
Sent: Friday, August 14, 2009 3:06 PM
To: lars.eggert@nokia.com; pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went on
a back-burner for a few days.

The original intention of having registration was to avoid confusion
during any early experimental adoption of PCN however that could be done
purely unofficially by having a list of DSCPs on the IETF wiki and just
politely asking developers to consult it and add any new ones they are
using. But there will need in future to be a process to formally
register certain standards (pool 1) DSCPs as PCN-compatible since this
effectively replaces ECN as the default  behaviour for such DSCPs. So my
suggestion is:

Change the IANA section to say something along the following lines (I
will get IANA assistance with crafting exact text):

"IANA will be asked to set up a registry of PCN-compatible Diffserv
codepoints. The decision as to whether to enable PCN for a given pool 1
codepoint must be made by the appropriate IETF Transport Area Working
Group (TSVWG?) which will then request IANA to add this to the
registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN to
has to be made by TSVWG and is separate to this document which just
defines the process and the encoding.

Change the last sentence of A.1 to "IANA will maintain a list of
PCN-compatible Diffserv Codepoints."

Would this cover things appropriately? I did wonder about asking IANA to
maintain the experimental registry but I am not sure if they are able to
do that sort of thing? If so the following could be added to the IANA
section:

"During the early stages of adoption it is envisaged that PCN will be
used experimentally using pool 2 or 3 DSCPs (experimental or local use).
Whilst these DSCPs are not controlled by IANA normally, a request will
be made to maintain a list of PCN experiments along with the DSCPs these
experiments are using."

Once I get the nod from WG I will release a new version of the I-D with
these updates...

Toby

> -----Original Message-----
> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To: pcn@ietf.org
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
>
> Hi,
>
> I'm waiting to hear from the authors/WG.
>
> Lars
>
> On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
>
> > Hi,
> >
> > this document is ready, except for one issue:
> >
> > Section 7., paragraph 1:
> >>   This document makes no direct request to IANA.  However this
> > document
> >>   allows for a set of Diffserv Codepoints to be assigned different
> > ECN
> >>   semantics within a controlled domain as described in [RFC4774].
A
> >>   list of such DSCPs will be maintained by the PCN working group.
> >
> >   DISCUSS: This text isn't aligned with appendix A.1. The text here
> > says
> >   "the WG will maintain a list of DSCPs that are OK", while the
> >   beginning of appendix A.1 says "the WG decided to not define with
> >   which DSCPs PCN can be used" (but then the end of A.1 talks about
> >   maintaining a list again.) Which is it? If there is to be a list,
> > you
> >   need to create an IANA registry, write management procedures for
it
> >   (see RFC5226) and populate it with some initial values. (WGs are
> >   ephemeral, which is why the PCN WG can't be the maintainer of this
> >   list, IANA has to be.) If you want to leave it fully open for
> >   deployments, you need to remove this confusion from the text.
> >
> > Lars
> >
> >
> > Nits:
> >
> > Section 4., paragraph 3:
> >>                  to prevent future compatability issues.
> >
> >   Nit: s/compatability/compatibility/
> >
> >
> > Section 4.2., paragraph 1:
> >>   that is guaranteeed to be copied down into the inner header upon
> >
> >   Nit: s/guaranteeed/guaranteed/
> >
> >
> > Section 6., paragraph 1:
> >>   always copy the CE codepoint from teh outer header into the inner
> >
> >   Nit: s/teh/the/
> >
> >
> > Section 6., paragraph 2:
> >>   header in decapsulation (unless the inner packet is not-ECT).
> > If an
> >>   operator it is essential that any operator wishing to allow ECN
to
> >>   exist end-to-end ensures there are no tunnel end-points within
the
> >>   PCN-domain.
> >
> >   "If an operator it is essential that any operator..." - wording
> >
> >
> > Section 12., paragraph 0:
> >> 12.  References
> >
> >   Should be updated; see idnits report.
> >
> >
> > Appendix A., paragraph 2:
> >>   a given PCN-domain is dependant on the nature of the traffic
> > entering
> >
> >   Nit: s/dependant/dependent/
> >
> > <smime.p7s><ATT00001.txt>

_______________________________________________
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 Tue Aug 18 23:30:21 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 3A02E3A6AF0 for ; Tue, 18 Aug 2009 23:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqZEsPwOefGj for ; Tue, 18 Aug 2009 23:30:19 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 915F23A684B for ; Tue, 18 Aug 2009 23:30:17 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 19 Aug 2009 08:27:30 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 08:27:30 +0200 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_01CA2096.20D78DE0" Date: Wed, 19 Aug 2009 08:27:28 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: AcogKnJThA7rpiWNQ9Gez6EhahDPKQAaw3wA References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> From: To: , X-OriginalArrivalTime: 19 Aug 2009 06:27:30.0692 (UTC) FILETIME=[2127CC40:01CA2096] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 06:30:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2096.20D78DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bob, =20 I agree to your suggestion to "scrub (ii) and only have (i)..[and that] = we should list classes that might be appropriate to associate with PCN = marking." =20 Regards, =20 Ruediger _____ =20 From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: Tuesday, August 18, 2009 7:37 PM To: Geib, R=FCdiger; toby.moncaster@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Ruediger, The draft as it stands holds two inconsistent opinions: i) " the aim is for PCN to re-use existing DSCPs " (S.4.3.1) ii) the second half of Appx A.1, repeated below. Similarly, your posting, talks about: i) applying PCN to existing DSCPs ii) reserving DSCPs for PCN. I believe we should scrub (ii) and only have (i). In place of ii) we = should list the classes that might be appropriate to associate with PCN = marking. In other words, we should only say that an operator _applies_ PCN = marking to certain existing DSCPs. No-one needs any additional DSCPs to enable PCN marking. Otherwise that = would waste DSCPs just to get a different marking behaviour for packets = requiring the same scheduling behaviour as a pre-existing DSCP. The = non-wasteful way to do this is to use one DSCP for a certain scheduling = behaviour, but set the ECN field to a non-zero value to turn on PCN = marking (S.4.3.1). [In MPLS, as there is no ECN field, the efficient way is different. Then = RFC5129 describes how you would do it.] To be absolutely sure it's clear what I mean, here's an example: hi stat mux subnet ___________________ | same | | marking | | _____ ____:___ | | | || || -------DSCPA--Not-ECT----------DSCPA--NM-------------DSCPA--Not-ECT------= ----- | | || || -------DSCPB--Not-ECT----------DSCPB--NM-------------DSCPB--Not-ECT------= ----- | | ||________|| | | | | -------DSCPC--Not-ECT----------DSCPC--Not-PCN--------DSCPC--Not-ECT------= ----- | |_____| | | _____ | | | | | -------DSCPD--ECT--------------DSCPD--ECT------------DSCPD--ECT----------= ----- | | | | -------DSCPE--Not-ECT----------DSCPE--Not-PCN--------DSCPE--Not-ECT------= ----- | |_____| | | : | | same | | scheduling | | (BA) | |___________________| - The text on each flow shows the DSCP-ECN combination used for that = segment - The boxes around DSCPA/B/C and around DSCPD/E represent the same = scheduling behaviour applied to multiple DSCPs in the aggregated region = (a behaviour aggregate). - The box around NM for the first two flows represents the same marking = behaviour (PCN) applied to multiple DSCPs. - The flows keep the same DSCP* along their whole path, so when they pop = out into the lo-stat-mux region on the other side, the DSCP is = preserved. - In practice, traffic might be tunnelled across the hi-stat mux region, = and at the same time common scheduling behaviours might be mapped to a = single DSCP in the outer headers. The diagram merely shows everything = can be done without tunnelling or layering. * Note: For some non-standardised DSCPs, the DSCP might not actually = stay the same along the whole path. It might be mapped to local DSCPs = that are each used for the same class at different points along the = path. Here's a copy of the 2nd half of Appx A.1, that I think needs to be removed (sorry, I know I'm a co-author, but...): " The choice of which DSCP is most suitable for a given PCN-domain is dependant on the nature of the traffic entering that domain and the link rates of all the links making up that domain. In PCN-domains with uniformly high link rates, the appropriate DSCPs would currently be those for the Real Time Traffic Class [RFC5127 ]. If the PCN domain includes lower speed links it would also be appropriate to use the DSCPs of the other traffic classes that [ = =20 Voice-Admit] defines for use with admission control, such as the three video classes CS4, CS3 and AF4 and the Admitted Telephony Class. The PCN working group will maintain a list of PCN- compatible Diffserv Codepoints. " At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: Toby, PCN should express to the IANA, whether one or more new DSCP is=20 required to operate or carry out experiments on PCN. As soon as IANA maintains a list of DSCPs for any purpose, this=20 will have the status of a standard.=20 "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs=20 per traffic class (DSCP bit 0-2, let's call them traffic class=20 in this email) for PCN, that's 32 DSCPs in all. If possible, PCN should limit the number of traffic classes,=20 where to apply PCN. I don't think PCN will be applied in traffic classes 0 and 6. I'd expect PCN to be used within traffic classes 5 and 4,=20 may be also 3 or 2. Traffic classes 1 and 7 may be excluded too. The above clearly expresses personal views, but informational=20 RFC5127 to some extent backs these personal views. I'm aware that PCN WG shouldn't standardise traffic class usage=20 or come close to that. I however want to avoid repeating the biggest=20 flaw of the AF specification, which in my eyes is to reserve=20 12 DSCPs for 4 traffic classes. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [ = mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com Sent: Friday, August 14, 2009 3:06 PM To: lars.eggert@nokia.com; pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Hi Lars, Sorry not to get back to you earlier - been busy at work so this went on a back-burner for a few days.=20 The original intention of having registration was to avoid confusion during any early experimental adoption of PCN however that could be done purely unofficially by having a list of DSCPs on the IETF wiki and just politely asking developers to consult it and add any new ones they are using. But there will need in future to be a process to formally register certain standards (pool 1) DSCPs as PCN-compatible since this effectively replaces ECN as the default behaviour for such DSCPs. So my suggestion is: Change the IANA section to say something along the following lines (I will get IANA assistance with crafting exact text): "IANA will be asked to set up a registry of PCN-compatible Diffserv codepoints. The decision as to whether to enable PCN for a given pool 1 codepoint must be made by the appropriate IETF Transport Area Working Group (TSVWG?) which will then request IANA to add this to the registry." Clarify at start of A.1 that the decision of which DSCPs to apply PCN to has to be made by TSVWG and is separate to this document which just defines the process and the encoding. Change the last sentence of A.1 to "IANA will maintain a list of PCN-compatible Diffserv Codepoints." Would this cover things appropriately? I did wonder about asking IANA to maintain the experimental registry but I am not sure if they are able to do that sort of thing? If so the following could be added to the IANA section: "During the early stages of adoption it is envisaged that PCN will be used experimentally using pool 2 or 3 DSCPs (experimental or local use). Whilst these DSCPs are not controlled by IANA normally, a request will be made to maintain a list of PCN experiments along with the DSCPs these experiments are using." Once I get the nod from WG I will release a new version of the I-D with these updates... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [ = mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 14 August 2009 12:27 > To: pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm waiting to hear from the authors/WG. >=20 > Lars >=20 > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, > > > > this document is ready, except for one issue: > > > > Section 7., paragraph 1: > >> This document makes no direct request to IANA. However this > > document > >> allows for a set of Diffserv Codepoints to be assigned different > > ECN > >> semantics within a controlled domain as described in [RFC4774]. A > >> list of such DSCPs will be maintained by the PCN working group. > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > says > > "the WG will maintain a list of DSCPs that are OK", while the > > beginning of appendix A.1 says "the WG decided to not define with > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > maintaining a list again.) Which is it? If there is to be a list, > > you > > need to create an IANA registry, write management procedures for it > > (see RFC5226) and populate it with some initial values. (WGs are > > ephemeral, which is why the PCN WG can't be the maintainer of this > > list, IANA has to be.) If you want to leave it fully open for > > deployments, you need to remove this confusion from the text. > > > > Lars > > > > > > Nits: > > > > Section 4., paragraph 3: > >> to prevent future compatability issues. > > > > Nit: s/compatability/compatibility/ > > > > > > Section 4.2., paragraph 1: > >> that is guaranteeed to be copied down into the inner header upon > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > Section 6., paragraph 1: > >> always copy the CE codepoint from teh outer header into the inner > > > > Nit: s/teh/the/ > > > > > > Section 6., paragraph 2: > >> header in decapsulation (unless the inner packet is not-ECT). > > If an > >> operator it is essential that any operator wishing to allow ECN to > >> exist end-to-end ensures there are no tunnel end-points within the > >> PCN-domain. > > > > "If an operator it is essential that any operator..." - wording > > > > > > Section 12., paragraph 0: > >> 12. References > > > > Should be updated; see idnits report. > > > > > > Appendix A., paragraph 2: > >> a given PCN-domain is dependant on the nature of the traffic > > entering > > > > Nit: s/dependant/dependent/ > > > > _______________________________________________ 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 ------_=_NextPart_001_01CA2096.20D78DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bob,
 
I agree to your suggestion to "scrub (ii) and = only have=20 (i)..[and that] we should list classes that might be appropriate to = associate=20 with PCN marking."
 
Regards,
 
Ruediger

From: Bob Briscoe=20 [mailto:rbriscoe@jungle.bt.co.uk]
Sent: Tuesday, August 18, = 2009 7:37=20 PM
To: Geib, R=FCdiger; toby.moncaster@bt.com
Cc:=20 pcn@ietf.org
Subject: Re: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04

Ruediger,

The draft as it stands holds two = inconsistent=20 opinions:
i) "
the aim is for PCN to re-use existing DSCPs
" = (S.4.3.1)
ii) the=20 second half of Appx A.1, repeated below.

Similarly, your posting, = talks=20 about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for=20 PCN.

I believe we should scrub (ii) and only have (i). In place = of ii) we=20 should list the classes that might be appropriate to associate with PCN=20 marking.

In other words, we should only say that an operator = _applies_=20 PCN marking to certain existing DSCPs.

No-one needs any = additional DSCPs=20 to enable PCN marking. Otherwise that would waste DSCPs just to get a = different=20 marking behaviour for packets requiring the same scheduling behaviour as = a=20 pre-existing DSCP. The non-wasteful way to do this is to use one DSCP = for a=20 certain scheduling behaviour, but set the ECN field to a non-zero value = to turn=20 on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the = efficient way is different. Then RFC5129 describes how you would do=20 it.]

To be absolutely sure it's clear what I mean, here's an=20 example:

         &nb= sp;           &nbs= p;     =20 hi stat mux=20 subnet
          &nb= sp;           &nbs= p;    =20 ___________________
        &n= bsp;           &nb= sp;     =20 |           =20 same  =20 |
           &n= bsp;           &nb= sp;  =20 |           marking=20 |
           &n= bsp;           &nb= sp;  =20 |   _____  ____:___=20 |
           &n= bsp;           &nb= sp;  =20 |  |     = ||       =20 ||
-------DSCPA--Not-ECT----------DSCPA--NM-------------DSCPA--Not-ECT= -----------
         &nbs= p;            = ;    =20 |  |     = ||       =20 ||
-------DSCPB--Not-ECT----------DSCPB--NM-------------DSCPB--Not-ECT= -----------
         &nbs= p;            = ;    =20 |  |    =20 ||________||
         &nb= sp;           &nbs= p;    =20 |  |    =20 |         =20 |
-------DSCPC--Not-ECT----------DSCPC--Not-PCN--------DSCPC--Not-ECT-= ----------
          = ;            =     =20 |  |_____|         =20 |
           &n= bsp;           &nb= sp;  =20 |   = _____          =20 |
           &n= bsp;           &nb= sp;  =20 |  |    =20 |         =20 |
-------DSCPD--ECT--------------DSCPD--ECT------------DSCPD--ECT-----= ----------
          = ;            =     =20 |  |    =20 |         =20 |
-------DSCPE--Not-ECT----------DSCPE--Not-PCN--------DSCPE--Not-ECT-= ----------
          = ;            =     =20 |  |_____|         =20 |
           &n= bsp;           &nb= sp;  =20 |    =20 :            = =20 |
           &n= bsp;           &nb= sp;  =20 |  =20 same           =20 |
           &n= bsp;           &nb= sp;  =20 | scheduling       =20 |
           &n= bsp;           &nb= sp;  =20 |  =20 (BA)           =20 |
           &n= bsp;           &nb= sp;  =20 |___________________|

- The text on each flow shows the DSCP-ECN=20 combination used for that segment
- The boxes around DSCPA/B/C and = around=20 DSCPD/E represent the same scheduling behaviour applied to multiple = DSCPs in the=20 aggregated region (a behaviour aggregate).
- The box around NM for = the first=20 two flows represents the same marking behaviour (PCN) applied to = multiple=20 DSCPs.
- The flows keep the same DSCP* along their whole path, so = when they=20 pop out into the lo-stat-mux region on the other side, the DSCP is=20 preserved.
- In practice, traffic might be tunnelled across the = hi-stat mux=20 region, and at the same time common scheduling behaviours might be = mapped to a=20 single DSCP in the outer headers. The diagram merely shows everything = can be=20 done without tunnelling or layering.

* Note: For some = non-standardised=20 DSCPs, the DSCP might not actually stay the same along the whole path. = It might=20 be mapped to local DSCPs that are each used for the same class at = different=20 points along the path.


Here's a copy of the 2nd half of =
Appx A.1, that I think needs to be
removed (sorry, I know I'm a co-author, but...):
"  The choice of which DSCP is most suitable for
   a given PCN-domain is dependant on the nature of the =
traffic
entering
   that domain and the link rates of all the links making up
that
   domain.  In PCN-domains with uniformly high link =
rates,
the
   appropriate DSCPs would currently be those for the Real =
Time
Traffic
   Class
[RFC5127].  If =
the
PCN domain includes lower speed links it
   would also be appropriate to use the DSCPs of the other
traffic
   classes that
[
Voice-Admit] defines for use with admission control,
   such as the three video classes CS4, CS3 and AF4 and the
Admitted
   Telephony Class.  The PCN working group will maintain =
a
list of PCN-
   compatible Diffserv Codepoints.
"

At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:
Toby,

PCN should = express to=20 the IANA, whether one or more new DSCP is
required to operate or = carry out=20 experiments on PCN.

As soon as IANA maintains a list of DSCPs = for any=20 purpose, this
will have the status of a standard.

"Using = pool 2 or=20 3 DSCPs" to me sounds like reserving 4 DSCPs
per traffic class = (DSCP bit=20 0-2, let's call them traffic class
in this email) for PCN, that's = 32 DSCPs=20 in all.

If possible, PCN should limit the number of traffic = classes,=20
where to apply PCN.

I don't think PCN will be applied in = traffic=20 classes 0 and 6.

I'd expect PCN to be used within traffic = classes 5 and=20 4,
may be also 3 or 2.

Traffic classes 1 and 7 may be = excluded=20 too.

The above clearly expresses personal views, but = informational=20
RFC5127 to some extent backs these personal views.

I'm = aware that=20 PCN WG shouldn't standardise traffic class usage
or come close to = that. I=20 however want to avoid repeating the biggest
flaw of the AF = specification,=20 which in my eyes is to reserve
12 DSCPs for 4 traffic=20 classes.

Regards,

Ruediger



-----Original=20 Message-----
From: pcn-bounces@ietf.org [=20 mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com
Sent:=20 Friday, August 14, 2009 3:06 PM
To: lars.eggert@nokia.com;=20 pcn@ietf.org
Subject: Re: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not = to get=20 back to you earlier - been busy at work so this went on
a = back-burner for a=20 few days.

The original intention of having registration was to = avoid=20 confusion
during any early experimental adoption of PCN however = that could=20 be done
purely unofficially by having a list of DSCPs on the IETF = wiki and=20 just
politely asking developers to consult it and add any new ones = they=20 are
using. But there will need in future to be a process to=20 formally
register certain standards (pool 1) DSCPs as = PCN-compatible since=20 this
effectively replaces ECN as the default  behaviour for = such=20 DSCPs. So my
suggestion is:

Change the IANA section to say = something=20 along the following lines (I
will get IANA assistance with crafting = exact=20 text):

"IANA will be asked to set up a registry of = PCN-compatible=20 Diffserv
codepoints. The decision as to whether to enable PCN for a = given=20 pool 1
codepoint must be made by the appropriate IETF Transport = Area=20 Working
Group (TSVWG?) which will then request IANA to add this to=20 the
registry."

Clarify at start of A.1 that the decision of = which=20 DSCPs to apply PCN to
has to be made by TSVWG and is separate to = this=20 document which just
defines the process and the = encoding.

Change the=20 last sentence of A.1 to "IANA will maintain a list = of
PCN-compatible=20 Diffserv Codepoints."

Would this cover things appropriately? I = did=20 wonder about asking IANA to
maintain the experimental registry but = I am not=20 sure if they are able to
do that sort of thing? If so the following = could=20 be added to the IANA
section:

"During the early stages of = adoption=20 it is envisaged that PCN will be
used experimentally using pool 2 = or 3=20 DSCPs (experimental or local use).
Whilst these DSCPs are not = controlled by=20 IANA normally, a request will
be made to maintain a list of PCN = experiments=20 along with the DSCPs these
experiments are using."

Once I = get the=20 nod from WG I will release a new version of the I-D with
these=20 updates...

Toby

> -----Original Message-----
> = From:=20 pcn-bounces@ietf.org [=20 mailto:pcn-bounces@ietf.org] On Behalf Of
> Lars = Eggert
>=20 Sent: 14 August 2009 12:27
> To: pcn@ietf.org
> Subject: = Re: [PCN]=20 AD review: draft-ietf-pcn-baseline-encoding-04
>
> = Hi,
>=20
> I'm waiting to hear from the authors/WG.
>
>=20 Lars
>
> On 2009-8-5, at 17:19, Eggert Lars = (Nokia-NRC/Espoo)=20 wrote:
>
> > Hi,
> >
> > this = document is=20 ready, except for one issue:
> >
> > Section 7., = paragraph=20 1:
> >>   This document makes no direct request = to=20 IANA.  However this
> > document
> = >>  =20 allows for a set of Diffserv Codepoints to be assigned = different
> >=20 ECN
> >>   semantics within a controlled domain = as=20 described in [RFC4774].
A
> >>   list of such = DSCPs=20 will be maintained by the PCN working group.
> >
>=20 >   DISCUSS: This text isn't aligned with appendix A.1. = The text=20 here
> > says
> >   "the WG will maintain = a list=20 of DSCPs that are OK", while the
> >   beginning of = appendix A.1 says "the WG decided to not define with
> = >  =20 which DSCPs PCN can be used" (but then the end of A.1 talks = about
>=20 >   maintaining a list again.) Which is it? If there is = to be a=20 list,
> > you
> >   need to create an IANA = registry, write management procedures for
it
> = >   (see=20 RFC5226) and populate it with some initial values. (WGs are
>=20 >   ephemeral, which is why the PCN WG can't be the = maintainer of=20 this
> >   list, IANA has to be.) If you want to = leave it=20 fully open for
> >   deployments, you need to = remove this=20 confusion from the text.
> >
> > Lars
> = >
>=20 >
> > Nits:
> >
> > Section 4., = paragraph=20 3:
>=20 = >>           = ;      =20 to prevent future compatability issues.
> >
> = >  =20 Nit: s/compatability/compatibility/
> >
> >
> = >=20 Section 4.2., paragraph 1:
> >>   that is = guaranteeed to=20 be copied down into the inner header upon
> >
>=20 >   Nit: s/guaranteeed/guaranteed/
> >
>=20 >
> > Section 6., paragraph 1:
> = >>   always=20 copy the CE codepoint from teh outer header into the inner
>=20 >
> >   Nit: s/teh/the/
> >
>=20 >
> > Section 6., paragraph 2:
> = >>   header=20 in decapsulation (unless the inner packet is not-ECT).
> > If = an
> >>   operator it is essential that any = operator=20 wishing to allow ECN
to
> >>   exist = end-to-end=20 ensures there are no tunnel end-points within
the
>=20 >>   PCN-domain.
> >
> >   = "If an=20 operator it is essential that any operator..." - wording
> = >
>=20 >
> > Section 12., paragraph 0:
> >> 12.  = References
> >
> >   Should be updated; = see idnits=20 report.
> >
> >
> > Appendix A., paragraph=20 2:
> >>   a given PCN-domain is dependant on the = nature=20 of the traffic
> > entering
> >
> = >  =20 Nit: s/dependant/dependent/
> >
> >=20 = <smime.p7s><ATT00001.txt>

____________________________= ___________________
PCN=20 mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn
_____= __________________________________________
PCN=20 mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01CA2096.20D78DE0-- From rbriscoe@jungle.bt.co.uk Wed Aug 19 01:30:01 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 49C3B3A6CBB for ; Wed, 19 Aug 2009 01:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=-1.382, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, 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 WiViJeNwbAKm for ; Wed, 19 Aug 2009 01:29:53 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 478DE3A67E9 for ; Wed, 19 Aug 2009 01:29:33 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 09:29:37 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 09:29:36 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1250670575155; Wed, 19 Aug 2009 09:29:35 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7J8TTgm015982; Wed, 19 Aug 2009 09:29:29 +0100 Message-Id: <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Aug 2009 09:29:26 +0100 To: , From: Bob Briscoe In-Reply-To: <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte .t-com.de> References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Aug 2009 08:29:36.0471 (UTC) FILETIME=[2FA8F670:01CA20A7] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 08:30:01 -0000 Ruediger,

Great.

[As some people couldn't read it, I've also replaced the diag quoted in the thread below with narrower ASCII-art to better survive word wrap]

Cheers


Bob

At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote:
Hi Bob,
 
I agree to your suggestion to "scrub (ii) and only have (i)..[and that] we should list classes that might be appropriate to associate with PCN marking."
 
Regards,
 
Ruediger

From: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, R=FCdiger; toby.moncaster@bt.com
Cc: pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

The draft as it stands holds two inconsistent opinions:
i) "
the aim is for PCN to re-use existing DSCPs

" (S.4.3.1)
ii) the second half of Appx A.1, repeated below.

Similarly, your posting, talks about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for PCN.

I believe we should scrub (ii) and only have (i). In place of ii) we should list the classes that might be appropriate to associate with PCN marking.

In other words, we should only say that an operator _applies_ PCN marking to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that would waste DSCPs just to get a different marking behaviour for packets requiring the same scheduling behaviour as a pre-existing DSCP. The non-wasteful way to do this is to use one DSCP for a certain scheduling behaviour, but set the ECN field to a non-zero value to turn on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the efficient way is different. Then RFC5129 describes how you would do it.]

To be absolutely sure it's clear what I mean, here's an example:

            &nbs= p;      hi stat mux subnet
            &nbs= p;      ___________________
            &nbs= p;     |            same   |
            &nbs= p;     |           marking |
            &nbs= p;     |   _____  ____:___ |
            &nbs= p;     |  |     ||        ||
--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
            &nbs= p;     |  |     ||        ||
--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
            &nbs= p;     |  |     ||________||
            &nbs= p;     |  |     |          |
--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
            &nbs= p;     |  |_____|          |
            &nbs= p;     |   _____           |
            &nbs= p;     |  |     |          |
--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
            &nbs= p;     |  |     |          |
--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
            &nbs= p;     |  |_____|          |
            &nbs= p;     |     :             |
            &nbs= p;     |   same            |
            &nbs= p;     | scheduling        |
            &nbs= p;     |   (BA)            |
            &nbs= p;     |___________________|

- The text on each flow shows the DSCP-ECN combination used for that segment
- The boxes around DSCPA/B/C and around DSCPD/E represent the same scheduling behaviour applied to multiple DSCPs in the aggregated region (a behaviour aggregate).
- The box around NM for the first two flows represents the same marking behaviour (PCN) applied to multiple DSCPs.
- The flows keep the same DSCP* along their whole path, so when they pop out into the lo-stat-mux region on the other side, the DSCP is preserved.
- In practice, traffic might be tunnelled across the hi-stat mux region, and at the same time common scheduling behaviours might be mapped to a single DSCP in the outer headers. The diagram merely shows everything can be done without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually stay the same along the whole path. It might be mapped to local DSCPs that are each used for the same class at different points along the path.



Here's a copy of the 2nd half of Appx A.1, that I think needs to be
removed (sorry, I know I'm a co-author, but...):
"  The choice of which DSCP is most suitable for
   a given PCN-domain is dependant on the nature of the
traffic
entering
   that domain and the link rates of all the links making up
that
   domain.  In PCN-domains with uniformly high link
rates,
the
   appropriate DSCPs would currently be those for the Real
Time
Traffic
   Class
[RFC5127].  If the
PCN domain includes lower speed links it
   would also be appropriate to use the DSCPs of the other
traffic
   classes that
[
Voice-Admit] defines for use with admission control,
   such as the three video classes CS4, CS3 and AF4 and the
Admitted
   Telephony Class.  The PCN working group will maintain
a
list of PCN-
   compatible Diffserv Codepoints.

"

At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:
Toby,

PCN should express to the IANA, whether one or more new DSCP is
required to operate or carry out experiments on PCN.

As soon as IANA maintains a list of DSCPs for any purpose, this
will have the status of a standard.

"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs
per traffic class (DSCP bit 0-2, let's call them traffic class
in this email) for PCN, that's 32 DSCPs in all.

If possible, PCN should limit the number of traffic classes,
where to apply PCN.

I don't think PCN will be applied in traffic classes 0 and 6.

I'd expect PCN to be used within traffic classes 5 and 4,
may be also 3 or 2.

Traffic classes 1 and 7 may be excluded too.

The above clearly expresses personal views, but informational
RFC5127 to some extent backs these personal views.

I'm aware that PCN WG shouldn't standardise traffic class usage
or come close to that. I however want to avoid repeating the biggest
flaw of the AF specification, which in my eyes is to reserve
12 DSCPs for 4 traffic classes.

Regards,

Ruediger



-----Original Message-----
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com
Sent: Friday, August 14, 2009 3:06 PM
To: lars.eggert@nokia.com; pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went on
a back-burner for a few days.

The original intention of having registration was to avoid confusion
during any early experimental adoption of PCN however that could be done
purely unofficially by having a list of DSCPs on the IETF wiki and just
politely asking developers to consult it and add any new ones they are
using. But there will need in future to be a process to formally
register certain standards (pool 1) DSCPs as PCN-compatible since this
effectively replaces ECN as the default  behaviour for such DSCPs. So my
suggestion is:

Change the IANA section to say something along the following lines (I
will get IANA assistance with crafting exact text):

"IANA will be asked to set up a registry of PCN-compatible Diffserv
codepoints. The decision as to whether to enable PCN for a given pool 1
codepoint must be made by the appropriate IETF Transport Area Working
Group (TSVWG?) which will then request IANA to add this to the
registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN to
has to be made by TSVWG and is separate to this document which just
defines the process and the encoding.

Change the last sentence of A.1 to "IANA will maintain a list of
PCN-compatible Diffserv Codepoints."

Would this cover things appropriately? I did wonder about asking IANA to
maintain the experimental registry but I am not sure if they are able to
do that sort of thing? If so the following could be added to the IANA
section:

"During the early stages of adoption it is envisaged that PCN will be
used experimentally using pool 2 or 3 DSCPs (experimental or local use).
Whilst these DSCPs are not controlled by IANA normally, a request will
be made to maintain a list of PCN experiments along with the DSCPs these
experiments are using."

Once I get the nod from WG I will release a new version of the I-D with
these updates...

Toby

> -----Original Message-----
> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To: pcn@ietf.org
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
>
> Hi,
>
> I'm waiting to hear from the authors/WG.
>
> Lars
>
> On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
>
> > Hi,
> >
> > this document is ready, except for one issue:
> >
> > Section 7., paragraph 1:
> >>   This document makes no direct request to IANA.  However this
> > document
> >>   allows for a set of Diffserv Codepoints to be assigned different
> > ECN
> >>   semantics within a controlled domain as described in [RFC4774].
A
> >>   list of such DSCPs will be maintained by the PCN working group.
> >
> >   DISCUSS: This text isn't aligned with appendix A.1. The text here
> > says
> >   "the WG will maintain a list of DSCPs that are OK", while the
> >   beginning of appendix A.1 says "the WG decided to not define with
> >   which DSCPs PCN can be used" (but then the end of A.1 talks about
> >   maintaining a list again.) Which is it? If there is to be a list,
> > you
> >   need to create an IANA registry, write management procedures for
it
> >   (see RFC5226) and populate it with some initial values. (WGs are
> >   ephemeral, which is why the PCN WG can't be the maintainer of this
> >   list, IANA has to be.) If you want to leave it fully open for
> >   deployments, you need to remove this confusion from the text.
> >
> > Lars
> >
> >
> > Nits:
> >
> > Section 4., paragraph 3:
> >>           &n= bsp;      to prevent future compatability issues.
> >
> >   Nit: s/compatability/compatibility/
> >
> >
> > Section 4.2., paragraph 1:
> >>   that is guaranteeed to be copied down into the inner header upon
> >
> >   Nit: s/guaranteeed/guaranteed/
> >
> >
> > Section 6., paragraph 1:
> >>   always copy the CE codepoint from teh outer header into the inner
> >
> >   Nit: s/teh/the/
> >
> >
> > Section 6., paragraph 2:
> >>   header in decapsulation (unless the inner packet is not-ECT).
> > If an
> >>   operator it is essential that any operator wishing to allow ECN
to
> >>   exist end-to-end ensures there are no tunnel end-points within
the
> >>   PCN-domain.
> >
> >   "If an operator it is essential that any operator..." - wording
> >
> >
> > Section 12., paragraph 0:
> >> 12.  References
> >
> >   Should be updated; see idnits report.
> >
> >
> > Appendix A., paragraph 2:
> >>   a given PCN-domain is dependant on the nature of the traffic
> > entering
> >
> >   Nit: s/dependant/dependent/
> >
> > <smime.p7s><ATT00001.txt>

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn
From toby.moncaster@bt.com Wed Aug 19 01:40: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 B29A628C37C for ; Wed, 19 Aug 2009 01:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 o4iX+C7Ah1ww for ; Wed, 19 Aug 2009 01:40:35 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1EB4828C0E7 for ; Wed, 19 Aug 2009 01:40:32 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 09:40:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA20A8.A93E11A6" x-cr-hashedpuzzle: D+Ch EcsY Gsl4 ISlA Jxo7 J//h Kbiu Kdzi NIH+ OdaM QE4y QJi5 Wp2R Wr6u XK3o XuOY; 2; cABjAG4AQABpAGUAdABmAC4AbwByAGcAOwByAHUAZQBkAGkAZwBlAHIALgBnAGUAaQBiAEAAdABlAGwAZQBrAG8AbQAuAGQAZQA=; Sosha1_v1; 7; {31429428-30E9-4025-BE7C-C801B2C1BBF9}; dABvAGIAeQAuAG0AbwBuAGMAYQBzAHQAZQByAEAAYgB0AC4AYwBvAG0A; Wed, 19 Aug 2009 08:39:55 GMT; UgBFADoAIABbAFAAQwBOAF0AIABBAEQAIAByAGUAdgBpAGUAdwA6ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHAAYwBuAC0AYgBhAHMAZQBsAGkAbgBlAC0AZQBuAGMAbwBkAGkAbgBnAC0AMAA0AA== x-cr-puzzleid: {31429428-30E9-4025-BE7C-C801B2C1BBF9} Content-class: urn:content-classes:message Date: Wed, 19 Aug 2009 09:39:55 +0100 Message-ID: In-Reply-To: <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: AcogpzBPkb2NaPlYQJ+BY2AEvXTCfAAAMhYA References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> From: To: , X-OriginalArrivalTime: 19 Aug 2009 08:40:36.0535 (UTC) FILETIME=[B916BC70:01CA20A8] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 08:40:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA20A8.A93E11A6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That ASCII art is still unreadable because (for me at least) it is = getting displayed in a variable-width font (Times New Roman to be = exact). I ended up having to convert it to Courier to be able to see = what you meant... =20 I am in the process of drafting a reply setting out the background to = this confusion and hopefully solving it. In the meantime there seems to = be a consensus that the way ahead is to recommend PCN as suitable for 1 = or more EXISTING DSCPs (which means we need to decide which ones...). = But that still leaves the question of whether we need to say something = about what needs to happen in the future if someone (say Fred Baker) = wants to add PCN to a new DSCP. =20 Toby =20 From: Briscoe,RJ,Bob,XVR9 BRISCORJ R=20 Sent: 19 August 2009 09:29 To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 =20 Ruediger, Great. [As some people couldn't read it, I've also replaced the diag quoted in = the thread below with narrower ASCII-art to better survive word wrap] Cheers Bob At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: Hi Bob, =20 I agree to your suggestion to "scrub (ii) and only have (i)..[and that] = we should list classes that might be appropriate to associate with PCN = marking." =20 Regards, =20 Ruediger ________________________________ From: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk = ]=20 Sent: Tuesday, August 18, 2009 7:37 PM To: Geib, R=FCdiger; toby.moncaster@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Ruediger, The draft as it stands holds two inconsistent opinions: i) " the aim is for PCN to re-use existing DSCPs " (S.4.3.1) ii) the second half of Appx A.1, repeated below. Similarly, your posting, talks about: i) applying PCN to existing DSCPs ii) reserving DSCPs for PCN. I believe we should scrub (ii) and only have (i). In place of ii) we = should list the classes that might be appropriate to associate with PCN = marking. In other words, we should only say that an operator _applies_ PCN = marking to certain existing DSCPs. No-one needs any additional DSCPs to enable PCN marking. Otherwise that = would waste DSCPs just to get a different marking behaviour for packets = requiring the same scheduling behaviour as a pre-existing DSCP. The = non-wasteful way to do this is to use one DSCP for a certain scheduling = behaviour, but set the ECN field to a non-zero value to turn on PCN = marking (S.4.3.1). [In MPLS, as there is no ECN field, the efficient way is different. Then = RFC5129 describes how you would do it.] To be absolutely sure it's clear what I mean, here's an example: hi stat mux subnet ___________________ | same | | marking | | _____ ____:___ | | | || || --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- | | || || --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- | | ||________|| | | | | --DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- | |_____| | | _____ | | | | | --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ | | | | --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- | |_____| | | : | | same | | scheduling | | (BA) | |___________________| - The text on each flow shows the DSCP-ECN combination used for that = segment - The boxes around DSCPA/B/C and around DSCPD/E represent the same = scheduling behaviour applied to multiple DSCPs in the aggregated region = (a behaviour aggregate). - The box around NM for the first two flows represents the same marking = behaviour (PCN) applied to multiple DSCPs. - The flows keep the same DSCP* along their whole path, so when they pop = out into the lo-stat-mux region on the other side, the DSCP is = preserved. - In practice, traffic might be tunnelled across the hi-stat mux region, = and at the same time common scheduling behaviours might be mapped to a = single DSCP in the outer headers. The diagram merely shows everything = can be done without tunnelling or layering. * Note: For some non-standardised DSCPs, the DSCP might not actually = stay the same along the whole path. It might be mapped to local DSCPs = that are each used for the same class at different points along the = path. Here's a copy of the 2nd half of Appx A.1, that I think needs to be removed (sorry, I know I'm a co-author, but...): " The choice of which DSCP is most suitable for a given PCN-domain is dependant on the nature of the traffic entering that domain and the link rates of all the links making up that domain. In PCN-domains with uniformly high link rates, the appropriate DSCPs would currently be those for the Real Time Traffic Class [RFC5127 ]. If the PCN domain includes lower speed links it would also be appropriate to use the DSCPs of the other traffic classes that [ = =20 Voice-Admit = ] defines for use with admission control, such as the three video classes CS4, CS3 and AF4 and the Admitted Telephony Class. The PCN working group will maintain a list of PCN- compatible Diffserv Codepoints. " At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: Toby, PCN should express to the IANA, whether one or more new DSCP is=20 required to operate or carry out experiments on PCN. As soon as IANA maintains a list of DSCPs for any purpose, this=20 will have the status of a standard.=20 "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs=20 per traffic class (DSCP bit 0-2, let's call them traffic class=20 in this email) for PCN, that's 32 DSCPs in all. If possible, PCN should limit the number of traffic classes,=20 where to apply PCN. I don't think PCN will be applied in traffic classes 0 and 6. I'd expect PCN to be used within traffic classes 5 and 4,=20 may be also 3 or 2. Traffic classes 1 and 7 may be excluded too. The above clearly expresses personal views, but informational=20 RFC5127 to some extent backs these personal views. I'm aware that PCN WG shouldn't standardise traffic class usage=20 or come close to that. I however want to avoid repeating the biggest=20 flaw of the AF specification, which in my eyes is to reserve=20 12 DSCPs for 4 traffic classes. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com Sent: Friday, August 14, 2009 3:06 PM To: lars.eggert@nokia.com; pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Hi Lars, Sorry not to get back to you earlier - been busy at work so this went on a back-burner for a few days.=20 The original intention of having registration was to avoid confusion during any early experimental adoption of PCN however that could be done purely unofficially by having a list of DSCPs on the IETF wiki and just politely asking developers to consult it and add any new ones they are using. But there will need in future to be a process to formally register certain standards (pool 1) DSCPs as PCN-compatible since this effectively replaces ECN as the default behaviour for such DSCPs. So my suggestion is: Change the IANA section to say something along the following lines (I will get IANA assistance with crafting exact text): "IANA will be asked to set up a registry of PCN-compatible Diffserv codepoints. The decision as to whether to enable PCN for a given pool 1 codepoint must be made by the appropriate IETF Transport Area Working Group (TSVWG?) which will then request IANA to add this to the registry." Clarify at start of A.1 that the decision of which DSCPs to apply PCN to has to be made by TSVWG and is separate to this document which just defines the process and the encoding. Change the last sentence of A.1 to "IANA will maintain a list of PCN-compatible Diffserv Codepoints." Would this cover things appropriately? I did wonder about asking IANA to maintain the experimental registry but I am not sure if they are able to do that sort of thing? If so the following could be added to the IANA section: "During the early stages of adoption it is envisaged that PCN will be used experimentally using pool 2 or 3 DSCPs (experimental or local use). Whilst these DSCPs are not controlled by IANA normally, a request will be made to maintain a list of PCN experiments along with the DSCPs these experiments are using." Once I get the nod from WG I will release a new version of the I-D with these updates... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 14 August 2009 12:27 > To: pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm waiting to hear from the authors/WG. >=20 > Lars >=20 > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, > > > > this document is ready, except for one issue: > > > > Section 7., paragraph 1: > >> This document makes no direct request to IANA. However this > > document > >> allows for a set of Diffserv Codepoints to be assigned different > > ECN > >> semantics within a controlled domain as described in [RFC4774]. A > >> list of such DSCPs will be maintained by the PCN working group. > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > says > > "the WG will maintain a list of DSCPs that are OK", while the > > beginning of appendix A.1 says "the WG decided to not define with > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > maintaining a list again.) Which is it? If there is to be a list, > > you > > need to create an IANA registry, write management procedures for it > > (see RFC5226) and populate it with some initial values. (WGs are > > ephemeral, which is why the PCN WG can't be the maintainer of this > > list, IANA has to be.) If you want to leave it fully open for > > deployments, you need to remove this confusion from the text. > > > > Lars > > > > > > Nits: > > > > Section 4., paragraph 3: > >> to prevent future compatability issues. > > > > Nit: s/compatability/compatibility/ > > > > > > Section 4.2., paragraph 1: > >> that is guaranteeed to be copied down into the inner header upon > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > Section 6., paragraph 1: > >> always copy the CE codepoint from teh outer header into the inner > > > > Nit: s/teh/the/ > > > > > > Section 6., paragraph 2: > >> header in decapsulation (unless the inner packet is not-ECT). > > If an > >> operator it is essential that any operator wishing to allow ECN to > >> exist end-to-end ensures there are no tunnel end-points within the > >> PCN-domain. > > > > "If an operator it is essential that any operator..." - wording > > > > > > Section 12., paragraph 0: > >> 12. References > > > > Should be updated; see idnits report. > > > > > > Appendix A., paragraph 2: > >> a given PCN-domain is dependant on the nature of the traffic > > entering > > > > Nit: s/dependant/dependent/ > > > > _______________________________________________ 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 ------_=_NextPart_001_01CA20A8.A93E11A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

That ASCII art is still unreadable because (for me at least) it is getting = displayed in a variable-width font (Times New Roman to be exact). I ended up = having to convert it to Courier to be able to see what you = meant…

 

I am in the process of drafting a reply setting out the background to this confusion and hopefully solving it. In the meantime there seems to be a consensus that the way ahead is to recommend PCN as suitable for 1 or = more EXISTING DSCPs (which means we need to decide which ones…). But = that still leaves the question of whether we need to say something about what = needs to happen in the future if someone (say Fred Baker) wants to add PCN to = a new DSCP.

 

Toby

 

From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009 09:29
To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R
Cc: pcn@ietf.org
Subject: RE: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04

 

Ruediger,

Great.

[As some people couldn't read it, I've also replaced the diag quoted in = the thread below with narrower ASCII-art to better survive word wrap]

Cheers


Bob

At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote:

Hi Bob,
 
I agree to your suggestion to "scrub (ii) and only have (i)..[and = that] we should list classes that might be appropriate to associate with PCN marking."
 
Re= gards,
 
Ru= ediger

From:= Bob = Briscoe [ = mailto:rbriscoe@jungle.bt.co.uk]
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, R=FCdiger; toby.moncaster@bt.com
Cc: pcn@ietf.org
Subject: Re: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04

Ruediger,

The draft as it stands holds two inconsistent opinions:
i) "

the aim is for PCN to re-use existing DSCPs


" (S.4.3.1)
ii) the second half of Appx A.1, repeated below.

Similarly, your posting, talks about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for PCN.

I believe we should scrub (ii) and only have (i). In place of ii) we = should list the classes that might be appropriate to associate with PCN = marking.

In other words, we should only say that an operator _applies_ PCN = marking to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that = would waste DSCPs just to get a different marking behaviour for packets = requiring the same scheduling behaviour as a pre-existing DSCP. The non-wasteful way = to do this is to use one DSCP for a certain scheduling behaviour, but set the = ECN field to a non-zero value to turn on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the efficient way is different. Then RFC5129 describes how you would do it.]

To be absolutely sure it's clear what I mean, here's an = example:


            &= nbsp;      hi stat mux subnet
            &= nbsp;      ___________________
            &= nbsp;     |            same   |
            &= nbsp;     |           marking = |
            &= nbsp;     |   _____  ____:___ |
            &= nbsp;     |  |     = ||        ||
--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
            &= nbsp;     |  |     = ||        ||
--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
            &= nbsp;     |  |     ||________||
            &= nbsp;     |  |     |          |
--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
            &= nbsp;     |  |_____|          = |
            &= nbsp;     |   = _____           |
            &= nbsp;     |  |     |          |
--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
            &= nbsp;     |  |     |          |
--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
            &= nbsp;     |  |_____|          = |
            &= nbsp;     |     :            = |
            &= nbsp;     |   same            = |
            &= nbsp;     | scheduling        |
            &= nbsp;     |   (BA)            = |
            &= nbsp;     |___________________|


- The text on each = flow shows the DSCP-ECN combination used for that segment
- The boxes around DSCPA/B/C and around DSCPD/E represent the same = scheduling behaviour applied to multiple DSCPs in the aggregated region (a = behaviour aggregate).
- The box around NM for the first two flows represents the same marking behaviour (PCN) applied to multiple DSCPs.
- The flows keep the same DSCP* along their whole path, so when they pop = out into the lo-stat-mux region on the other side, the DSCP is = preserved.
- In practice, traffic might be tunnelled across the hi-stat mux region, = and at the same time common scheduling behaviours might be mapped to a single = DSCP in the outer headers. The diagram merely shows everything can be done = without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually = stay the same along the whole path. It might be mapped to local DSCPs that are = each used for the same class at different points along the path.


Here's a copy of the 2nd half of Appx A.1, that I think needs to =
be
removed (sorry, I know I'm a co-author, =
but...):
"  The choice of which DSCP is =
most suitable for
   a given PCN-domain =
is dependant on the nature of =
the
traffic
entering=

   that domain and the link rates of all the links =
making up
that
   =
domain.  In PCN-domains with uniformly high =
link
rates,
the
   appropriate DSCPs would currently be those for the =
Real
Time
Traffic
   Class
[RFC5127].  If =
the
PCN domain includes lower speed links =
it
   would also be appropriate to use =
the DSCPs of the =
other
traffic
   =
classes that
[
Voice-Admit] defines for use with admission =
control,
   such as the three video =
classes CS4, CS3 and AF4 and =
the
Admitted
   =
Telephony Class.  The PCN working group will =
maintain
a
list of =
PCN-
   compatible Diffserv =
Codepoints.





"



At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:



Toby,



PCN should express to the IANA, whether one or more new DSCP is 

required to operate or carry out experiments on PCN.



As soon as IANA maintains a list of DSCPs for any purpose, this 

will have the status of a standard. 



"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs =


per traffic class (DSCP bit 0-2, let's call them traffic class 

in this email) for PCN, that's 32 DSCPs in all.



If possible, PCN should limit the number of traffic classes, 

where to apply PCN.



I don't think PCN will be applied in traffic classes 0 and 6.



I'd expect PCN to be used within traffic classes 5 and 4, 

may be also 3 or 2.



Traffic classes 1 and 7 may be excluded too.



The above clearly expresses personal views, but informational 

RFC5127 to some extent backs these personal views.



I'm aware that PCN WG shouldn't standardise traffic class usage 

or come close to that. I however want to avoid repeating the biggest =


flaw of the AF specification, which in my eyes is to reserve 

12 DSCPs for 4 traffic classes.



Regards,



Ruediger







-----Original Message-----

From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org]
On Behalf Of toby.moncaster@bt.com

Sent: Friday, August 14, 2009 3:06 PM

To: lars.eggert@nokia.com; pcn@ietf.org

Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04



Hi Lars,



Sorry not to get back to you earlier - been busy at work so this went =
on

a back-burner for a few days. 



The original intention of having registration was to avoid confusion

during any early experimental adoption of PCN however that could be =
done

purely unofficially by having a list of DSCPs on the IETF wiki and =
just

politely asking developers to consult it and add any new ones they =
are

using. But there will need in future to be a process to formally

register certain standards (pool 1) DSCPs as PCN-compatible since =
this

effectively replaces ECN as the default  behaviour for such DSCPs. =
So my

suggestion is:



Change the IANA section to say something along the following lines =
(I

will get IANA assistance with crafting exact text):



"IANA will be asked to set up a registry of PCN-compatible =
Diffserv

codepoints. The decision as to whether to enable PCN for a given pool =
1

codepoint must be made by the appropriate IETF Transport Area =
Working

Group (TSVWG?) which will then request IANA to add this to the

registry."



Clarify at start of A.1 that the decision of which DSCPs to apply PCN =
to

has to be made by TSVWG and is separate to this document which just

defines the process and the encoding.



Change the last sentence of A.1 to "IANA will maintain a list =
of

PCN-compatible Diffserv Codepoints."



Would this cover things appropriately? I did wonder about asking IANA =
to

maintain the experimental registry but I am not sure if they are able =
to

do that sort of thing? If so the following could be added to the =
IANA

section:



"During the early stages of adoption it is envisaged that PCN will =
be

used experimentally using pool 2 or 3 DSCPs (experimental or local =
use).

Whilst these DSCPs are not controlled by IANA normally, a request =
will

be made to maintain a list of PCN experiments along with the DSCPs =
these

experiments are using."



Once I get the nod from WG I will release a new version of the I-D =
with

these updates...



Toby



> -----Original Message-----

> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org]
On Behalf Of

> Lars Eggert

> Sent: 14 August 2009 12:27

> To: pcn@ietf.org

> Subject: Re: [PCN] AD review: =
draft-ietf-pcn-baseline-encoding-04

> 

> Hi,

> 

> I'm waiting to hear from the authors/WG.

> 

> Lars

> 

> On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:

> 

> > Hi,

> >

> > this document is ready, except for one issue:

> >

> > Section 7., paragraph 1:

> >>   This document makes no direct request to =
IANA. 
However this

> > document

> >>   allows for a set of Diffserv Codepoints to be
assigned different

> > ECN

> >>   semantics within a controlled domain as =
described in
[RFC4774].

A

> >>   list of such DSCPs will be maintained by the =
PCN
working group.

> >

> >   DISCUSS: This text isn't aligned with appendix =
A.1. The
text here

> > says

> >   "the WG will maintain a list of DSCPs that =
are
OK", while the

> >   beginning of appendix A.1 says "the WG =
decided to
not define with

> >   which DSCPs PCN can be used" (but then the =
end of
A.1 talks about

> >   maintaining a list again.) Which is it? If there =
is to be
a list,

> > you

> >   need to create an IANA registry, write management
procedures for

it

> >   (see RFC5226) and populate it with some initial =
values.
(WGs are

> >   ephemeral, which is why the PCN WG can't be the
maintainer of this

> >   list, IANA has to be.) If you want to leave it =
fully open
for

> >   deployments, you need to remove this confusion =
from the
text.

> >

> > Lars

> >

> >

> > Nits:

> >

> > Section 4., paragraph 3:

>
>>           =
;      
to prevent future compatability issues.

> >

> >   Nit: s/compatability/compatibility/

> >

> >

> > Section 4.2., paragraph 1:

> >>   that is guaranteeed to be copied down into the =
inner
header upon

> >

> >   Nit: s/guaranteeed/guaranteed/

> >

> >

> > Section 6., paragraph 1:

> >>   always copy the CE codepoint from teh outer =
header
into the inner

> >

> >   Nit: s/teh/the/

> >

> >

> > Section 6., paragraph 2:

> >>   header in decapsulation (unless the inner =
packet is
not-ECT).

> > If an

> >>   operator it is essential that any operator =
wishing to
allow ECN

to

> >>   exist end-to-end ensures there are no tunnel
end-points within

the

> >>   PCN-domain.

> >

> >   "If an operator it is essential that any
operator..." - wording

> >

> >

> > Section 12., paragraph 0:

> >> 12.  References

> >

> >   Should be updated; see idnits report.

> >

> >

> > Appendix A., paragraph 2:

> >>   a given PCN-domain is dependant on the nature =
of the
traffic

> > entering

> >

> >   Nit: s/dependant/dependent/

> >

> > <smime.p7s><ATT00001.txt>



_______________________________________________

PCN mailing list

PCN@ietf.org

https://www.ietf.org/m=
ailman/listinfo/pcn

_______________________________________________

PCN mailing list

PCN@ietf.org

https://www.ietf.org/m=
ailman/listinfo/pcn
------_=_NextPart_001_01CA20A8.A93E11A6-- From menth@informatik.uni-wuerzburg.de Wed Aug 19 01:52:18 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F1D3A6BA7 for ; Wed, 19 Aug 2009 01:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbvd83hFImkZ for ; Wed, 19 Aug 2009 01:52:16 -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 B53EF3A68E6 for ; Wed, 19 Aug 2009 01:52:15 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 20CC8A0CEB; Wed, 19 Aug 2009 10:52:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1479FA0C7E; Wed, 19 Aug 2009 10:52:16 +0200 (CEST) Received: from [192.168.1.2] (e181183006.adsl.alicedsl.de [85.181.183.6]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A7B491994B2; Wed, 19 Aug 2009 10:52:15 +0200 (CEST) Message-ID: <4A8BBD24.10908@informatik.uni-wuerzburg.de> Date: Wed, 19 Aug 2009 10:51:48 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> In-Reply-To: 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] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 08:52:18 -0000 Hi, I'm not sure whether the ASCII art is needed at all and I did not really understand it. The following message arrived with me: PCN is locally applied to some specific DSCPs with the same scheduling behavior (I don't think that we can allow different one, this requires more study). If PCN marking applies to them, the ECN field of corresponding packets is set to an appropriate value by the ingress node, else it is set to 00. After leaving the domain, the PCN egress node clears the ECN field with 00. This way, no new DSCPs are needed for PCN. Or have I missed a critical point? Regards, Michael toby.moncaster@bt.com schrieb: > > That ASCII art is still unreadable because (for me at least) it is > getting displayed in a variable-width font (Times New Roman to be > exact). I ended up having to convert it to Courier to be able to see > what you meant… > > I am in the process of drafting a reply setting out the background to > this confusion and hopefully solving it. In the meantime there seems > to be a consensus that the way ahead is to recommend PCN as suitable > for 1 or more EXISTING DSCPs (which means we need to decide which > ones…). But that still leaves the question of whether we need to say > something about what needs to happen in the future if someone (say > Fred Baker) wants to add PCN to a new DSCP. > > Toby > > *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R > *Sent:* 19 August 2009 09:29 > *To:* Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R > *Cc:* pcn@ietf.org > *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > Ruediger, > > Great. > > [As some people couldn't read it, I've also replaced the diag quoted > in the thread below with narrower ASCII-art to better survive word wrap] > > Cheers > > > Bob > > At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: > > Hi Bob, > > I agree to your suggestion to "scrub (ii) and only have (i)..[and > that] we should list classes that might be appropriate to associate > with PCN marking." > > Regards, > > Ruediger > > ------------------------------------------------------------------------ > > *From:* Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk] > *Sent:* Tuesday, August 18, 2009 7:37 PM > *To:* Geib, Rüdiger; toby.moncaster@bt.com > *Cc:* pcn@ietf.org > *Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > Ruediger, > > The draft as it stands holds two inconsistent opinions: > i) " > > the aim is for PCN to re-use existing DSCPs > > > " (S.4.3.1) > ii) the second half of Appx A.1, repeated below. > > Similarly, your posting, talks about: > i) applying PCN to existing DSCPs > ii) reserving DSCPs for PCN. > > I believe we should scrub (ii) and only have (i). In place of ii) we > should list the classes that might be appropriate to associate with > PCN marking. > > In other words, we should only say that an operator _applies_ PCN > marking to certain existing DSCPs. > > No-one needs any additional DSCPs to enable PCN marking. Otherwise > that would waste DSCPs just to get a different marking behaviour for > packets requiring the same scheduling behaviour as a pre-existing > DSCP. The non-wasteful way to do this is to use one DSCP for a certain > scheduling behaviour, but set the ECN field to a non-zero value to > turn on PCN marking (S.4.3.1). > > [In MPLS, as there is no ECN field, the efficient way is different. > Then RFC5129 describes how you would do it.] > > To be absolutely sure it's clear what I mean, here's an example: > > > hi stat mux subnet > ___________________ > | same | > | marking | > | _____ ____:___ | > | | || || > --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- > | | || || > --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- > | | ||________|| > | | | | > --DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- > | |_____| | > | _____ | > | | | | > --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ > | | | | > --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- > | |_____| | > | : | > | same | > | scheduling | > | (BA) | > |___________________| > > > - The text on each flow shows the DSCP-ECN combination used for that > segment > - The boxes around DSCPA/B/C and around DSCPD/E represent the same > scheduling behaviour applied to multiple DSCPs in the aggregated > region (a behaviour aggregate). > - The box around NM for the first two flows represents the same > marking behaviour (PCN) applied to multiple DSCPs. > - The flows keep the same DSCP* along their whole path, so when they > pop out into the lo-stat-mux region on the other side, the DSCP is > preserved. > - In practice, traffic might be tunnelled across the hi-stat mux > region, and at the same time common scheduling behaviours might be > mapped to a single DSCP in the outer headers. The diagram merely shows > everything can be done without tunnelling or layering. > > * Note: For some non-standardised DSCPs, the DSCP might not actually > stay the same along the whole path. It might be mapped to local DSCPs > that are each used for the same class at different points along the path. > > > Here's a copy of the 2nd half of Appx A.1, that I think needs to be > removed (sorry, I know I'm a co-author, but...): > " The choice of which DSCP is most suitable for > a given PCN-domain is dependant on the nature of the > traffic > entering > that domain and the link rates of all the links making up > that > domain. In PCN-domains with uniformly high link > rates, > the > appropriate DSCPs would currently be those for the Real > Time > Traffic > Class > [RFC5127 ]. If the > PCN domain includes lower speed links it > would also be appropriate to use the DSCPs of the other > traffic > classes that > [ > Voice-Admit ] defines for use with admission control, > such as the three video classes CS4, CS3 and AF4 and the > Admitted > Telephony Class. The PCN working group will maintain > a > list of PCN- > compatible Diffserv Codepoints. > > > " > > At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: > > Toby, > > PCN should express to the IANA, whether one or more new DSCP is > required to operate or carry out experiments on PCN. > > As soon as IANA maintains a list of DSCPs for any purpose, this > will have the status of a standard. > > "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs > per traffic class (DSCP bit 0-2, let's call them traffic class > in this email) for PCN, that's 32 DSCPs in all. > > If possible, PCN should limit the number of traffic classes, > where to apply PCN. > > I don't think PCN will be applied in traffic classes 0 and 6. > > I'd expect PCN to be used within traffic classes 5 and 4, > may be also 3 or 2. > > Traffic classes 1 and 7 may be excluded too. > > The above clearly expresses personal views, but informational > RFC5127 to some extent backs these personal views. > > I'm aware that PCN WG shouldn't standardise traffic class usage > or come close to that. I however want to avoid repeating the biggest > flaw of the AF specification, which in my eyes is to reserve > 12 DSCPs for 4 traffic classes. > > Regards, > > Ruediger > > > > -----Original Message----- > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of > toby.moncaster@bt.com > Sent: Friday, August 14, 2009 3:06 PM > To: lars.eggert@nokia.com; pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > Hi Lars, > > Sorry not to get back to you earlier - been busy at work so this went on > a back-burner for a few days. > > The original intention of having registration was to avoid confusion > during any early experimental adoption of PCN however that could be done > purely unofficially by having a list of DSCPs on the IETF wiki and just > politely asking developers to consult it and add any new ones they are > using. But there will need in future to be a process to formally > register certain standards (pool 1) DSCPs as PCN-compatible since this > effectively replaces ECN as the default behaviour for such DSCPs. So my > suggestion is: > > Change the IANA section to say something along the following lines (I > will get IANA assistance with crafting exact text): > > "IANA will be asked to set up a registry of PCN-compatible Diffserv > codepoints. The decision as to whether to enable PCN for a given pool 1 > codepoint must be made by the appropriate IETF Transport Area Working > Group (TSVWG?) which will then request IANA to add this to the > registry." > > Clarify at start of A.1 that the decision of which DSCPs to apply PCN to > has to be made by TSVWG and is separate to this document which just > defines the process and the encoding. > > Change the last sentence of A.1 to "IANA will maintain a list of > PCN-compatible Diffserv Codepoints." > > Would this cover things appropriately? I did wonder about asking IANA to > maintain the experimental registry but I am not sure if they are able to > do that sort of thing? If so the following could be added to the IANA > section: > > "During the early stages of adoption it is envisaged that PCN will be > used experimentally using pool 2 or 3 DSCPs (experimental or local use). > Whilst these DSCPs are not controlled by IANA normally, a request will > be made to maintain a list of PCN experiments along with the DSCPs these > experiments are using." > > Once I get the nod from WG I will release a new version of the I-D with > these updates... > > Toby > > > -----Original Message----- > > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of > > Lars Eggert > > Sent: 14 August 2009 12:27 > > To: pcn@ietf.org > > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > > > Hi, > > > > I'm waiting to hear from the authors/WG. > > > > Lars > > > > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: > > > > > Hi, > > > > > > this document is ready, except for one issue: > > > > > > Section 7., paragraph 1: > > >> This document makes no direct request to IANA. However this > > > document > > >> allows for a set of Diffserv Codepoints to be assigned different > > > ECN > > >> semantics within a controlled domain as described in [RFC4774]. > A > > >> list of such DSCPs will be maintained by the PCN working group. > > > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > > says > > > "the WG will maintain a list of DSCPs that are OK", while the > > > beginning of appendix A.1 says "the WG decided to not define with > > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > > maintaining a list again.) Which is it? If there is to be a list, > > > you > > > need to create an IANA registry, write management procedures for > it > > > (see RFC5226) and populate it with some initial values. (WGs are > > > ephemeral, which is why the PCN WG can't be the maintainer of this > > > list, IANA has to be.) If you want to leave it fully open for > > > deployments, you need to remove this confusion from the text. > > > > > > Lars > > > > > > > > > Nits: > > > > > > Section 4., paragraph 3: > > >> to prevent future compatability issues. > > > > > > Nit: s/compatability/compatibility/ > > > > > > > > > Section 4.2., paragraph 1: > > >> that is guaranteeed to be copied down into the inner header upon > > > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > > > > Section 6., paragraph 1: > > >> always copy the CE codepoint from teh outer header into the inner > > > > > > Nit: s/teh/the/ > > > > > > > > > Section 6., paragraph 2: > > >> header in decapsulation (unless the inner packet is not-ECT). > > > If an > > >> operator it is essential that any operator wishing to allow ECN > to > > >> exist end-to-end ensures there are no tunnel end-points within > the > > >> PCN-domain. > > > > > > "If an operator it is essential that any operator..." - wording > > > > > > > > > Section 12., paragraph 0: > > >> 12. References > > > > > > Should be updated; see idnits report. > > > > > > > > > Appendix A., paragraph 2: > > >> a given PCN-domain is dependant on the nature of the traffic > > > entering > > > > > > Nit: s/dependant/dependent/ > > > > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- 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 Aug 19 02:19:28 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 747FB3A69A6 for ; Wed, 19 Aug 2009 02:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zppBUPZTIWny for ; Wed, 19 Aug 2009 02:19:26 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id BDA0C28C3B0 for ; Wed, 19 Aug 2009 02:19:21 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 10:19:25 +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: Wed, 19 Aug 2009 10:19:06 +0100 Message-ID: In-Reply-To: <4A8BBD24.10908@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: Acogqlzu7riAksc0QCSL691ASOOKDwAA2Q+w References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <4A8BBD24.10908@informatik.uni-wuerzburg.de> From: To: X-OriginalArrivalTime: 19 Aug 2009 09:19:25.0873 (UTC) FILETIME=[257B8210:01CA20AE] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 09:19:28 -0000 Certainly that is correct for baseline. In other words all we are doing = is proposing PCN as an alternative marking behaviour that doesn't affect = any other aspect of DiffServ directly... That still leaves the question of which DSCPs will we initially = recommend might benefit from it (Lars is keen we should mention at least = one so PCN can get deployed) Toby > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 19 August 2009 09:52 > To: Moncaster,T,Toby,DER3 R > Cc: Briscoe,RJ,Bob,XVR9 BRISCORJ R; Ruediger.Geib@telekom.de; > pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm not sure whether the ASCII art is needed at all and I did not > really > understand it. The following message arrived with me: >=20 > PCN is locally applied to some specific DSCPs with the same scheduling > behavior (I don't think that we can allow different one, this requires > more study). If PCN marking applies to them, the ECN field of > corresponding packets is set to an appropriate value by the ingress > node, else it is set to 00. After leaving the domain, the PCN egress > node clears the ECN field with 00. This way, no new DSCPs are needed > for > PCN. >=20 > Or have I missed a critical point? >=20 > Regards, >=20 > Michael >=20 >=20 >=20 > toby.moncaster@bt.com schrieb: > > > > That ASCII art is still unreadable because (for me at least) it is > > getting displayed in a variable-width font (Times New Roman to be > > exact). I ended up having to convert it to Courier to be able to see > > what you meant... > > > > I am in the process of drafting a reply setting out the background = to > > this confusion and hopefully solving it. In the meantime there seems > > to be a consensus that the way ahead is to recommend PCN as suitable > > for 1 or more EXISTING DSCPs (which means we need to decide which > > ones...). But that still leaves the question of whether we need to = say > > something about what needs to happen in the future if someone (say > > Fred Baker) wants to add PCN to a new DSCP. > > > > Toby > > > > *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R > > *Sent:* 19 August 2009 09:29 > > *To:* Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R > > *Cc:* pcn@ietf.org > > *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > > > Ruediger, > > > > Great. > > > > [As some people couldn't read it, I've also replaced the diag quoted > > in the thread below with narrower ASCII-art to better survive word > wrap] > > > > Cheers > > > > > > Bob > > > > At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: > > > > Hi Bob, > > > > I agree to your suggestion to "scrub (ii) and only have (i)..[and > > that] we should list classes that might be appropriate to associate > > with PCN marking." > > > > Regards, > > > > Ruediger > > > > = --------------------------------------------------------------------- > --- > > > > *From:* Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk] > > *Sent:* Tuesday, August 18, 2009 7:37 PM > > *To:* Geib, R=FCdiger; toby.moncaster@bt.com > > *Cc:* pcn@ietf.org > > *Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > > > Ruediger, > > > > The draft as it stands holds two inconsistent opinions: > > i) " > > > > the aim is for PCN to re-use existing DSCPs > > > > > > " (S.4.3.1) > > ii) the second half of Appx A.1, repeated below. > > > > Similarly, your posting, talks about: > > i) applying PCN to existing DSCPs > > ii) reserving DSCPs for PCN. > > > > I believe we should scrub (ii) and only have (i). In place of ii) we > > should list the classes that might be appropriate to associate with > > PCN marking. > > > > In other words, we should only say that an operator _applies_ PCN > > marking to certain existing DSCPs. > > > > No-one needs any additional DSCPs to enable PCN marking. Otherwise > > that would waste DSCPs just to get a different marking behaviour for > > packets requiring the same scheduling behaviour as a pre-existing > > DSCP. The non-wasteful way to do this is to use one DSCP for a > certain > > scheduling behaviour, but set the ECN field to a non-zero value to > > turn on PCN marking (S.4.3.1). > > > > [In MPLS, as there is no ECN field, the efficient way is different. > > Then RFC5129 describes how you would do it.] > > > > To be absolutely sure it's clear what I mean, here's an example: > > > > > > hi stat mux subnet > > ___________________ > > | same | > > | marking | > > | _____ ____:___ | > > | | || || > > --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- > > | | || || > > --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- > > | | ||________|| > > | | | | > > --DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- > > | |_____| | > > | _____ | > > | | | | > > --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ > > | | | | > > --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- > > | |_____| | > > | : | > > | same | > > | scheduling | > > | (BA) | > > |___________________| > > > > > > - The text on each flow shows the DSCP-ECN combination used for that > > segment > > - The boxes around DSCPA/B/C and around DSCPD/E represent the same > > scheduling behaviour applied to multiple DSCPs in the aggregated > > region (a behaviour aggregate). > > - The box around NM for the first two flows represents the same > > marking behaviour (PCN) applied to multiple DSCPs. > > - The flows keep the same DSCP* along their whole path, so when they > > pop out into the lo-stat-mux region on the other side, the DSCP is > > preserved. > > - In practice, traffic might be tunnelled across the hi-stat mux > > region, and at the same time common scheduling behaviours might be > > mapped to a single DSCP in the outer headers. The diagram merely > shows > > everything can be done without tunnelling or layering. > > > > * Note: For some non-standardised DSCPs, the DSCP might not actually > > stay the same along the whole path. It might be mapped to local = DSCPs > > that are each used for the same class at different points along the > path. > > > > > > Here's a copy of the 2nd half of Appx A.1, that I think needs to be > > removed (sorry, I know I'm a co-author, but...): > > " The choice of which DSCP is most suitable for > > a given PCN-domain is dependant on the nature of the > > traffic > > entering > > that domain and the link rates of all the links making up > > that > > domain. In PCN-domains with uniformly high link > > rates, > > the > > appropriate DSCPs would currently be those for the Real > > Time > > Traffic > > Class > > [RFC5127 ]. If the > > PCN domain includes lower speed links it > > would also be appropriate to use the DSCPs of the other > > traffic > > classes that > > [ 04#ref-Voice-Admit> > > Voice-Admit encoding-04#ref-Voice-Admit>] defines for use with admission control, > > such as the three video classes CS4, CS3 and AF4 and the > > Admitted > > Telephony Class. The PCN working group will maintain > > a > > list of PCN- > > compatible Diffserv Codepoints. > > > > > > " > > > > At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: > > > > Toby, > > > > PCN should express to the IANA, whether one or more new DSCP is > > required to operate or carry out experiments on PCN. > > > > As soon as IANA maintains a list of DSCPs for any purpose, this > > will have the status of a standard. > > > > "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs > > per traffic class (DSCP bit 0-2, let's call them traffic class > > in this email) for PCN, that's 32 DSCPs in all. > > > > If possible, PCN should limit the number of traffic classes, > > where to apply PCN. > > > > I don't think PCN will be applied in traffic classes 0 and 6. > > > > I'd expect PCN to be used within traffic classes 5 and 4, > > may be also 3 or 2. > > > > Traffic classes 1 and 7 may be excluded too. > > > > The above clearly expresses personal views, but informational > > RFC5127 to some extent backs these personal views. > > > > I'm aware that PCN WG shouldn't standardise traffic class usage > > or come close to that. I however want to avoid repeating the biggest > > flaw of the AF specification, which in my eyes is to reserve > > 12 DSCPs for 4 traffic classes. > > > > Regards, > > > > Ruediger > > > > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf > Of > > toby.moncaster@bt.com > > Sent: Friday, August 14, 2009 3:06 PM > > To: lars.eggert@nokia.com; pcn@ietf.org > > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > > > Hi Lars, > > > > Sorry not to get back to you earlier - been busy at work so this = went > on > > a back-burner for a few days. > > > > The original intention of having registration was to avoid confusion > > during any early experimental adoption of PCN however that could be > done > > purely unofficially by having a list of DSCPs on the IETF wiki and > just > > politely asking developers to consult it and add any new ones they > are > > using. But there will need in future to be a process to formally > > register certain standards (pool 1) DSCPs as PCN-compatible since > this > > effectively replaces ECN as the default behaviour for such DSCPs. So > my > > suggestion is: > > > > Change the IANA section to say something along the following lines = (I > > will get IANA assistance with crafting exact text): > > > > "IANA will be asked to set up a registry of PCN-compatible Diffserv > > codepoints. The decision as to whether to enable PCN for a given = pool > 1 > > codepoint must be made by the appropriate IETF Transport Area = Working > > Group (TSVWG?) which will then request IANA to add this to the > > registry." > > > > Clarify at start of A.1 that the decision of which DSCPs to apply = PCN > to > > has to be made by TSVWG and is separate to this document which just > > defines the process and the encoding. > > > > Change the last sentence of A.1 to "IANA will maintain a list of > > PCN-compatible Diffserv Codepoints." > > > > Would this cover things appropriately? I did wonder about asking = IANA > to > > maintain the experimental registry but I am not sure if they are = able > to > > do that sort of thing? If so the following could be added to the = IANA > > section: > > > > "During the early stages of adoption it is envisaged that PCN will = be > > used experimentally using pool 2 or 3 DSCPs (experimental or local > use). > > Whilst these DSCPs are not controlled by IANA normally, a request > will > > be made to maintain a list of PCN experiments along with the DSCPs > these > > experiments are using." > > > > Once I get the nod from WG I will release a new version of the I-D > with > > these updates... > > > > Toby > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On = Behalf > Of > > > Lars Eggert > > > Sent: 14 August 2009 12:27 > > > To: pcn@ietf.org > > > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > > > > > Hi, > > > > > > I'm waiting to hear from the authors/WG. > > > > > > Lars > > > > > > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: > > > > > > > Hi, > > > > > > > > this document is ready, except for one issue: > > > > > > > > Section 7., paragraph 1: > > > >> This document makes no direct request to IANA. However this > > > > document > > > >> allows for a set of Diffserv Codepoints to be assigned = different > > > > ECN > > > >> semantics within a controlled domain as described in [RFC4774]. > > A > > > >> list of such DSCPs will be maintained by the PCN working group. > > > > > > > > DISCUSS: This text isn't aligned with appendix A.1. The text = here > > > > says > > > > "the WG will maintain a list of DSCPs that are OK", while the > > > > beginning of appendix A.1 says "the WG decided to not define = with > > > > which DSCPs PCN can be used" (but then the end of A.1 talks = about > > > > maintaining a list again.) Which is it? If there is to be a = list, > > > > you > > > > need to create an IANA registry, write management procedures for > > it > > > > (see RFC5226) and populate it with some initial values. (WGs are > > > > ephemeral, which is why the PCN WG can't be the maintainer of > this > > > > list, IANA has to be.) If you want to leave it fully open for > > > > deployments, you need to remove this confusion from the text. > > > > > > > > Lars > > > > > > > > > > > > Nits: > > > > > > > > Section 4., paragraph 3: > > > >> to prevent future compatability issues. > > > > > > > > Nit: s/compatability/compatibility/ > > > > > > > > > > > > Section 4.2., paragraph 1: > > > >> that is guaranteeed to be copied down into the inner header = upon > > > > > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > > > > > > > Section 6., paragraph 1: > > > >> always copy the CE codepoint from teh outer header into the > inner > > > > > > > > Nit: s/teh/the/ > > > > > > > > > > > > Section 6., paragraph 2: > > > >> header in decapsulation (unless the inner packet is not-ECT). > > > > If an > > > >> operator it is essential that any operator wishing to allow ECN > > to > > > >> exist end-to-end ensures there are no tunnel end-points within > > the > > > >> PCN-domain. > > > > > > > > "If an operator it is essential that any operator..." - wording > > > > > > > > > > > > Section 12., paragraph 0: > > > >> 12. References > > > > > > > > Should be updated; see idnits report. > > > > > > > > > > > > Appendix A., paragraph 2: > > > >> a given PCN-domain is dependant on the nature of the traffic > > > > entering > > > > > > > > Nit: s/dependant/dependent/ > > > > > > > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > = --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > >=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 toby.moncaster@bt.com Wed Aug 19 02:31: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 B1EBD3A6998 for ; Wed, 19 Aug 2009 02:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 zc9podhEt6+q for ; Wed, 19 Aug 2009 02:31:02 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 2D59A3A6A12 for ; Wed, 19 Aug 2009 02:31:01 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 10:31:05 +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, 19 Aug 2009 10:30:33 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: Acoc2SIdh0b1ygh5TSyje6dp2oIklwAA7z+QAPRacaA= References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> From: To: , , , , X-OriginalArrivalTime: 19 Aug 2009 09:31:05.0229 (UTC) FILETIME=[C654C3D0:01CA20AF] Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 09:31:03 -0000 Hi All, I think there is now a possible solution to progress this. The confusion all stemmed from the WG's desire to have a record kept of PCN experiments which then led to the source of the confusion in the baseline document's Appendix A. My proposed solution (based on the comments over the past 3 days) aims to do two things, firstly to clarify that PCN is an alternative marking behaviour that Operators can specify for certain DSCPs (without changing the scheduling or other behaviours), secondly it should recommend 1 (or more) DSCPs that are currently suitable and should list what we believe are the criteria for suitability AND/OR explain what we would expect needed to happen if people wanted to suggest other DSCPs that it could apply to (either existing or new ones). This second bit is more thorny and I am not sure I am best placed to do it. I would welcome any offers of text for that bit... The end result will be that we have a doc that really makes no IANA requests, that suggests a suitable DSCP to apply PCN to initially and that explains what makes that DSCP suitable... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > toby.moncaster@bt.com > Sent: 14 August 2009 14:06 > To: lars.eggert@nokia.com; pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi Lars, >=20 > Sorry not to get back to you earlier - been busy at work so this went > on > a back-burner for a few days. >=20 > The original intention of having registration was to avoid confusion > during any early experimental adoption of PCN however that could be > done > purely unofficially by having a list of DSCPs on the IETF wiki and just > politely asking developers to consult it and add any new ones they are > using. But there will need in future to be a process to formally > register certain standards (pool 1) DSCPs as PCN-compatible since this > effectively replaces ECN as the default behaviour for such DSCPs. So > my > suggestion is: >=20 > Change the IANA section to say something along the following lines (I > will get IANA assistance with crafting exact text): >=20 > "IANA will be asked to set up a registry of PCN-compatible Diffserv > codepoints. The decision as to whether to enable PCN for a given pool 1 > codepoint must be made by the appropriate IETF Transport Area Working > Group (TSVWG?) which will then request IANA to add this to the > registry." >=20 > Clarify at start of A.1 that the decision of which DSCPs to apply PCN > to > has to be made by TSVWG and is separate to this document which just > defines the process and the encoding. >=20 > Change the last sentence of A.1 to "IANA will maintain a list of > PCN-compatible Diffserv Codepoints." >=20 > Would this cover things appropriately? I did wonder about asking IANA > to > maintain the experimental registry but I am not sure if they are able > to > do that sort of thing? If so the following could be added to the IANA > section: >=20 > "During the early stages of adoption it is envisaged that PCN will be > used experimentally using pool 2 or 3 DSCPs (experimental or local > use). > Whilst these DSCPs are not controlled by IANA normally, a request will > be made to maintain a list of PCN experiments along with the DSCPs > these > experiments are using." >=20 > Once I get the nod from WG I will release a new version of the I-D with > these updates... >=20 > Toby >=20 > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Lars Eggert > > Sent: 14 August 2009 12:27 > > To: pcn@ietf.org > > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 > > > > Hi, > > > > I'm waiting to hear from the authors/WG. > > > > Lars > > > > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: > > > > > Hi, > > > > > > this document is ready, except for one issue: > > > > > > Section 7., paragraph 1: > > >> This document makes no direct request to IANA. However this > > > document > > >> allows for a set of Diffserv Codepoints to be assigned different > > > ECN > > >> semantics within a controlled domain as described in [RFC4774]. > A > > >> list of such DSCPs will be maintained by the PCN working group. > > > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > > says > > > "the WG will maintain a list of DSCPs that are OK", while the > > > beginning of appendix A.1 says "the WG decided to not define with > > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > > maintaining a list again.) Which is it? If there is to be a list, > > > you > > > need to create an IANA registry, write management procedures for > it > > > (see RFC5226) and populate it with some initial values. (WGs are > > > ephemeral, which is why the PCN WG can't be the maintainer of > this > > > list, IANA has to be.) If you want to leave it fully open for > > > deployments, you need to remove this confusion from the text. > > > > > > Lars > > > > > > > > > Nits: > > > > > > Section 4., paragraph 3: > > >> to prevent future compatability issues. > > > > > > Nit: s/compatability/compatibility/ > > > > > > > > > Section 4.2., paragraph 1: > > >> that is guaranteeed to be copied down into the inner header upon > > > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > > > > Section 6., paragraph 1: > > >> always copy the CE codepoint from teh outer header into the > inner > > > > > > Nit: s/teh/the/ > > > > > > > > > Section 6., paragraph 2: > > >> header in decapsulation (unless the inner packet is not-ECT). > > > If an > > >> operator it is essential that any operator wishing to allow ECN > to > > >> exist end-to-end ensures there are no tunnel end-points within > the > > >> PCN-domain. > > > > > > "If an operator it is essential that any operator..." - wording > > > > > > > > > Section 12., paragraph 0: > > >> 12. References > > > > > > Should be updated; see idnits report. > > > > > > > > > Appendix A., paragraph 2: > > >> a given PCN-domain is dependant on the nature of the traffic > > > entering > > > > > > Nit: s/dependant/dependent/ > > > > > > >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From rbriscoe@jungle.bt.co.uk Wed Aug 19 02:31:15 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FBE3A6A12 for ; Wed, 19 Aug 2009 02:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_QP_LONG_LINE=1.396, 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 mtnkaMaLzpJW for ; Wed, 19 Aug 2009 02:31:07 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 1B75F3A6E3B for ; Wed, 19 Aug 2009 02:31:06 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 10:31:11 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 10:31:10 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 12506742595; Wed, 19 Aug 2009 10:30:59 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7J9UsUq017459; Wed, 19 Aug 2009 10:30:54 +0100 Message-Id: <200908190930.n7J9UsUq017459@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Aug 2009 10:30:53 +0100 To: menth@informatik.uni-wuerzburg.de, toby.moncaster@bt.com From: Bob Briscoe In-Reply-To: <4A8BBD24.10908@informatik.uni-wuerzburg.de> References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <4A8BBD24.10908@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Aug 2009 09:31:10.0847 (UTC) FILETIME=[C9AE00F0:01CA20AF] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 09:31:15 -0000 Michael, Correct. (Except, there is a wrinkle about clearing the=20 ECN field at the egress; only if e2e ECN is not being used.) The ASCII art was merely intended to explain why=20 we can't assume there will be just one DSCP for=20 PCN traffic. The lo-stat-mux part of a network=20 treats multiple DSCPs with multiple PHBs. But=20 even if they all get treated with the same PHB=20 within a hi-stat-mux core, they don't all=20 necessarily get mapped to one DSCP (so that they=20 can be separated out again on the other side). Bob At 09:51 19/08/2009, Michael Menth wrote: >Hi, > >I'm not sure whether the ASCII art is needed at=20 >all and I did not really understand it. The following message arrived with= me: > >PCN is locally applied to some specific DSCPs=20 >with the same scheduling behavior (I don't think=20 >that we can allow different one, this requires=20 >more study). If PCN marking applies to them, the=20 >ECN field of corresponding packets is set to an=20 >appropriate value by the ingress node, else it=20 >is set to 00. After leaving the domain, the PCN=20 >egress node clears the ECN field with 00. This=20 >way, no new DSCPs are needed for PCN. > >Or have I missed a critical point? > >Regards, > >Michael > > > >toby.moncaster@bt.com schrieb: >> >>That ASCII art is still unreadable because (for=20 >>me at least) it is getting displayed in a=20 >>variable-width font (Times New Roman to be=20 >>exact). I ended up having to convert it to=20 >>Courier to be able to see what you meant=85 >> >>I am in the process of drafting a reply setting=20 >>out the background to this confusion and=20 >>hopefully solving it. In the meantime there=20 >>seems to be a consensus that the way ahead is=20 >>to recommend PCN as suitable for 1 or more=20 >>EXISTING DSCPs (which means we need to decide=20 >>which ones=85). But that still leaves the=20 >>question of whether we need to say something=20 >>about what needs to happen in the future if=20 >>someone (say Fred Baker) wants to add PCN to a new DSCP. >> >>Toby >> >>*From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R >>*Sent:* 19 August 2009 09:29 >>*To:* Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R >>*Cc:* pcn@ietf.org >>*Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> >>Ruediger, >> >>Great. >> >>[As some people couldn't read it, I've also=20 >>replaced the diag quoted in the thread below=20 >>with narrower ASCII-art to better survive word wrap] >> >>Cheers >> >> >>Bob >> >>At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: >> >>Hi Bob, >> >>I agree to your suggestion to "scrub (ii) and=20 >>only have (i)..[and that] we should list=20 >>classes that might be appropriate to associate with PCN marking." >> >>Regards, >> >>Ruediger >> >>------------------------------------------------------------------------ >> >>*From:* Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk] >>*Sent:* Tuesday, August 18, 2009 7:37 PM >>*To:* Geib, R=FCdiger; toby.moncaster@bt.com >>*Cc:* pcn@ietf.org >>*Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> >>Ruediger, >> >>The draft as it stands holds two inconsistent opinions: >>i) " >> >>the aim is for PCN to re-use existing DSCPs >> >> >>" (S.4.3.1) >>ii) the second half of Appx A.1, repeated below. >> >>Similarly, your posting, talks about: >>i) applying PCN to existing DSCPs >>ii) reserving DSCPs for PCN. >> >>I believe we should scrub (ii) and only have=20 >>(i). In place of ii) we should list the classes=20 >>that might be appropriate to associate with PCN marking. >> >>In other words, we should only say that an=20 >>operator _applies_ PCN marking to certain existing DSCPs. >> >>No-one needs any additional DSCPs to enable PCN=20 >>marking. Otherwise that would waste DSCPs just=20 >>to get a different marking behaviour for=20 >>packets requiring the same scheduling behaviour=20 >>as a pre-existing DSCP. The non-wasteful way to=20 >>do this is to use one DSCP for a certain=20 >>scheduling behaviour, but set the ECN field to=20 >>a non-zero value to turn on PCN marking (S.4.3.1). >> >>[In MPLS, as there is no ECN field, the=20 >>efficient way is different. Then RFC5129 describes how you would do it.] >> >>To be absolutely sure it's clear what I mean, here's an example: >> >> >>hi stat mux subnet >>___________________ >>| same | >>| marking | >>| _____ ____:___ | >>| | || || >>--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- >>| | || || >>--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- >>| | ||________|| >>| | | | >>--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- >>| |_____| | >>| _____ | >>| | | | >>--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ >>| | | | >>--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- >>| |_____| | >>| : | >>| same | >>| scheduling | >>| (BA) | >>|___________________| >> >> >>- The text on each flow shows the DSCP-ECN combination used for that= segment >>- The boxes around DSCPA/B/C and around DSCPD/E=20 >>represent the same scheduling behaviour applied=20 >>to multiple DSCPs in the aggregated region (a behaviour aggregate). >>- The box around NM for the first two flows=20 >>represents the same marking behaviour (PCN) applied to multiple DSCPs. >>- The flows keep the same DSCP* along their=20 >>whole path, so when they pop out into the=20 >>lo-stat-mux region on the other side, the DSCP is preserved. >>- In practice, traffic might be tunnelled=20 >>across the hi-stat mux region, and at the same=20 >>time common scheduling behaviours might be=20 >>mapped to a single DSCP in the outer headers.=20 >>The diagram merely shows everything can be done without tunnelling or= layering. >> >>* Note: For some non-standardised DSCPs, the=20 >>DSCP might not actually stay the same along the=20 >>whole path. It might be mapped to local DSCPs=20 >>that are each used for the same class at different points along the path. >> >> >>Here's a copy of the 2nd half of Appx A.1, that I think needs to be >>removed (sorry, I know I'm a co-author, but...): >>" The choice of which DSCP is most suitable for >> a given PCN-domain is dependant on the nature of the >>traffic >>entering >> that domain and the link rates of all the links making up >>that >> domain. In PCN-domains with uniformly high link >>rates, >>the >> appropriate DSCPs would currently be those for the Real >>Time >>Traffic >> Class >>[RFC5127 ]. If the >>PCN domain includes lower speed links it >> would also be appropriate to use the DSCPs of the other >>traffic >> classes that >>[=20 >> >>Voice-Admit=20 >>]=20 >>defines for use with admission control, >> such as the three video classes CS4, CS3 and AF4 and the >>Admitted >> Telephony Class. The PCN working group will maintain >>a >>list of PCN- >> compatible Diffserv Codepoints. >> >> >>" >> >>At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: >> >>Toby, >> >>PCN should express to the IANA, whether one or more new DSCP is >>required to operate or carry out experiments on PCN. >> >>As soon as IANA maintains a list of DSCPs for any purpose, this >>will have the status of a standard. >> >>"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs >>per traffic class (DSCP bit 0-2, let's call them traffic class >>in this email) for PCN, that's 32 DSCPs in all. >> >>If possible, PCN should limit the number of traffic classes, >>where to apply PCN. >> >>I don't think PCN will be applied in traffic classes 0 and 6. >> >>I'd expect PCN to be used within traffic classes 5 and 4, >>may be also 3 or 2. >> >>Traffic classes 1 and 7 may be excluded too. >> >>The above clearly expresses personal views, but informational >>RFC5127 to some extent backs these personal views. >> >>I'm aware that PCN WG shouldn't standardise traffic class usage >>or come close to that. I however want to avoid repeating the biggest >>flaw of the AF specification, which in my eyes is to reserve >>12 DSCPs for 4 traffic classes. >> >>Regards, >> >>Ruediger >> >> >> >>-----Original Message----- >>From: pcn-bounces@ietf.org [=20 >>mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com >>Sent: Friday, August 14, 2009 3:06 PM >>To: lars.eggert@nokia.com; pcn@ietf.org >>Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> >>Hi Lars, >> >>Sorry not to get back to you earlier - been busy at work so this went on >>a back-burner for a few days. >> >>The original intention of having registration was to avoid confusion >>during any early experimental adoption of PCN however that could be done >>purely unofficially by having a list of DSCPs on the IETF wiki and just >>politely asking developers to consult it and add any new ones they are >>using. But there will need in future to be a process to formally >>register certain standards (pool 1) DSCPs as PCN-compatible since this >>effectively replaces ECN as the default behaviour for such DSCPs. So my >>suggestion is: >> >>Change the IANA section to say something along the following lines (I >>will get IANA assistance with crafting exact text): >> >>"IANA will be asked to set up a registry of PCN-compatible Diffserv >>codepoints. The decision as to whether to enable PCN for a given pool 1 >>codepoint must be made by the appropriate IETF Transport Area Working >>Group (TSVWG?) which will then request IANA to add this to the >>registry." >> >>Clarify at start of A.1 that the decision of which DSCPs to apply PCN to >>has to be made by TSVWG and is separate to this document which just >>defines the process and the encoding. >> >>Change the last sentence of A.1 to "IANA will maintain a list of >>PCN-compatible Diffserv Codepoints." >> >>Would this cover things appropriately? I did wonder about asking IANA to >>maintain the experimental registry but I am not sure if they are able to >>do that sort of thing? If so the following could be added to the IANA >>section: >> >>"During the early stages of adoption it is envisaged that PCN will be >>used experimentally using pool 2 or 3 DSCPs (experimental or local use). >>Whilst these DSCPs are not controlled by IANA normally, a request will >>be made to maintain a list of PCN experiments along with the DSCPs these >>experiments are using." >> >>Once I get the nod from WG I will release a new version of the I-D with >>these updates... >> >>Toby >> >> > -----Original Message----- >> > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of >> > Lars Eggert >> > Sent: 14 August 2009 12:27 >> > To: pcn@ietf.org >> > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> > >> > Hi, >> > >> > I'm waiting to hear from the authors/WG. >> > >> > Lars >> > >> > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >> > >> > > Hi, >> > > >> > > this document is ready, except for one issue: >> > > >> > > Section 7., paragraph 1: >> > >> This document makes no direct request to IANA. However this >> > > document >> > >> allows for a set of Diffserv Codepoints to be assigned different >> > > ECN >> > >> semantics within a controlled domain as described in [RFC4774]. >>A >> > >> list of such DSCPs will be maintained by the PCN working group. >> > > >> > > DISCUSS: This text isn't aligned with appendix A.1. The text here >> > > says >> > > "the WG will maintain a list of DSCPs that are OK", while the >> > > beginning of appendix A.1 says "the WG decided to not define with >> > > which DSCPs PCN can be used" (but then the end of A.1 talks about >> > > maintaining a list again.) Which is it? If there is to be a list, >> > > you >> > > need to create an IANA registry, write management procedures for >>it >> > > (see RFC5226) and populate it with some initial values. (WGs are >> > > ephemeral, which is why the PCN WG can't be the maintainer of this >> > > list, IANA has to be.) If you want to leave it fully open for >> > > deployments, you need to remove this confusion from the text. >> > > >> > > Lars >> > > >> > > >> > > Nits: >> > > >> > > Section 4., paragraph 3: >> > >> to prevent future compatability issues. >> > > >> > > Nit: s/compatability/compatibility/ >> > > >> > > >> > > Section 4.2., paragraph 1: >> > >> that is guaranteeed to be copied down into the inner header upon >> > > >> > > Nit: s/guaranteeed/guaranteed/ >> > > >> > > >> > > Section 6., paragraph 1: >> > >> always copy the CE codepoint from teh outer header into the inner >> > > >> > > Nit: s/teh/the/ >> > > >> > > >> > > Section 6., paragraph 2: >> > >> header in decapsulation (unless the inner packet is not-ECT). >> > > If an >> > >> operator it is essential that any operator wishing to allow ECN >>to >> > >> exist end-to-end ensures there are no tunnel end-points within >>the >> > >> PCN-domain. >> > > >> > > "If an operator it is essential that any operator..." - wording >> > > >> > > >> > > Section 12., paragraph 0: >> > >> 12. References >> > > >> > > Should be updated; see idnits report. >> > > >> > > >> > > Appendix A., paragraph 2: >> > >> a given PCN-domain is dependant on the nature of the traffic >> > > entering >> > > >> > > Nit: s/dependant/dependent/ >> > > >> > > >> >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www.ietf.org/mailman/listinfo/pcn >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www.ietf.org/mailman/listinfo/pcn >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www.ietf.org/mailman/listinfo/pcn >> > >-- >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 menth@informatik.uni-wuerzburg.de Wed Aug 19 02:34: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 8DDF83A6E51 for ; Wed, 19 Aug 2009 02:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gRJqqhdR5vk for ; Wed, 19 Aug 2009 02:34:53 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 3A3D33A6C58 for ; Wed, 19 Aug 2009 02:34:18 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 4AECE199689; Wed, 19 Aug 2009 11:34:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3E57B199660; Wed, 19 Aug 2009 11:34:23 +0200 (CEST) Received: from [192.168.1.2] (e181183006.adsl.alicedsl.de [85.181.183.6]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CB4B5A074E; Wed, 19 Aug 2009 11:34:22 +0200 (CEST) Message-ID: <4A8BC6F7.9070803@informatik.uni-wuerzburg.de> Date: Wed, 19 Aug 2009 11:33:43 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Bob Briscoe References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <4A8BBD24.10908@informatik.uni-wuerzburg.de> <200908190930.n7J9UsUq017459@bagheera.jungle.bt.co.uk> In-Reply-To: <200908190930.n7J9UsUq017459@bagheera.jungle.bt.co.uk> 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] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 09:34:54 -0000 Hi Bob, Bob Briscoe schrieb: > Michael, > > Correct. > > (Except, there is a wrinkle about clearing the ECN field at the > egress; only if e2e ECN is not being used.) > > The ASCII art was merely intended to explain why we can't assume there > will be just one DSCP for PCN traffic. The lo-stat-mux part of a > network treats multiple DSCPs with multiple PHBs. But even if they all > get treated with the same PHB within a hi-stat-mux core, they don't > all necessarily get mapped to one DSCP (so that they can be separated > out again on the other side). I understand. That makes any marking behavior using two DSCPs even more problematic, right? Regards, Michael > > > > Bob > > At 09:51 19/08/2009, Michael Menth wrote: >> Hi, >> >> I'm not sure whether the ASCII art is needed at all and I did not >> really understand it. The following message arrived with me: >> >> PCN is locally applied to some specific DSCPs with the same >> scheduling behavior (I don't think that we can allow different one, >> this requires more study). If PCN marking applies to them, the ECN >> field of corresponding packets is set to an appropriate value by the >> ingress node, else it is set to 00. After leaving the domain, the PCN >> egress node clears the ECN field with 00. This way, no new DSCPs are >> needed for PCN. >> >> Or have I missed a critical point? >> >> Regards, >> >> Michael >> >> >> >> toby.moncaster@bt.com schrieb: >>> >>> That ASCII art is still unreadable because (for me at least) it is >>> getting displayed in a variable-width font (Times New Roman to be >>> exact). I ended up having to convert it to Courier to be able to see >>> what you meant… >>> >>> I am in the process of drafting a reply setting out the background >>> to this confusion and hopefully solving it. In the meantime there >>> seems to be a consensus that the way ahead is to recommend PCN as >>> suitable for 1 or more EXISTING DSCPs (which means we need to decide >>> which ones…). But that still leaves the question of whether we need >>> to say something about what needs to happen in the future if someone >>> (say Fred Baker) wants to add PCN to a new DSCP. >>> >>> Toby >>> >>> *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R >>> *Sent:* 19 August 2009 09:29 >>> *To:* Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R >>> *Cc:* pcn@ietf.org >>> *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >>> >>> Ruediger, >>> >>> Great. >>> >>> [As some people couldn't read it, I've also replaced the diag quoted >>> in the thread below with narrower ASCII-art to better survive word >>> wrap] >>> >>> Cheers >>> >>> >>> Bob >>> >>> At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: >>> >>> Hi Bob, >>> >>> I agree to your suggestion to "scrub (ii) and only have (i)..[and >>> that] we should list classes that might be appropriate to associate >>> with PCN marking." >>> >>> Regards, >>> >>> Ruediger >>> >>> ------------------------------------------------------------------------ >>> >>> >>> *From:* Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk] >>> *Sent:* Tuesday, August 18, 2009 7:37 PM >>> *To:* Geib, Rüdiger; toby.moncaster@bt.com >>> *Cc:* pcn@ietf.org >>> *Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >>> >>> Ruediger, >>> >>> The draft as it stands holds two inconsistent opinions: >>> i) " >>> >>> the aim is for PCN to re-use existing DSCPs >>> >>> >>> " (S.4.3.1) >>> ii) the second half of Appx A.1, repeated below. >>> >>> Similarly, your posting, talks about: >>> i) applying PCN to existing DSCPs >>> ii) reserving DSCPs for PCN. >>> >>> I believe we should scrub (ii) and only have (i). In place of ii) we >>> should list the classes that might be appropriate to associate with >>> PCN marking. >>> >>> In other words, we should only say that an operator _applies_ PCN >>> marking to certain existing DSCPs. >>> >>> No-one needs any additional DSCPs to enable PCN marking. Otherwise >>> that would waste DSCPs just to get a different marking behaviour for >>> packets requiring the same scheduling behaviour as a pre-existing >>> DSCP. The non-wasteful way to do this is to use one DSCP for a >>> certain scheduling behaviour, but set the ECN field to a non-zero >>> value to turn on PCN marking (S.4.3.1). >>> >>> [In MPLS, as there is no ECN field, the efficient way is different. >>> Then RFC5129 describes how you would do it.] >>> >>> To be absolutely sure it's clear what I mean, here's an example: >>> >>> >>> hi stat mux subnet >>> ___________________ >>> | same | >>> | marking | >>> | _____ ____:___ | >>> | | || || >>> --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- >>> | | || || >>> --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- >>> | | ||________|| >>> | | | | >>> --DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- >>> | |_____| | >>> | _____ | >>> | | | | >>> --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ >>> | | | | >>> --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- >>> | |_____| | >>> | : | >>> | same | >>> | scheduling | >>> | (BA) | >>> |___________________| >>> >>> >>> - The text on each flow shows the DSCP-ECN combination used for that >>> segment >>> - The boxes around DSCPA/B/C and around DSCPD/E represent the same >>> scheduling behaviour applied to multiple DSCPs in the aggregated >>> region (a behaviour aggregate). >>> - The box around NM for the first two flows represents the same >>> marking behaviour (PCN) applied to multiple DSCPs. >>> - The flows keep the same DSCP* along their whole path, so when they >>> pop out into the lo-stat-mux region on the other side, the DSCP is >>> preserved. >>> - In practice, traffic might be tunnelled across the hi-stat mux >>> region, and at the same time common scheduling behaviours might be >>> mapped to a single DSCP in the outer headers. The diagram merely >>> shows everything can be done without tunnelling or layering. >>> >>> * Note: For some non-standardised DSCPs, the DSCP might not actually >>> stay the same along the whole path. It might be mapped to local >>> DSCPs that are each used for the same class at different points >>> along the path. >>> >>> >>> Here's a copy of the 2nd half of Appx A.1, that I think needs to be >>> removed (sorry, I know I'm a co-author, but...): >>> " The choice of which DSCP is most suitable for >>> a given PCN-domain is dependant on the nature of the >>> traffic >>> entering >>> that domain and the link rates of all the links making up >>> that >>> domain. In PCN-domains with uniformly high link >>> rates, >>> the >>> appropriate DSCPs would currently be those for the Real >>> Time >>> Traffic >>> Class >>> [RFC5127 ]. If the >>> PCN domain includes lower speed links it >>> would also be appropriate to use the DSCPs of the other >>> traffic >>> classes that >>> [ >>> >>> >>> Voice-Admit >>> ] >>> defines for use with admission control, >>> such as the three video classes CS4, CS3 and AF4 and the >>> Admitted >>> Telephony Class. The PCN working group will maintain >>> a >>> list of PCN- >>> compatible Diffserv Codepoints. >>> >>> >>> " >>> >>> At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: >>> >>> Toby, >>> >>> PCN should express to the IANA, whether one or more new DSCP is >>> required to operate or carry out experiments on PCN. >>> >>> As soon as IANA maintains a list of DSCPs for any purpose, this >>> will have the status of a standard. >>> >>> "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs >>> per traffic class (DSCP bit 0-2, let's call them traffic class >>> in this email) for PCN, that's 32 DSCPs in all. >>> >>> If possible, PCN should limit the number of traffic classes, >>> where to apply PCN. >>> >>> I don't think PCN will be applied in traffic classes 0 and 6. >>> >>> I'd expect PCN to be used within traffic classes 5 and 4, >>> may be also 3 or 2. >>> >>> Traffic classes 1 and 7 may be excluded too. >>> >>> The above clearly expresses personal views, but informational >>> RFC5127 to some extent backs these personal views. >>> >>> I'm aware that PCN WG shouldn't standardise traffic class usage >>> or come close to that. I however want to avoid repeating the biggest >>> flaw of the AF specification, which in my eyes is to reserve >>> 12 DSCPs for 4 traffic classes. >>> >>> Regards, >>> >>> Ruediger >>> >>> >>> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf >>> Of toby.moncaster@bt.com >>> Sent: Friday, August 14, 2009 3:06 PM >>> To: lars.eggert@nokia.com; pcn@ietf.org >>> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >>> >>> Hi Lars, >>> >>> Sorry not to get back to you earlier - been busy at work so this >>> went on >>> a back-burner for a few days. >>> >>> The original intention of having registration was to avoid confusion >>> during any early experimental adoption of PCN however that could be >>> done >>> purely unofficially by having a list of DSCPs on the IETF wiki and just >>> politely asking developers to consult it and add any new ones they are >>> using. But there will need in future to be a process to formally >>> register certain standards (pool 1) DSCPs as PCN-compatible since this >>> effectively replaces ECN as the default behaviour for such DSCPs. So my >>> suggestion is: >>> >>> Change the IANA section to say something along the following lines (I >>> will get IANA assistance with crafting exact text): >>> >>> "IANA will be asked to set up a registry of PCN-compatible Diffserv >>> codepoints. The decision as to whether to enable PCN for a given pool 1 >>> codepoint must be made by the appropriate IETF Transport Area Working >>> Group (TSVWG?) which will then request IANA to add this to the >>> registry." >>> >>> Clarify at start of A.1 that the decision of which DSCPs to apply >>> PCN to >>> has to be made by TSVWG and is separate to this document which just >>> defines the process and the encoding. >>> >>> Change the last sentence of A.1 to "IANA will maintain a list of >>> PCN-compatible Diffserv Codepoints." >>> >>> Would this cover things appropriately? I did wonder about asking >>> IANA to >>> maintain the experimental registry but I am not sure if they are >>> able to >>> do that sort of thing? If so the following could be added to the IANA >>> section: >>> >>> "During the early stages of adoption it is envisaged that PCN will be >>> used experimentally using pool 2 or 3 DSCPs (experimental or local >>> use). >>> Whilst these DSCPs are not controlled by IANA normally, a request will >>> be made to maintain a list of PCN experiments along with the DSCPs >>> these >>> experiments are using." >>> >>> Once I get the nod from WG I will release a new version of the I-D with >>> these updates... >>> >>> Toby >>> >>> > -----Original Message----- >>> > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On >>> Behalf Of >>> > Lars Eggert >>> > Sent: 14 August 2009 12:27 >>> > To: pcn@ietf.org >>> > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >>> > >>> > Hi, >>> > >>> > I'm waiting to hear from the authors/WG. >>> > >>> > Lars >>> > >>> > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >>> > >>> > > Hi, >>> > > >>> > > this document is ready, except for one issue: >>> > > >>> > > Section 7., paragraph 1: >>> > >> This document makes no direct request to IANA. However this >>> > > document >>> > >> allows for a set of Diffserv Codepoints to be assigned different >>> > > ECN >>> > >> semantics within a controlled domain as described in [RFC4774]. >>> A >>> > >> list of such DSCPs will be maintained by the PCN working group. >>> > > >>> > > DISCUSS: This text isn't aligned with appendix A.1. The text here >>> > > says >>> > > "the WG will maintain a list of DSCPs that are OK", while the >>> > > beginning of appendix A.1 says "the WG decided to not define with >>> > > which DSCPs PCN can be used" (but then the end of A.1 talks about >>> > > maintaining a list again.) Which is it? If there is to be a list, >>> > > you >>> > > need to create an IANA registry, write management procedures for >>> it >>> > > (see RFC5226) and populate it with some initial values. (WGs are >>> > > ephemeral, which is why the PCN WG can't be the maintainer of this >>> > > list, IANA has to be.) If you want to leave it fully open for >>> > > deployments, you need to remove this confusion from the text. >>> > > >>> > > Lars >>> > > >>> > > >>> > > Nits: >>> > > >>> > > Section 4., paragraph 3: >>> > >> to prevent future compatability issues. >>> > > >>> > > Nit: s/compatability/compatibility/ >>> > > >>> > > >>> > > Section 4.2., paragraph 1: >>> > >> that is guaranteeed to be copied down into the inner header upon >>> > > >>> > > Nit: s/guaranteeed/guaranteed/ >>> > > >>> > > >>> > > Section 6., paragraph 1: >>> > >> always copy the CE codepoint from teh outer header into the inner >>> > > >>> > > Nit: s/teh/the/ >>> > > >>> > > >>> > > Section 6., paragraph 2: >>> > >> header in decapsulation (unless the inner packet is not-ECT). >>> > > If an >>> > >> operator it is essential that any operator wishing to allow ECN >>> to >>> > >> exist end-to-end ensures there are no tunnel end-points within >>> the >>> > >> PCN-domain. >>> > > >>> > > "If an operator it is essential that any operator..." - wording >>> > > >>> > > >>> > > Section 12., paragraph 0: >>> > >> 12. References >>> > > >>> > > Should be updated; see idnits report. >>> > > >>> > > >>> > > Appendix A., paragraph 2: >>> > >> a given PCN-domain is dependant on the nature of the traffic >>> > > entering >>> > > >>> > > Nit: s/dependant/dependent/ >>> > > >>> > > >>> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >>> >> >> -- >> 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 -- 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 Aug 19 02:45: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 4737928C147 for ; Wed, 19 Aug 2009 02:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfODysBCFLjx for ; Wed, 19 Aug 2009 02:45:09 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B00A63A687F for ; Wed, 19 Aug 2009 02:45:08 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 10:45:13 +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: Wed, 19 Aug 2009 10:45:12 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0636375E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A8BC6F7.9070803@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: AcogsGU0185f2hoWRaewWPr3kS/FMgAAR+bA From: To: , X-OriginalArrivalTime: 19 Aug 2009 09:45:13.0244 (UTC) FILETIME=[BFC995C0:01CA20B1] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 09:45:11 -0000 Yes, I think any of the extended pcn encodings that uses 2 dscps needs = to say something about the scheduling behaviour of the 2 dscps. The = obvious thing is that they both map to the same scheduling PHB = (actually, first guess is that this is the only thing that makes sense) { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Michael Menth { Sent: 19 August 2009 10:34 { To: Briscoe,RJ,Bob,XVR9 BRISCORJ R { Cc: pcn@ietf.org { Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 {=20 { Hi Bob, {=20 { Bob Briscoe schrieb: { > Michael, { > { > Correct. { > { > (Except, there is a wrinkle about clearing the ECN field at the { > egress; only if e2e ECN is not being used.) { > { > The ASCII art was merely intended to explain why we can't assume = there { > will be just one DSCP for PCN traffic. The lo-stat-mux part of a { > network treats multiple DSCPs with multiple PHBs. But even if they = all { > get treated with the same PHB within a hi-stat-mux core, they don't { > all necessarily get mapped to one DSCP (so that they can be = separated { > out again on the other side). { I understand. That makes any marking behavior using two DSCPs even = more { problematic, right? {=20 { Regards, {=20 { Michael {=20 {=20 { > { > { > { > Bob { > { > At 09:51 19/08/2009, Michael Menth wrote: { >> Hi, { >> { >> I'm not sure whether the ASCII art is needed at all and I did not { >> really understand it. The following message arrived with me: { >> { >> PCN is locally applied to some specific DSCPs with the same { >> scheduling behavior (I don't think that we can allow different one, { >> this requires more study). If PCN marking applies to them, the ECN { >> field of corresponding packets is set to an appropriate value by = the { >> ingress node, else it is set to 00. After leaving the domain, the = PCN { >> egress node clears the ECN field with 00. This way, no new DSCPs = are { >> needed for PCN. { >> { >> Or have I missed a critical point? { >> { >> Regards, { >> { >> Michael { >> { >> { >> { >> toby.moncaster@bt.com schrieb: { >>> { >>> That ASCII art is still unreadable because (for me at least) it is { >>> getting displayed in a variable-width font (Times New Roman to be { >>> exact). I ended up having to convert it to Courier to be able to = see { >>> what you meant... { >>> { >>> I am in the process of drafting a reply setting out the background { >>> to this confusion and hopefully solving it. In the meantime there { >>> seems to be a consensus that the way ahead is to recommend PCN as { >>> suitable for 1 or more EXISTING DSCPs (which means we need to = decide { >>> which ones...). But that still leaves the question of whether we = need { >>> to say something about what needs to happen in the future if = someone { >>> (say Fred Baker) wants to add PCN to a new DSCP. { >>> { >>> Toby { >>> { >>> *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R { >>> *Sent:* 19 August 2009 09:29 { >>> *To:* Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R { >>> *Cc:* pcn@ietf.org { >>> *Subject:* RE: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04 { >>> { >>> Ruediger, { >>> { >>> Great. { >>> { >>> [As some people couldn't read it, I've also replaced the diag = quoted { >>> in the thread below with narrower ASCII-art to better survive word { >>> wrap] { >>> { >>> Cheers { >>> { >>> { >>> Bob { >>> { >>> At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: { >>> { >>> Hi Bob, { >>> { >>> I agree to your suggestion to "scrub (ii) and only have (i)..[and { >>> that] we should list classes that might be appropriate to = associate { >>> with PCN marking." { >>> { >>> Regards, { >>> { >>> Ruediger { >>> { >>> = ---------------------------------------------------------------------- { -- { >>> { >>> { >>> *From:* Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk] { >>> *Sent:* Tuesday, August 18, 2009 7:37 PM { >>> *To:* Geib, R=FCdiger; toby.moncaster@bt.com { >>> *Cc:* pcn@ietf.org { >>> *Subject:* Re: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04 { >>> { >>> Ruediger, { >>> { >>> The draft as it stands holds two inconsistent opinions: { >>> i) " { >>> { >>> the aim is for PCN to re-use existing DSCPs { >>> { >>> { >>> " (S.4.3.1) { >>> ii) the second half of Appx A.1, repeated below. { >>> { >>> Similarly, your posting, talks about: { >>> i) applying PCN to existing DSCPs { >>> ii) reserving DSCPs for PCN. { >>> { >>> I believe we should scrub (ii) and only have (i). In place of ii) = we { >>> should list the classes that might be appropriate to associate = with { >>> PCN marking. { >>> { >>> In other words, we should only say that an operator _applies_ PCN { >>> marking to certain existing DSCPs. { >>> { >>> No-one needs any additional DSCPs to enable PCN marking. Otherwise { >>> that would waste DSCPs just to get a different marking behaviour = for { >>> packets requiring the same scheduling behaviour as a pre-existing { >>> DSCP. The non-wasteful way to do this is to use one DSCP for a { >>> certain scheduling behaviour, but set the ECN field to a non-zero { >>> value to turn on PCN marking (S.4.3.1). { >>> { >>> [In MPLS, as there is no ECN field, the efficient way is = different. { >>> Then RFC5129 describes how you would do it.] { >>> { >>> To be absolutely sure it's clear what I mean, here's an example: { >>> { >>> { >>> hi stat mux subnet { >>> ___________________ { >>> | same | { >>> | marking | { >>> | _____ ____:___ | { >>> | | || || { >>> --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- { >>> | | || || { >>> --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- { >>> | | ||________|| { >>> | | | | { >>> --DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- { >>> | |_____| | { >>> | _____ | { >>> | | | | { >>> --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ { >>> | | | | { >>> --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- { >>> | |_____| | { >>> | : | { >>> | same | { >>> | scheduling | { >>> | (BA) | { >>> |___________________| { >>> { >>> { >>> - The text on each flow shows the DSCP-ECN combination used for = that { >>> segment { >>> - The boxes around DSCPA/B/C and around DSCPD/E represent the same { >>> scheduling behaviour applied to multiple DSCPs in the aggregated { >>> region (a behaviour aggregate). { >>> - The box around NM for the first two flows represents the same { >>> marking behaviour (PCN) applied to multiple DSCPs. { >>> - The flows keep the same DSCP* along their whole path, so when = they { >>> pop out into the lo-stat-mux region on the other side, the DSCP is { >>> preserved. { >>> - In practice, traffic might be tunnelled across the hi-stat mux { >>> region, and at the same time common scheduling behaviours might be { >>> mapped to a single DSCP in the outer headers. The diagram merely { >>> shows everything can be done without tunnelling or layering. { >>> { >>> * Note: For some non-standardised DSCPs, the DSCP might not = actually { >>> stay the same along the whole path. It might be mapped to local { >>> DSCPs that are each used for the same class at different points { >>> along the path. { >>> { >>> { >>> Here's a copy of the 2nd half of Appx A.1, that I think needs to = be { >>> removed (sorry, I know I'm a co-author, but...): { >>> " The choice of which DSCP is most suitable for { >>> a given PCN-domain is dependant on the nature of the { >>> traffic { >>> entering { >>> that domain and the link rates of all the links making up { >>> that { >>> domain. In PCN-domains with uniformly high link { >>> rates, { >>> the { >>> appropriate DSCPs would currently be those for the Real { >>> Time { >>> Traffic { >>> Class { >>> [RFC5127 ]. If the { >>> PCN domain includes lower speed links it { >>> would also be appropriate to use the DSCPs of the other { >>> traffic { >>> classes that { >>> [ { >>> = { >>> { >>> Voice-Admit { >>> = ] { >>> defines for use with admission control, { >>> such as the three video classes CS4, CS3 and AF4 and the { >>> Admitted { >>> Telephony Class. The PCN working group will maintain { >>> a { >>> list of PCN- { >>> compatible Diffserv Codepoints. { >>> { >>> { >>> " { >>> { >>> At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: { >>> { >>> Toby, { >>> { >>> PCN should express to the IANA, whether one or more new DSCP is { >>> required to operate or carry out experiments on PCN. { >>> { >>> As soon as IANA maintains a list of DSCPs for any purpose, this { >>> will have the status of a standard. { >>> { >>> "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs { >>> per traffic class (DSCP bit 0-2, let's call them traffic class { >>> in this email) for PCN, that's 32 DSCPs in all. { >>> { >>> If possible, PCN should limit the number of traffic classes, { >>> where to apply PCN. { >>> { >>> I don't think PCN will be applied in traffic classes 0 and 6. { >>> { >>> I'd expect PCN to be used within traffic classes 5 and 4, { >>> may be also 3 or 2. { >>> { >>> Traffic classes 1 and 7 may be excluded too. { >>> { >>> The above clearly expresses personal views, but informational { >>> RFC5127 to some extent backs these personal views. { >>> { >>> I'm aware that PCN WG shouldn't standardise traffic class usage { >>> or come close to that. I however want to avoid repeating the = biggest { >>> flaw of the AF specification, which in my eyes is to reserve { >>> 12 DSCPs for 4 traffic classes. { >>> { >>> Regards, { >>> { >>> Ruediger { >>> { >>> { >>> { >>> -----Original Message----- { >>> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On = Behalf { >>> Of toby.moncaster@bt.com { >>> Sent: Friday, August 14, 2009 3:06 PM { >>> To: lars.eggert@nokia.com; pcn@ietf.org { >>> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 { >>> { >>> Hi Lars, { >>> { >>> Sorry not to get back to you earlier - been busy at work so this { >>> went on { >>> a back-burner for a few days. { >>> { >>> The original intention of having registration was to avoid = confusion { >>> during any early experimental adoption of PCN however that could = be { >>> done { >>> purely unofficially by having a list of DSCPs on the IETF wiki and { just { >>> politely asking developers to consult it and add any new ones they = are { >>> using. But there will need in future to be a process to formally { >>> register certain standards (pool 1) DSCPs as PCN-compatible since = this { >>> effectively replaces ECN as the default behaviour for such DSCPs. = So { my { >>> suggestion is: { >>> { >>> Change the IANA section to say something along the following lines = (I { >>> will get IANA assistance with crafting exact text): { >>> { >>> "IANA will be asked to set up a registry of PCN-compatible = Diffserv { >>> codepoints. The decision as to whether to enable PCN for a given = pool { 1 { >>> codepoint must be made by the appropriate IETF Transport Area = Working { >>> Group (TSVWG?) which will then request IANA to add this to the { >>> registry." { >>> { >>> Clarify at start of A.1 that the decision of which DSCPs to apply { >>> PCN to { >>> has to be made by TSVWG and is separate to this document which = just { >>> defines the process and the encoding. { >>> { >>> Change the last sentence of A.1 to "IANA will maintain a list of { >>> PCN-compatible Diffserv Codepoints." { >>> { >>> Would this cover things appropriately? I did wonder about asking { >>> IANA to { >>> maintain the experimental registry but I am not sure if they are { >>> able to { >>> do that sort of thing? If so the following could be added to the = IANA { >>> section: { >>> { >>> "During the early stages of adoption it is envisaged that PCN will = be { >>> used experimentally using pool 2 or 3 DSCPs (experimental or local { >>> use). { >>> Whilst these DSCPs are not controlled by IANA normally, a request = will { >>> be made to maintain a list of PCN experiments along with the DSCPs { >>> these { >>> experiments are using." { >>> { >>> Once I get the nod from WG I will release a new version of the I-D { with { >>> these updates... { >>> { >>> Toby { >>> { >>> > -----Original Message----- { >>> > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On { >>> Behalf Of { >>> > Lars Eggert { >>> > Sent: 14 August 2009 12:27 { >>> > To: pcn@ietf.org { >>> > Subject: Re: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04 { >>> > { >>> > Hi, { >>> > { >>> > I'm waiting to hear from the authors/WG. { >>> > { >>> > Lars { >>> > { >>> > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: { >>> > { >>> > > Hi, { >>> > > { >>> > > this document is ready, except for one issue: { >>> > > { >>> > > Section 7., paragraph 1: { >>> > >> This document makes no direct request to IANA. However this { >>> > > document { >>> > >> allows for a set of Diffserv Codepoints to be assigned = different { >>> > > ECN { >>> > >> semantics within a controlled domain as described in = [RFC4774]. { >>> A { >>> > >> list of such DSCPs will be maintained by the PCN working = group. { >>> > > { >>> > > DISCUSS: This text isn't aligned with appendix A.1. The text = here { >>> > > says { >>> > > "the WG will maintain a list of DSCPs that are OK", while the { >>> > > beginning of appendix A.1 says "the WG decided to not define = with { >>> > > which DSCPs PCN can be used" (but then the end of A.1 talks = about { >>> > > maintaining a list again.) Which is it? If there is to be a = list, { >>> > > you { >>> > > need to create an IANA registry, write management procedures = for { >>> it { >>> > > (see RFC5226) and populate it with some initial values. (WGs = are { >>> > > ephemeral, which is why the PCN WG can't be the maintainer of = this { >>> > > list, IANA has to be.) If you want to leave it fully open for { >>> > > deployments, you need to remove this confusion from the text. { >>> > > { >>> > > Lars { >>> > > { >>> > > { >>> > > Nits: { >>> > > { >>> > > Section 4., paragraph 3: { >>> > >> to prevent future compatability issues. { >>> > > { >>> > > Nit: s/compatability/compatibility/ { >>> > > { >>> > > { >>> > > Section 4.2., paragraph 1: { >>> > >> that is guaranteeed to be copied down into the inner header = upon { >>> > > { >>> > > Nit: s/guaranteeed/guaranteed/ { >>> > > { >>> > > { >>> > > Section 6., paragraph 1: { >>> > >> always copy the CE codepoint from teh outer header into the = inner { >>> > > { >>> > > Nit: s/teh/the/ { >>> > > { >>> > > { >>> > > Section 6., paragraph 2: { >>> > >> header in decapsulation (unless the inner packet is not-ECT). { >>> > > If an { >>> > >> operator it is essential that any operator wishing to allow = ECN { >>> to { >>> > >> exist end-to-end ensures there are no tunnel end-points = within { >>> the { >>> > >> PCN-domain. { >>> > > { >>> > > "If an operator it is essential that any operator..." - = wording { >>> > > { >>> > > { >>> > > Section 12., paragraph 0: { >>> > >> 12. References { >>> > > { >>> > > Should be updated; see idnits report. { >>> > > { >>> > > { >>> > > Appendix A., paragraph 2: { >>> > >> a given PCN-domain is dependant on the nature of the traffic { >>> > > entering { >>> > > { >>> > > Nit: s/dependant/dependent/ { >>> > > { >>> > > { >>> { >>> _______________________________________________ { >>> PCN mailing list { >>> PCN@ietf.org { >>> https://www.ietf.org/mailman/listinfo/pcn { >>> _______________________________________________ { >>> PCN mailing list { >>> PCN@ietf.org { >>> https://www.ietf.org/mailman/listinfo/pcn { >>> { >>> = ---------------------------------------------------------------------- { -- { >>> { >>> { >>> _______________________________________________ { >>> PCN mailing list { >>> PCN@ietf.org { >>> https://www.ietf.org/mailman/listinfo/pcn { >>> { >> { >> -- { >> 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 {=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 {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From lars.eggert@nokia.com Wed Aug 19 03:36:35 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 1C2EF3A6CD9 for ; Wed, 19 Aug 2009 03:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.567, 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 fLVaQxMBAuMs for ; Wed, 19 Aug 2009 03:36:34 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 0D38B3A6A1F for ; Wed, 19 Aug 2009 03:36:33 -0700 (PDT) Received: from lars.sigcomm09.bcn ([212.121.255.27]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7JAZhtJ019396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 13:35:44 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <3423E723-5C5E-44C0-98A0-E056C8C8B02C@nokia.com> From: Lars Eggert To: toby.moncaster@bt.com In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-18--359485315; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 12:35:37 +0200 References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Wed, 19 Aug 2009 13:36:30 +0300 (EEST) Cc: "pcn@ietf.org" Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 10:36:35 -0000 --Apple-Mail-18--359485315 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, this sounds like a reasonable way forward. Lars On 2009-8-19, at 11:30, toby.moncaster@bt.com wrote: > My proposed solution (based on the comments over the past 3 days) aims > to do two things, firstly to clarify that PCN is an alternative > marking > behaviour that Operators can specify for certain DSCPs (without > changing > the scheduling or other behaviours), secondly it should recommend 1 > (or > more) DSCPs that are currently suitable and should list what we > believe > are the criteria for suitability AND/OR explain what we would expect > needed to happen if people wanted to suggest other DSCPs that it could > apply to (either existing or new ones). This second bit is more thorny > and I am not sure I am best placed to do it. I would welcome any > offers > of text for that bit... > > The end result will be that we have a doc that really makes no IANA > requests, that suggests a suitable DSCP to apply PCN to initially and > that explains what makes that DSCP suitable... --Apple-Mail-18--359485315 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 MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTkxMDM1MzhaMCMGCSqGSIb3DQEJBDEWBBQ7K78edlmUD9h8 kYNYZyYnt5dUSjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEABfxw5Bjws5WnVo1Jturi4LUNXQchupEMM7UO3Yp6FcjEw7rm8nrI jzWIFqkW0erE7OrgCkUt8KLhM84O/c1mGQifzPoQyVxjRvhnrDvXH2AUdyQj7Ttb+OvV/BaFltlA EUoAJiqzFeaIgBkakKi06sJjBUfrilmkunDx//VelZwIIsvnKaxI2KDKgmePsaPQcUAKfRuiDwnQ fx6JUjQsRshZxx0DKfF7aqynIwFTYP9p1Z6jPhp2r7Vp+VpDSKhhcpjmTZstWAHg3Mlkh0ZXKojw XtQtWD+1MwMhkuurp7oB+DRDce3gm1GiFTUdjfgjY2SbSlBbPnIU39jFYttn/wAAAAAAAA== --Apple-Mail-18--359485315-- From rbriscoe@jungle.bt.co.uk Wed Aug 19 03:59:32 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 3B95F3A6864 for ; Wed, 19 Aug 2009 03:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 tDlIfL30UJ4S for ; Wed, 19 Aug 2009 03:59:24 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D14B23A6CEA for ; Wed, 19 Aug 2009 03:59:08 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 11:59:09 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 11:59:09 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1250679547190; Wed, 19 Aug 2009 11:59:07 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7JAx3hn019241; Wed, 19 Aug 2009 11:59:03 +0100 Message-Id: <200908191059.n7JAx3hn019241@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Aug 2009 11:59:01 +0100 To: , From: Bob Briscoe In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0636375E@E03MVB1-UKBR.doma in1.systemhost.net> References: <4A8BC6F7.9070803@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC0636375E@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Aug 2009 10:59:09.0024 (UTC) FILETIME=[13B7E600:01CA20BC] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 10:59:32 -0000 Phil, Tho you're correct, I think Michael's point=20 was about excessive use of DSCPs. Michael, I agree (and this has been said in the=20 relevant encoding drafts, AFAIK). Ie. A PCN=20 encoding that uses 2 DSCPs will need a second=20 DSCP for every DSCP it is applied to. If it=20 applies to n DSCPs, it will consume 2n DSCPs. Bob At 10:45 19/08/2009, philip.eardley@bt.com wrote: >Yes, I think any of the extended pcn encodings=20 >that uses 2 dscps needs to say something about=20 >the scheduling behaviour of the 2 dscps. The=20 >obvious thing is that they both map to the same=20 >scheduling PHB (actually, first guess is that=20 >this is the only thing that makes sense) > >{ -----Original Message----- >{ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >{ Michael Menth >{ Sent: 19 August 2009 10:34 >{ To: Briscoe,RJ,Bob,XVR9 BRISCORJ R >{ Cc: pcn@ietf.org >{ Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >{ >{ Hi Bob, >{ >{ Bob Briscoe schrieb: >{ > Michael, >{ > >{ > Correct. >{ > >{ > (Except, there is a wrinkle about clearing the ECN field at the >{ > egress; only if e2e ECN is not being used.) >{ > >{ > The ASCII art was merely intended to explain why we can't assume there >{ > will be just one DSCP for PCN traffic. The lo-stat-mux part of a >{ > network treats multiple DSCPs with multiple PHBs. But even if they all >{ > get treated with the same PHB within a hi-stat-mux core, they don't >{ > all necessarily get mapped to one DSCP (so that they can be separated >{ > out again on the other side). >{ I understand. That makes any marking behavior using two DSCPs even more >{ problematic, right? >{ >{ Regards, >{ >{ Michael >{ >{ >{ > >{ > >{ > >{ > Bob >{ > >{ > At 09:51 19/08/2009, Michael Menth wrote: >{ >> Hi, >{ >> >{ >> I'm not sure whether the ASCII art is needed at all and I did not >{ >> really understand it. The following message arrived with me: >{ >> >{ >> PCN is locally applied to some specific DSCPs with the same >{ >> scheduling behavior (I don't think that we can allow different one, >{ >> this requires more study). If PCN marking applies to them, the ECN >{ >> field of corresponding packets is set to an appropriate value by the >{ >> ingress node, else it is set to 00. After leaving the domain, the PCN >{ >> egress node clears the ECN field with 00. This way, no new DSCPs are >{ >> needed for PCN. >{ >> >{ >> Or have I missed a critical point? >{ >> >{ >> Regards, >{ >> >{ >> Michael >{ >> >{ >> >{ >> >{ >> toby.moncaster@bt.com schrieb: >{ >>> >{ >>> That ASCII art is still unreadable because (for me at least) it is >{ >>> getting displayed in a variable-width font (Times New Roman to be >{ >>> exact). I ended up having to convert it to Courier to be able to see >{ >>> what you meant... >{ >>> >{ >>> I am in the process of drafting a reply setting out the background >{ >>> to this confusion and hopefully solving it. In the meantime there >{ >>> seems to be a consensus that the way ahead is to recommend PCN as >{ >>> suitable for 1 or more EXISTING DSCPs (which means we need to decide >{ >>> which ones...). But that still leaves the question of whether we need >{ >>> to say something about what needs to happen in the future if someone >{ >>> (say Fred Baker) wants to add PCN to a new DSCP. >{ >>> >{ >>> Toby >{ >>> >{ >>> *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R >{ >>> *Sent:* 19 August 2009 09:29 >{ >>> *To:* Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R >{ >>> *Cc:* pcn@ietf.org >{ >>> *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >{ >>> >{ >>> Ruediger, >{ >>> >{ >>> Great. >{ >>> >{ >>> [As some people couldn't read it, I've also replaced the diag quoted >{ >>> in the thread below with narrower ASCII-art to better survive word >{ >>> wrap] >{ >>> >{ >>> Cheers >{ >>> >{ >>> >{ >>> Bob >{ >>> >{ >>> At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: >{ >>> >{ >>> Hi Bob, >{ >>> >{ >>> I agree to your suggestion to "scrub (ii) and only have (i)..[and >{ >>> that] we should list classes that might be appropriate to associate >{ >>> with PCN marking." >{ >>> >{ >>> Regards, >{ >>> >{ >>> Ruediger >{ >>> >{ >>>= ---------------------------------------------------------------------- >{ -- >{ >>> >{ >>> >{ >>> *From:* Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk] >{ >>> *Sent:* Tuesday, August 18, 2009 7:37 PM >{ >>> *To:* Geib, R=FCdiger; toby.moncaster@bt.com >{ >>> *Cc:* pcn@ietf.org >{ >>> *Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >{ >>> >{ >>> Ruediger, >{ >>> >{ >>> The draft as it stands holds two inconsistent opinions: >{ >>> i) " >{ >>> >{ >>> the aim is for PCN to re-use existing DSCPs >{ >>> >{ >>> >{ >>> " (S.4.3.1) >{ >>> ii) the second half of Appx A.1, repeated below. >{ >>> >{ >>> Similarly, your posting, talks about: >{ >>> i) applying PCN to existing DSCPs >{ >>> ii) reserving DSCPs for PCN. >{ >>> >{ >>> I believe we should scrub (ii) and only have (i). In place of ii) we >{ >>> should list the classes that might be appropriate to associate with >{ >>> PCN marking. >{ >>> >{ >>> In other words, we should only say that an operator _applies_ PCN >{ >>> marking to certain existing DSCPs. >{ >>> >{ >>> No-one needs any additional DSCPs to enable PCN marking. Otherwise >{ >>> that would waste DSCPs just to get a different marking behaviour for >{ >>> packets requiring the same scheduling behaviour as a pre-existing >{ >>> DSCP. The non-wasteful way to do this is to use one DSCP for a >{ >>> certain scheduling behaviour, but set the ECN field to a non-zero >{ >>> value to turn on PCN marking (S.4.3.1). >{ >>> >{ >>> [In MPLS, as there is no ECN field, the efficient way is different. >{ >>> Then RFC5129 describes how you would do it.] >{ >>> >{ >>> To be absolutely sure it's clear what I mean, here's an example: >{ >>> >{ >>> >{ >>> hi stat mux subnet >{ >>> ___________________ >{ >>> | same | >{ >>> | marking | >{ >>> | _____ ____:___ | >{ >>> | | || || >{ >>> --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- >{ >>> | | || || >{ >>> --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- >{ >>> | | ||________|| >{ >>> | | | | >{ >>> --DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- >{ >>> | |_____| | >{ >>> | _____ | >{ >>> | | | | >{ >>> --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ >{ >>> | | | | >{ >>> --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- >{ >>> | |_____| | >{ >>> | : | >{ >>> | same | >{ >>> | scheduling | >{ >>> | (BA) | >{ >>> |___________________| >{ >>> >{ >>> >{ >>> - The text on each flow shows the DSCP-ECN combination used for that >{ >>> segment >{ >>> - The boxes around DSCPA/B/C and around DSCPD/E represent the same >{ >>> scheduling behaviour applied to multiple DSCPs in the aggregated >{ >>> region (a behaviour aggregate). >{ >>> - The box around NM for the first two flows represents the same >{ >>> marking behaviour (PCN) applied to multiple DSCPs. >{ >>> - The flows keep the same DSCP* along their whole path, so when they >{ >>> pop out into the lo-stat-mux region on the other side, the DSCP is >{ >>> preserved. >{ >>> - In practice, traffic might be tunnelled across the hi-stat mux >{ >>> region, and at the same time common scheduling behaviours might be >{ >>> mapped to a single DSCP in the outer headers. The diagram merely >{ >>> shows everything can be done without tunnelling or layering. >{ >>> >{ >>> * Note: For some non-standardised DSCPs, the DSCP might not actually >{ >>> stay the same along the whole path. It might be mapped to local >{ >>> DSCPs that are each used for the same class at different points >{ >>> along the path. >{ >>> >{ >>> >{ >>> Here's a copy of the 2nd half of Appx A.1, that I think needs to be >{ >>> removed (sorry, I know I'm a co-author, but...): >{ >>> " The choice of which DSCP is most suitable for >{ >>> a given PCN-domain is dependant on the nature of the >{ >>> traffic >{ >>> entering >{ >>> that domain and the link rates of all the links making up >{ >>> that >{ >>> domain. In PCN-domains with uniformly high link >{ >>> rates, >{ >>> the >{ >>> appropriate DSCPs would currently be those for the Real >{ >>> Time >{ >>> Traffic >{ >>> Class >{ >>> [RFC5127 ]. If the >{ >>> PCN domain includes lower speed links it >{ >>> would also be appropriate to use the DSCPs of the other >{ >>> traffic >{ >>> classes that >{ >>> [ >{ >>> { Voice-Admit> >{ >>> >{ >>> Voice-Admit >{ >>> { Voice-Admit>] >{ >>> defines for use with admission control, >{ >>> such as the three video classes CS4, CS3 and AF4 and the >{ >>> Admitted >{ >>> Telephony Class. The PCN working group will maintain >{ >>> a >{ >>> list of PCN- >{ >>> compatible Diffserv Codepoints. >{ >>> >{ >>> >{ >>> " >{ >>> >{ >>> At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: >{ >>> >{ >>> Toby, >{ >>> >{ >>> PCN should express to the IANA, whether one or more new DSCP is >{ >>> required to operate or carry out experiments on PCN. >{ >>> >{ >>> As soon as IANA maintains a list of DSCPs for any purpose, this >{ >>> will have the status of a standard. >{ >>> >{ >>> "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs >{ >>> per traffic class (DSCP bit 0-2, let's call them traffic class >{ >>> in this email) for PCN, that's 32 DSCPs in all. >{ >>> >{ >>> If possible, PCN should limit the number of traffic classes, >{ >>> where to apply PCN. >{ >>> >{ >>> I don't think PCN will be applied in traffic classes 0 and 6. >{ >>> >{ >>> I'd expect PCN to be used within traffic classes 5 and 4, >{ >>> may be also 3 or 2. >{ >>> >{ >>> Traffic classes 1 and 7 may be excluded too. >{ >>> >{ >>> The above clearly expresses personal views, but informational >{ >>> RFC5127 to some extent backs these personal views. >{ >>> >{ >>> I'm aware that PCN WG shouldn't standardise traffic class usage >{ >>> or come close to that. I however want to avoid repeating the biggest >{ >>> flaw of the AF specification, which in my eyes is to reserve >{ >>> 12 DSCPs for 4 traffic classes. >{ >>> >{ >>> Regards, >{ >>> >{ >>> Ruediger >{ >>> >{ >>> >{ >>> >{ >>> -----Original Message----- >{ >>> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf >{ >>> Of toby.moncaster@bt.com >{ >>> Sent: Friday, August 14, 2009 3:06 PM >{ >>> To: lars.eggert@nokia.com; pcn@ietf.org >{ >>> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >{ >>> >{ >>> Hi Lars, >{ >>> >{ >>> Sorry not to get back to you earlier - been busy at work so this >{ >>> went on >{ >>> a back-burner for a few days. >{ >>> >{ >>> The original intention of having registration was to avoid confusion >{ >>> during any early experimental adoption of PCN however that could be >{ >>> done >{ >>> purely unofficially by having a list of DSCPs on the IETF wiki and >{ just >{ >>> politely asking developers to consult it and add any new ones they= are >{ >>> using. But there will need in future to be a process to formally >{ >>> register certain standards (pool 1) DSCPs as PCN-compatible since= this >{ >>> effectively replaces ECN as the default behaviour for such DSCPs. So >{ my >{ >>> suggestion is: >{ >>> >{ >>> Change the IANA section to say something along the following lines (I >{ >>> will get IANA assistance with crafting exact text): >{ >>> >{ >>> "IANA will be asked to set up a registry of PCN-compatible Diffserv >{ >>> codepoints. The decision as to whether to enable PCN for a given pool >{ 1 >{ >>> codepoint must be made by the appropriate IETF Transport Area Working >{ >>> Group (TSVWG?) which will then request IANA to add this to the >{ >>> registry." >{ >>> >{ >>> Clarify at start of A.1 that the decision of which DSCPs to apply >{ >>> PCN to >{ >>> has to be made by TSVWG and is separate to this document which just >{ >>> defines the process and the encoding. >{ >>> >{ >>> Change the last sentence of A.1 to "IANA will maintain a list of >{ >>> PCN-compatible Diffserv Codepoints." >{ >>> >{ >>> Would this cover things appropriately? I did wonder about asking >{ >>> IANA to >{ >>> maintain the experimental registry but I am not sure if they are >{ >>> able to >{ >>> do that sort of thing? If so the following could be added to the IANA >{ >>> section: >{ >>> >{ >>> "During the early stages of adoption it is envisaged that PCN will be >{ >>> used experimentally using pool 2 or 3 DSCPs (experimental or local >{ >>> use). >{ >>> Whilst these DSCPs are not controlled by IANA normally, a request= will >{ >>> be made to maintain a list of PCN experiments along with the DSCPs >{ >>> these >{ >>> experiments are using." >{ >>> >{ >>> Once I get the nod from WG I will release a new version of the I-D >{ with >{ >>> these updates... >{ >>> >{ >>> Toby >{ >>> >{ >>> > -----Original Message----- >{ >>> > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On >{ >>> Behalf Of >{ >>> > Lars Eggert >{ >>> > Sent: 14 August 2009 12:27 >{ >>> > To: pcn@ietf.org >{ >>> > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >{ >>> > >{ >>> > Hi, >{ >>> > >{ >>> > I'm waiting to hear from the authors/WG. >{ >>> > >{ >>> > Lars >{ >>> > >{ >>> > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >{ >>> > >{ >>> > > Hi, >{ >>> > > >{ >>> > > this document is ready, except for one issue: >{ >>> > > >{ >>> > > Section 7., paragraph 1: >{ >>> > >> This document makes no direct request to IANA. However this >{ >>> > > document >{ >>> > >> allows for a set of Diffserv Codepoints to be assigned different >{ >>> > > ECN >{ >>> > >> semantics within a controlled domain as described in [RFC4774]. >{ >>> A >{ >>> > >> list of such DSCPs will be maintained by the PCN working group. >{ >>> > > >{ >>> > > DISCUSS: This text isn't aligned with appendix A.1. The text here >{ >>> > > says >{ >>> > > "the WG will maintain a list of DSCPs that are OK", while the >{ >>> > > beginning of appendix A.1 says "the WG decided to not define with >{ >>> > > which DSCPs PCN can be used" (but then the end of A.1 talks about >{ >>> > > maintaining a list again.) Which is it? If there is to be a list, >{ >>> > > you >{ >>> > > need to create an IANA registry, write management procedures for >{ >>> it >{ >>> > > (see RFC5226) and populate it with some initial values. (WGs are >{ >>> > > ephemeral, which is why the PCN WG can't be the maintainer of= this >{ >>> > > list, IANA has to be.) If you want to leave it fully open for >{ >>> > > deployments, you need to remove this confusion from the text. >{ >>> > > >{ >>> > > Lars >{ >>> > > >{ >>> > > >{ >>> > > Nits: >{ >>> > > >{ >>> > > Section 4., paragraph 3: >{ >>> > >> to prevent future compatability issues. >{ >>> > > >{ >>> > > Nit: s/compatability/compatibility/ >{ >>> > > >{ >>> > > >{ >>> > > Section 4.2., paragraph 1: >{ >>> > >> that is guaranteeed to be copied down into the inner header upon >{ >>> > > >{ >>> > > Nit: s/guaranteeed/guaranteed/ >{ >>> > > >{ >>> > > >{ >>> > > Section 6., paragraph 1: >{ >>> > >> always copy the CE codepoint from teh outer header into the= inner >{ >>> > > >{ >>> > > Nit: s/teh/the/ >{ >>> > > >{ >>> > > >{ >>> > > Section 6., paragraph 2: >{ >>> > >> header in decapsulation (unless the inner packet is not-ECT). >{ >>> > > If an >{ >>> > >> operator it is essential that any operator wishing to allow ECN >{ >>> to >{ >>> > >> exist end-to-end ensures there are no tunnel end-points within >{ >>> the >{ >>> > >> PCN-domain. >{ >>> > > >{ >>> > > "If an operator it is essential that any operator..." - wording >{ >>> > > >{ >>> > > >{ >>> > > Section 12., paragraph 0: >{ >>> > >> 12. References >{ >>> > > >{ >>> > > Should be updated; see idnits report. >{ >>> > > >{ >>> > > >{ >>> > > Appendix A., paragraph 2: >{ >>> > >> a given PCN-domain is dependant on the nature of the traffic >{ >>> > > entering >{ >>> > > >{ >>> > > Nit: s/dependant/dependent/ >{ >>> > > >{ >>> > > >{ >>> >{ >>> _______________________________________________ >{ >>> PCN mailing list >{ >>> PCN@ietf.org >{ >>> https://www.ietf.org/mailman/listinfo/pcn >{ >>> _______________________________________________ >{ >>> PCN mailing list >{ >>> PCN@ietf.org >{ >>> https://www.ietf.org/mailman/listinfo/pcn >{ >>> >{ >>>= ---------------------------------------------------------------------- >{ -- >{ >>> >{ >>> >{ >>> _______________________________________________ >{ >>> PCN mailing list >{ >>> PCN@ietf.org >{ >>> https://www.ietf.org/mailman/listinfo/pcn >{ >>> >{ >> >{ >> -- >{ >> 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 >{ >{ -- >{ 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 rbriscoe@jungle.bt.co.uk Wed Aug 19 04:13: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 B2B303A6C86 for ; Wed, 19 Aug 2009 04:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAQmLqGkN2Gc for ; Wed, 19 Aug 2009 04:13:32 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B4DFC3A6828 for ; Wed, 19 Aug 2009 04:13:31 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:13:36 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:13:34 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1250680411964; Wed, 19 Aug 2009 12:13:31 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7JBDRFv019578; Wed, 19 Aug 2009 12:13:27 +0100 Message-Id: <200908191113.n7JBDRFv019578@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Aug 2009 12:13:25 +0100 To: Lars Eggert , toby.moncaster@bt.com From: Bob Briscoe In-Reply-To: <3423E723-5C5E-44C0-98A0-E056C8C8B02C@nokia.com> References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <3423E723-5C5E-44C0-98A0-E056C8C8B02C@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Aug 2009 11:13:34.0457 (UTC) FILETIME=[178E7E90:01CA20BE] Cc: "pcn@ietf.org" Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 11:13:38 -0000 Lars, Toby, Yup, seems the way to go. Concerning: >"explain what we would expect >needed to happen if people wanted to suggest other DSCPs that it could >apply to (either existing or new ones). " I don't see this as a big issue. It's just advice (informational appendix). If an operator applies PCN to a DSCP that isn't on the list, AFAIK it doesn't create any interworking problem that the IETF needs to worry about (noting that the charter says we have to keep interconnection in mind). So we don't need a process for the IETF to _approve_ the use of PCN for a DSCP not on the list. Already some operators choose to apply admission control to a class while others don't. Introducing PCN to the RFC series simply adds another choice of mechanism with which to do admission control. But that doesn't create any more of an interworking problem than there was originally with operators choosing which classes they do admission control for. Even if they do PCN interconnect purely in the data plane, without back-to-back edge gateways at the interconnect, it doesn't create any greater interworking problem than they already have. They already have to agree between themselves if they want to do inter-domain admission control for a class. And they have to agree the mechanism. So surely PCN is just added to that conversation as another mechanism choice. Bob At 11:35 19/08/2009, Lars Eggert wrote: >Hi, > >this sounds like a reasonable way forward. > >Lars > >On 2009-8-19, at 11:30, toby.moncaster@bt.com wrote: > >>My proposed solution (based on the comments over the past 3 days) aims >>to do two things, firstly to clarify that PCN is an alternative >>marking >>behaviour that Operators can specify for certain DSCPs (without >>changing >>the scheduling or other behaviours), secondly it should recommend 1 >>(or >>more) DSCPs that are currently suitable and should list what we >>believe >>are the criteria for suitability AND/OR explain what we would expect >>needed to happen if people wanted to suggest other DSCPs that it could >>apply to (either existing or new ones). This second bit is more thorny >>and I am not sure I am best placed to do it. I would welcome any >>offers >>of text for that bit... >> >>The end result will be that we have a doc that really makes no IANA >>requests, that suggests a suitable DSCP to apply PCN to initially and >>that explains what makes that DSCP suitable... > > > From rbriscoe@jungle.bt.co.uk Wed Aug 19 05:51: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 AC2FC3A6AE7 for ; Wed, 19 Aug 2009 05:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-1.874, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, 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 FJjb1OYIPeCV for ; Wed, 19 Aug 2009 05:51:19 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id A99F13A6A8C for ; Wed, 19 Aug 2009 05:51:18 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 13:51:21 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 13:51:21 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1250686281358; Wed, 19 Aug 2009 13:51:21 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7JCpHG7021784; Wed, 19 Aug 2009 13:51:17 +0100 Message-Id: <200908191251.n7JCpHG7021784@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Aug 2009 13:51:13 +0100 To: , From: Bob Briscoe In-Reply-To: References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Aug 2009 12:51:22.0001 (UTC) FILETIME=[C0E2A810:01CA20CB] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 12:51:26 -0000 Toby,

At 09:39 19/08/2009, toby.moncaster@bt.com wrote:
That ASCII art is still unreadable because (for me at least) it is getting displayed in a variable-width font (Times New Roman to be exact). I ended up having to convert it to Courier to be able to see what you meant=85

The Tao of email says that's your problem. I sent it as plain text (and even if I didn't it would have been Courier New (fixed)).

 
I am in the process of drafting a reply setting out the background to this confusion and hopefully solving it. In the meantime there seems to be a consensus that the way ahead is to recommend PCN as suitable for 1 or more EXISTING DSCPs (which means we need to decide which ones=85). But that still leaves the question of whether we need to say something about what needs to happen in the future if someone (say Fred Baker) wants to add PCN to a new DSCP.

Ruediger has suggested some. Can you check them off against those that Fred discusses in voice-admit. That should give a decent list.


Bob

 
Toby
 
From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009 09:29
To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R
Cc: pcn@ietf.org
Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
 
Ruediger,

Great.

[As some people couldn't read it, I've also replaced the diag quoted in the thread below with narrower ASCII-art to better survive word wrap]

Cheers


Bob

At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote:

Hi Bob,
 
I agree to your suggestion to "scrub (ii) and only have (i)..[and that] we should list classes that might be appropriate to associate with PCN marking."
 
Regards,
 
Ruediger
From: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, R=FCdiger; toby.moncaster@bt.com
Cc: pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

The draft as it stands holds two inconsistent opinions:
i) "

the aim is for PCN to re-use existing DSCPs


" (S.4.3.1)
ii) the second half of Appx A.1, repeated below.

Similarly, your posting, talks about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for PCN.

I believe we should scrub (ii) and only have (i). In place of ii) we should list the classes that might be appropriate to associate with PCN marking.

In other words, we should only say that an operator _applies_ PCN marking to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that would waste DSCPs just to get a different marking behaviour for packets requiring the same scheduling behaviour as a pre-existing DSCP. The non-wasteful way to do this is to use one DSCP for a certain scheduling behaviour, but set the ECN field to a non-zero value to turn on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the efficient way is different. Then RFC5129 describes how you would do it.]

To be absolutely sure it's clear what I mean, here's an example:

            &nbs= p;      hi stat mux subnet
            &nbs= p;      ___________________
            &nbs= p;     |            same   |
            &nbs= p;     |           marking |
            &nbs= p;     |   _____  ____:___ |
            &nbs= p;     |  |     ||        ||
--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
            &nbs= p;     |  |     ||        ||
--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
            &nbs= p;     |  |     ||________||
            &nbs= p;     |  |     |          |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
            &nbs= p;     |  |_____|          |
            &nbs= p;     |   _____           |
            &nbs= p;     |  |     |          |
--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
            &nbs= p;     |  |     |          |
--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
            &nbs= p;     |  |_____|          |
            &nbs= p;     |     :             |
            &nbs= p;     |   same            |
            &nbs= p;     | scheduling        |
            &nbs= p;     |   (BA)            |
            &nbs= p;     |___________________|


- The text on each flow shows the DSCP-ECN combination used for that segment
- The boxes around DSCPA/B/C and around DSCPD/E represent the same scheduling behaviour applied to multiple DSCPs in the aggregated region (a behaviour aggregate).
- The box around NM for the first two flows represents the same marking behaviour (PCN) applied to multiple DSCPs.
- The flows keep the same DSCP* along their whole path, so when they pop out into the lo-stat-mux region on the other side, the DSCP is preserved.
- In practice, traffic might be tunnelled across the hi-stat mux region, and at the same time common scheduling behaviours might be mapped to a single DSCP in the outer headers. The diagram merely shows everything can be done without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually stay the same along the whole path. It might be mapped to local DSCPs that are each used for the same class at different points along the path.



Here's a copy of the 2nd half of Appx A.1, that I think needs to
be


removed (sorry, I know I'm a co-author, but...):


"  The choice of which DSCP is most suitable
for


   a given PCN-domain is dependant on the nature of
the


traffic


entering


   that domain and the link rates of all the links making
up


that


   domain.  In PCN-domains with uniformly high
link


rates,


the


   appropriate DSCPs would currently be those for the
Real


Time


Traffic


   Class


[RFC5127].  If
the


PCN domain includes lower speed links it


   would also be appropriate to use the DSCPs of the
other


traffic


   classes that



[



Voice-Admit] defines for use with admission control,


   such as the three video classes CS4, CS3 and AF4 and
the


Admitted


   Telephony Class.  The PCN working group will
maintain


a


list of PCN-


   compatible Diffserv Codepoints.


"

At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:
Toby,

PCN should express to the IANA, whether one or more new DSCP is
required to operate or carry out experiments on PCN.

As soon as IANA maintains a list of DSCPs for any purpose, this
will have the status of a standard.

"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs
per traffic class (DSCP bit 0-2, let's call them traffic class
in this email) for PCN, that's 32 DSCPs in all.

If possible, PCN should limit the number of traffic classes,
where to apply PCN.

I don't think PCN will be applied in traffic classes 0 and 6.

I'd expect PCN to be used within traffic classes 5 and 4,
may be also 3 or 2.
Traffic classes 1 and 7 may be excluded too.

The above clearly expresses personal views, but informational
RFC5127 to some extent backs these personal views.

I'm aware that PCN WG shouldn't standardise traffic class usage
or come close to that. I however want to avoid repeating the biggest
flaw of the AF specification, which in my eyes is to reserve
12 DSCPs for 4 traffic classes.

Regards,

Ruediger



-----Original Message-----
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com
Sent: Friday, August 14, 2009 3:06 PM
To: lars.eggert@nokia.com; pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went on
a back-burner for a few days.

The original intention of having registration was to avoid confusion
during any early experimental adoption of PCN however that could be done
purely unofficially by having a list of DSCPs on the IETF wiki and just
politely asking developers to consult it and add any new ones they are
using. But there will need in future to be a process to formally
register certain standards (pool 1) DSCPs as PCN-compatible since this
effectively replaces ECN as the default  behaviour for such DSCPs. So my
suggestion is:

Change the IANA section to say something along the following lines (I
will get IANA assistance with crafting exact text):

"IANA will be asked to set up a registry of PCN-compatible Diffserv
codepoints. The decision as to whether to enable PCN for a given pool 1
codepoint must be made by the appropriate IETF Transport Area Working
Group (TSVWG?) which will then request IANA to add this to the
registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN to
has to be made by TSVWG and is separate to this document which just
defines the process and the encoding.

Change the last sentence of A.1 to "IANA will maintain a list of
PCN-compatible Diffserv Codepoints."

Would this cover things appropriately? I did wonder about asking IANA to
maintain the experimental registry but I am not sure if they are able to
do that sort of thing? If so the following could be added to the IANA
section:

"During the early stages of adoption it is envisaged that PCN will be
used experimentally using pool 2 or 3 DSCPs (experimental or local use).
Whilst these DSCPs are not controlled by IANA normally, a request will
be made to maintain a list of PCN experiments along with the DSCPs these
experiments are using."

Once I get the nod from WG I will release a new version of the I-D with
these updates...

Toby

> -----Original Message-----
> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To: pcn@ietf.org
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
>
> Hi,
>
> I'm waiting to hear from the authors/WG.
>
> Lars
>
> On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
>
> > Hi,
> >
> > this document is ready, except for one issue:
> >
> > Section 7., paragraph 1:
> >>   This document makes no direct request to IANA.  However this
> > document
> >>   allows for a set of Diffserv Codepoints to be assigned different
> > ECN
> >>   semantics within a controlled domain as described in [RFC4774].
A
> >>   list of such DSCPs will be maintained by the PCN working group.
> >
> >   DISCUSS: This text isn't aligned with appendix A.1. The text here
> > says
> >   "the WG will maintain a list of DSCPs that are OK", while the
> >   beginning of appendix A.1 says "the WG decided to not define with
> >   which DSCPs PCN can be used" (but then the end of A.1 talks about
> >   maintaining a list again.) Which is it? If there is to be a list,
> > you
> >   need to create an IANA registry, write management procedures for
it
> >   (see RFC5226) and populate it with some initial values. (WGs are
> >   ephemeral, which is why the PCN WG can't be the maintainer of this
> >   list, IANA has to be.) If you want to leave it fully open for
> >   deployments, you need to remove this confusion from the text.
> >
> > Lars
> >
> >
> > Nits:
> >
> > Section 4., paragraph 3:
> >>           &n= bsp;      to prevent future compatability issues.
> >
> >   Nit: s/compatability/compatibility/
> >
> >
> > Section 4.2., paragraph 1:
> >>   that is guaranteeed to be copied down into the inner header upon
> >
> >   Nit: s/guaranteeed/guaranteed/
> >
> >
> > Section 6., paragraph 1:
> >>   always copy the CE codepoint from teh outer header into the inner
> >
> >   Nit: s/teh/the/
> >
> >
> > Section 6., paragraph 2:
> >>   header in decapsulation (unless the inner packet is not-ECT).
> > If an
> >>   operator it is essential that any operator wishing to allow ECN
to
> >>   exist end-to-end ensures there are no tunnel end-points within
the
> >>   PCN-domain.
> >
> >   "If an operator it is essential that any operator..." - wording
> >
> >
> > Section 12., paragraph 0:
> >> 12.  References
> >
> >   Should be updated; see idnits report.
> >
> >
> > Appendix A., paragraph 2:
> >>   a given PCN-domain is dependant on the nature of the traffic
> > entering
> >
> >   Nit: s/dependant/dependent/
> >
> > <smime.p7s><ATT00001.txt>

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn
From toby.moncaster@bt.com Wed Aug 19 06:28: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 653513A6DBC for ; Wed, 19 Aug 2009 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EqIPKalh00ZL for ; Wed, 19 Aug 2009 06:28:33 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 59EF728C3A7 for ; Wed, 19 Aug 2009 06:28:32 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 14:28:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA20D0.D745706B" x-cr-hashedpuzzle: BwP5 CYFl CtAY G+ki HS4T HVeB IbVl J9HZ KWir MA91 MiLv OGdV QzEE Q0A/ Rnqu SGhX; 2; cABjAG4AQABpAGUAdABmAC4AbwByAGcAOwByAHUAZQBkAGkAZwBlAHIALgBnAGUAaQBiAEAAdABlAGwAZQBrAG8AbQAuAGQAZQA=; Sosha1_v1; 7; {C0678331-E0F0-46E6-AEE4-2D324E28A70D}; dABvAGIAeQAuAG0AbwBuAGMAYQBzAHQAZQByAEAAYgB0AC4AYwBvAG0A; Wed, 19 Aug 2009 13:27:39 GMT; UgBFADoAIABbAFAAQwBOAF0AIABBAEQAIAByAGUAdgBpAGUAdwA6ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHAAYwBuAC0AYgBhAHMAZQBsAGkAbgBlAC0AZQBuAGMAbwBkAGkAbgBnAC0AMAA0AA== x-cr-puzzleid: {C0678331-E0F0-46E6-AEE4-2D324E28A70D} Content-class: urn:content-classes:message Date: Wed, 19 Aug 2009 14:27:39 +0100 Message-ID: In-Reply-To: <200908191251.n7JCpHG7021784@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: Acogy8FdcdcongXRQFy1iBZvE2AFegABIaTA References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <200908191251.n7JCpHG7021784@bagheera.jungle.bt.co.uk> From: To: , X-OriginalArrivalTime: 19 Aug 2009 13:28:36.0651 (UTC) FILETIME=[F4D72FB0:01CA20D0] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 13:28:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA20D0.D745706B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leaving aside ASCII art. =20 >From Ruediger's list below and Fred's draft the following seems like a = possible list of DSCPs that might reasonably employ PCN marking: =20 CS2, CS3, CS4, CS5, AF4. =20 Phil in an earlier email suggested EF as well. =20 Does that seem like a sensible list? Should we actually play it safe and = reduce it slightly? =20 Toby =20 =20 From: Briscoe,RJ,Bob,XVR9 BRISCORJ R=20 Sent: 19 August 2009 13:51 To: Moncaster,T,Toby,DER3 R; Ruediger.Geib@telekom.de Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 =20 Toby, At 09:39 19/08/2009, toby.moncaster@bt.com wrote: That ASCII art is still unreadable because (for me at least) it is = getting displayed in a variable-width font (Times New Roman to be = exact). I ended up having to convert it to Courier to be able to see = what you meant... The Tao of email says that's your problem. I sent it as plain text (and = even if I didn't it would have been Courier New (fixed)).=20 =20 I am in the process of drafting a reply setting out the background to = this confusion and hopefully solving it. In the meantime there seems to = be a consensus that the way ahead is to recommend PCN as suitable for 1 = or more EXISTING DSCPs (which means we need to decide which ones...). = But that still leaves the question of whether we need to say something = about what needs to happen in the future if someone (say Fred Baker) = wants to add PCN to a new DSCP. Ruediger has suggested some. Can you check them off against those that = Fred discusses in voice-admit. That should give a decent list. Bob =20 Toby =20 From: Briscoe,RJ,Bob,XVR9 BRISCORJ R=20 Sent: 19 August 2009 09:29 To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 =20 Ruediger, Great. [As some people couldn't read it, I've also replaced the diag quoted in = the thread below with narrower ASCII-art to better survive word wrap] Cheers Bob At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: Hi Bob, =20 I agree to your suggestion to "scrub (ii) and only have (i)..[and that] = we should list classes that might be appropriate to associate with PCN = marking." =20 Regards, =20 Ruediger ________________________________ From: Bob Briscoe [ = mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: Tuesday, August 18, 2009 7:37 PM To: Geib, R=FCdiger; toby.moncaster@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Ruediger, The draft as it stands holds two inconsistent opinions: i) " the aim is for PCN to re-use existing DSCPs " (S.4.3.1) ii) the second half of Appx A.1, repeated below. Similarly, your posting, talks about: i) applying PCN to existing DSCPs ii) reserving DSCPs for PCN. I believe we should scrub (ii) and only have (i). In place of ii) we = should list the classes that might be appropriate to associate with PCN = marking. In other words, we should only say that an operator _applies_ PCN = marking to certain existing DSCPs. No-one needs any additional DSCPs to enable PCN marking. Otherwise that = would waste DSCPs just to get a different marking behaviour for packets = requiring the same scheduling behaviour as a pre-existing DSCP. The = non-wasteful way to do this is to use one DSCP for a certain scheduling = behaviour, but set the ECN field to a non-zero value to turn on PCN = marking (S.4.3.1). [In MPLS, as there is no ECN field, the efficient way is different. Then = RFC5129 describes how you would do it.] To be absolutely sure it's clear what I mean, here's an example: hi stat mux subnet ___________________ | same | | marking | | _____ ____:___ | | | || || --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- | | || || --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- | | ||________|| | | | = |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- | |_____| | | _____ | | | | | --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ | | | | --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- | |_____| | | : | | same | | scheduling | | (BA) | |___________________| - The text on each flow shows the DSCP-ECN combination used for that = segment - The boxes around DSCPA/B/C and around DSCPD/E represent the same = scheduling behaviour applied to multiple DSCPs in the aggregated region = (a behaviour aggregate). - The box around NM for the first two flows represents the same marking = behaviour (PCN) applied to multiple DSCPs. - The flows keep the same DSCP* along their whole path, so when they pop = out into the lo-stat-mux region on the other side, the DSCP is = preserved. - In practice, traffic might be tunnelled across the hi-stat mux region, = and at the same time common scheduling behaviours might be mapped to a = single DSCP in the outer headers. The diagram merely shows everything = can be done without tunnelling or layering. * Note: For some non-standardised DSCPs, the DSCP might not actually = stay the same along the whole path. It might be mapped to local DSCPs = that are each used for the same class at different points along the = path. Here's a copy of the 2nd half of Appx A.1, that I think needs to be =20 removed (sorry, I know I'm a co-author, but...): =20 " The choice of which DSCP is most suitable for =20 a given PCN-domain is dependant on the nature of the =20 traffic =20 entering =20 that domain and the link rates of all the links making up =20 that =20 domain. In PCN-domains with uniformly high link =20 rates, =20 the =20 appropriate DSCPs would currently be those for the Real =20 Time =20 Traffic =20 Class =20 [RFC5127 ]. If the =20 PCN domain includes lower speed links it =20 would also be appropriate to use the DSCPs of the other =20 traffic =20 classes that =20 =20 =20 [ = =20 =20 =20 =20 Voice-Admit = ] defines for use with admission control, =20 such as the three video classes CS4, CS3 and AF4 and the =20 Admitted =20 Telephony Class. The PCN working group will maintain =20 a =20 list of PCN- =20 compatible Diffserv Codepoints. " At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: Toby, PCN should express to the IANA, whether one or more new DSCP is=20 required to operate or carry out experiments on PCN. As soon as IANA maintains a list of DSCPs for any purpose, this=20 will have the status of a standard.=20 "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs=20 per traffic class (DSCP bit 0-2, let's call them traffic class=20 in this email) for PCN, that's 32 DSCPs in all. If possible, PCN should limit the number of traffic classes,=20 where to apply PCN. I don't think PCN will be applied in traffic classes 0 and 6. I'd expect PCN to be used within traffic classes 5 and 4,=20 may be also 3 or 2. Traffic classes 1 and 7 may be excluded too. The above clearly expresses personal views, but informational=20 RFC5127 to some extent backs these personal views. I'm aware that PCN WG shouldn't standardise traffic class usage=20 or come close to that. I however want to avoid repeating the biggest=20 flaw of the AF specification, which in my eyes is to reserve=20 12 DSCPs for 4 traffic classes. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com Sent: Friday, August 14, 2009 3:06 PM To: lars.eggert@nokia.com; pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Hi Lars, Sorry not to get back to you earlier - been busy at work so this went on a back-burner for a few days.=20 The original intention of having registration was to avoid confusion during any early experimental adoption of PCN however that could be done purely unofficially by having a list of DSCPs on the IETF wiki and just politely asking developers to consult it and add any new ones they are using. But there will need in future to be a process to formally register certain standards (pool 1) DSCPs as PCN-compatible since this effectively replaces ECN as the default behaviour for such DSCPs. So my suggestion is: Change the IANA section to say something along the following lines (I will get IANA assistance with crafting exact text): "IANA will be asked to set up a registry of PCN-compatible Diffserv codepoints. The decision as to whether to enable PCN for a given pool 1 codepoint must be made by the appropriate IETF Transport Area Working Group (TSVWG?) which will then request IANA to add this to the registry." Clarify at start of A.1 that the decision of which DSCPs to apply PCN to has to be made by TSVWG and is separate to this document which just defines the process and the encoding. Change the last sentence of A.1 to "IANA will maintain a list of PCN-compatible Diffserv Codepoints." Would this cover things appropriately? I did wonder about asking IANA to maintain the experimental registry but I am not sure if they are able to do that sort of thing? If so the following could be added to the IANA section: "During the early stages of adoption it is envisaged that PCN will be used experimentally using pool 2 or 3 DSCPs (experimental or local use). Whilst these DSCPs are not controlled by IANA normally, a request will be made to maintain a list of PCN experiments along with the DSCPs these experiments are using." Once I get the nod from WG I will release a new version of the I-D with these updates... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 14 August 2009 12:27 > To: pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm waiting to hear from the authors/WG. >=20 > Lars >=20 > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, > > > > this document is ready, except for one issue: > > > > Section 7., paragraph 1: > >> This document makes no direct request to IANA. However this > > document > >> allows for a set of Diffserv Codepoints to be assigned different > > ECN > >> semantics within a controlled domain as described in [RFC4774]. A > >> list of such DSCPs will be maintained by the PCN working group. > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > says > > "the WG will maintain a list of DSCPs that are OK", while the > > beginning of appendix A.1 says "the WG decided to not define with > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > maintaining a list again.) Which is it? If there is to be a list, > > you > > need to create an IANA registry, write management procedures for it > > (see RFC5226) and populate it with some initial values. (WGs are > > ephemeral, which is why the PCN WG can't be the maintainer of this > > list, IANA has to be.) If you want to leave it fully open for > > deployments, you need to remove this confusion from the text. > > > > Lars > > > > > > Nits: > > > > Section 4., paragraph 3: > >> to prevent future compatability issues. > > > > Nit: s/compatability/compatibility/ > > > > > > Section 4.2., paragraph 1: > >> that is guaranteeed to be copied down into the inner header upon > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > Section 6., paragraph 1: > >> always copy the CE codepoint from teh outer header into the inner > > > > Nit: s/teh/the/ > > > > > > Section 6., paragraph 2: > >> header in decapsulation (unless the inner packet is not-ECT). > > If an > >> operator it is essential that any operator wishing to allow ECN to > >> exist end-to-end ensures there are no tunnel end-points within the > >> PCN-domain. > > > > "If an operator it is essential that any operator..." - wording > > > > > > Section 12., paragraph 0: > >> 12. References > > > > Should be updated; see idnits report. > > > > > > Appendix A., paragraph 2: > >> a given PCN-domain is dependant on the nature of the traffic > > entering > > > > Nit: s/dependant/dependent/ > > > > _______________________________________________ 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 ------_=_NextPart_001_01CA20D0.D745706B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Leaving aside ASCII art.

 

From Ruediger’s list below and Fred’s draft the following seems = like a possible list of DSCPs that might reasonably employ PCN = marking:

 

CS2, CS3, CS4, CS5, AF4.

 

Phil in an earlier email suggested EF as well.

 

Does that seem like a sensible list? Should we actually play it safe and = reduce it slightly?

 

Toby

 

 

From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009 13:51
To: Moncaster,T,Toby,DER3 R; Ruediger.Geib@telekom.de
Cc: pcn@ietf.org
Subject: RE: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04

 

Toby,

At 09:39 19/08/2009, toby.moncaster@bt.com wrote:

That ASCII art is still unreadable because (for me = at least) it is getting displayed in a variable-width font (Times New Roman to be = exact). I ended up having to convert it to Courier to be able to see what you meant…


The Tao of email says that's your problem. I sent it as plain text (and = even if I didn't it would have been Courier New (fixed)).


 
I am in the process of drafting a reply setting out the background to = this confusion and hopefully solving it. In the meantime there seems to be a consensus that the way ahead is to recommend PCN as suitable for 1 or = more EXISTING DSCPs (which means we need to decide which ones…). But = that still leaves the question of whether we need to say something about what = needs to happen in the future if someone (say Fred Baker) wants to add PCN to = a new DSCP.


Ruediger has suggested some. Can you check them off against those that = Fred discusses in voice-admit. That should give a decent list.


Bob


 
Toby
 
From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009 09:29
To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R
Cc: pcn@ietf.org
Subject: RE: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04
 
Ruediger,

Great.

[As some people couldn't read it, I've also replaced the diag quoted in = the thread below with narrower ASCII-art to better survive word wrap]

Cheers


Bob

At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote:

Hi Bob,
 
I agree to your suggestion to "scrub (ii) and only have (i)..[and = that] we should list classes that might be appropriate to associate with PCN marking."
 
Regards,
 
Ruediger

From: Bob = Briscoe [ mailto:rbriscoe@jungle.bt.co.uk<= /a>]
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, R=FCdiger; toby.moncaster@bt.com
Cc: pcn@ietf.org
Subject: Re: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04

Ruediger,

The draft as it stands holds two inconsistent opinions:
i) "

the aim is for PCN to re-use existing DSCPs



" (S.4.3.1)
ii) the second half of Appx A.1, repeated below.

Similarly, your posting, talks about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for PCN.

I believe we should scrub (ii) and only have (i). In place of ii) we = should list the classes that might be appropriate to associate with PCN = marking.

In other words, we should only say that an operator _applies_ PCN = marking to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that = would waste DSCPs just to get a different marking behaviour for packets = requiring the same scheduling behaviour as a pre-existing DSCP. The non-wasteful way = to do this is to use one DSCP for a certain scheduling behaviour, but set the = ECN field to a non-zero value to turn on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the efficient way is different. Then RFC5129 describes how you would do it.]

To be absolutely sure it's clear what I mean, here's an example:

            &= nbsp;      hi stat mux subnet
            &= nbsp;      ___________________
            &= nbsp;     |            same   |
            &= nbsp;     |           marking = |
            &= nbsp;     |   _____  ____:___ |
            &= nbsp;     |  |     = ||        ||
--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
            &= nbsp;     |  |     = ||        ||
--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
            &= nbsp;     |  |     ||________||
            &= nbsp;     |  |     |          |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
            &= nbsp;     |  |_____|          = |
            &= nbsp;     |   = _____           |
            &= nbsp;     |  |     |          |
--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
            &= nbsp;     |  |     |          |
--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
            &= nbsp;     |  |_____|          = |
            &= nbsp;     |     :            = |
            &= nbsp;     |   same            = |
            &= nbsp;     | scheduling        |
            &= nbsp;     |   (BA)            = |
            &= nbsp;     |___________________|


- The text on each flow shows the DSCP-ECN combination used for that = segment
- The boxes around DSCPA/B/C and around DSCPD/E represent the same = scheduling behaviour applied to multiple DSCPs in the aggregated region (a = behaviour aggregate).
- The box around NM for the first two flows represents the same marking behaviour (PCN) applied to multiple DSCPs.
- The flows keep the same DSCP* along their whole path, so when they pop = out into the lo-stat-mux region on the other side, the DSCP is = preserved.
- In practice, traffic might be tunnelled across the hi-stat mux region, = and at the same time common scheduling behaviours might be mapped to a single = DSCP in the outer headers. The diagram merely shows everything can be done = without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually = stay the same along the whole path. It might be mapped to local DSCPs that are = each used for the same class at different points along the path.


Here's a copy of the 2nd half of Appx A.1, that I think needs =
to
be

 

removed (sorry, I know I'm a co-author, but...):

 

"  The choice of which DSCP is most =
suitable
for

 

   a given PCN-domain is dependant on the nature =
of
the

 

traffic

 

entering

 

   that domain and the link rates of all the links =
making
up

 

that

 

   domain.  In PCN-domains with uniformly =
high
link

 

rates,

 

the

 

   appropriate DSCPs would currently be those for =
the
Real

 

Time

 

Traffic

 

   Class

 

[RFC5127].  =
If
the

 

PCN domain includes lower speed links it

 

   would also be appropriate to use the DSCPs of =
the
other

 

traffic

 

   classes that

 

 
[

 

 
Voice-Admit] defines for use with admission =
control,

 

   such as the three video classes CS4, CS3 and AF4 =
and
the

 

Admitted

 

   Telephony Class.  The PCN working group =
will
maintain

 

a

 

list of PCN-

 

   compatible Diffserv Codepoints.



"

At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:
Toby,

PCN should express to the IANA, whether one or more new DSCP is
required to operate or carry out experiments on PCN.

As soon as IANA maintains a list of DSCPs for any purpose, this
will have the status of a standard.

"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs =
per traffic class (DSCP bit 0-2, let's call them traffic class
in this email) for PCN, that's 32 DSCPs in all.

If possible, PCN should limit the number of traffic classes,
where to apply PCN.

I don't think PCN will be applied in traffic classes 0 and 6.

I'd expect PCN to be used within traffic classes 5 and 4,
may be also 3 or 2.
Traffic classes 1 and 7 may be excluded too.

The above clearly expresses personal views, but informational
RFC5127 to some extent backs these personal views.

I'm aware that PCN WG shouldn't standardise traffic class usage
or come close to that. I however want to avoid repeating the biggest =
flaw of the AF specification, which in my eyes is to reserve
12 DSCPs for 4 traffic classes.

Regards,

Ruediger



-----Original Message-----
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com
Sent: Friday, August 14, 2009 3:06 PM
To: lars.eggert@nokia.com; pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went = on
a back-burner for a few days.

The original intention of having registration was to avoid confusion
during any early experimental adoption of PCN however that could be = done
purely unofficially by having a list of DSCPs on the IETF wiki and = just
politely asking developers to consult it and add any new ones they = are
using. But there will need in future to be a process to formally
register certain standards (pool 1) DSCPs as PCN-compatible since = this
effectively replaces ECN as the default  behaviour for such DSCPs. = So my
suggestion is:

Change the IANA section to say something along the following lines = (I
will get IANA assistance with crafting exact text):

"IANA will be asked to set up a registry of PCN-compatible = Diffserv
codepoints. The decision as to whether to enable PCN for a given pool = 1
codepoint must be made by the appropriate IETF Transport Area = Working
Group (TSVWG?) which will then request IANA to add this to the
registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN = to
has to be made by TSVWG and is separate to this document which just
defines the process and the encoding.

Change the last sentence of A.1 to "IANA will maintain a list = of
PCN-compatible Diffserv Codepoints."

Would this cover things appropriately? I did wonder about asking IANA = to
maintain the experimental registry but I am not sure if they are able = to
do that sort of thing? If so the following could be added to the = IANA
section:

"During the early stages of adoption it is envisaged that PCN will = be
used experimentally using pool 2 or 3 DSCPs (experimental or local = use).
Whilst these DSCPs are not controlled by IANA normally, a request = will
be made to maintain a list of PCN experiments along with the DSCPs = these
experiments are using."

Once I get the nod from WG I will release a new version of the I-D = with
these updates...

Toby

> -----Original Message-----
> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To: pcn@ietf.org
> Subject: Re: [PCN] AD review: = draft-ietf-pcn-baseline-encoding-04
>
> Hi,
>
> I'm waiting to hear from the authors/WG.
>
> Lars
>
> On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
>
> > Hi,
> >
> > this document is ready, except for one issue:
> >
> > Section 7., paragraph 1:
> >>   This document makes no direct request to = IANA.  However this
> > document
> >>   allows for a set of Diffserv Codepoints to be assigned different
> > ECN
> >>   semantics within a controlled domain as = described in [RFC4774].
A
> >>   list of such DSCPs will be maintained by the = PCN working group.
> >
> >   DISCUSS: This text isn't aligned with appendix = A.1. The text here
> > says
> >   "the WG will maintain a list of DSCPs that = are OK", while the
> >   beginning of appendix A.1 says "the WG = decided to not define with
> >   which DSCPs PCN can be used" (but then the = end of A.1 talks about
> >   maintaining a list again.) Which is it? If there = is to be a list,
> > you
> >   need to create an IANA registry, write management procedures for
it
> >   (see RFC5226) and populate it with some initial = values. (WGs are
> >   ephemeral, which is why the PCN WG can't be the = maintainer of this
> >   list, IANA has to be.) If you want to leave it = fully open for
> >   deployments, you need to remove this confusion = from the text.
> >
> > Lars
> >
> >
> > Nits:
> >
> > Section 4., paragraph 3:
> >>           = ;       to prevent future compatability issues.
> >
> >   Nit: s/compatability/compatibility/
> >
> >
> > Section 4.2., paragraph 1:
> >>   that is guaranteeed to be copied down into the = inner header upon
> >
> >   Nit: s/guaranteeed/guaranteed/
> >
> >
> > Section 6., paragraph 1:
> >>   always copy the CE codepoint from teh outer = header into the inner
> >
> >   Nit: s/teh/the/
> >
> >
> > Section 6., paragraph 2:
> >>   header in decapsulation (unless the inner = packet is not-ECT).
> > If an
> >>   operator it is essential that any operator = wishing to allow ECN
to
> >>   exist end-to-end ensures there are no tunnel end-points within
the
> >>   PCN-domain.
> >
> >   "If an operator it is essential that any operator..." - wording
> >
> >
> > Section 12., paragraph 0:
> >> 12.  References
> >
> >   Should be updated; see idnits report.
> >
> >
> > Appendix A., paragraph 2:
> >>   a given PCN-domain is dependant on the nature = of the traffic
> > entering
> >
> >   Nit: s/dependant/dependent/
> >
> > <smime.p7s><ATT00001.txt>

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn

------_=_NextPart_001_01CA20D0.D745706B-- From Ruediger.Geib@telekom.de Wed Aug 19 06:56:18 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2877E3A6AFB for ; Wed, 19 Aug 2009 06:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 Ygdm3qaOfXtd for ; Wed, 19 Aug 2009 06:56:03 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 53CE428C19E for ; Wed, 19 Aug 2009 06:56:01 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 19 Aug 2009 15:55:58 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 15:55:58 +0200 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_01CA20D4.C73B4268" Date: Wed, 19 Aug 2009 15:55:57 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501E99165@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: Acogy8FdcdcongXRQFy1iBZvE2AFegABIaTAAAB7l9A= References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <200908191251.n7JCpHG7021784@bagheera.jungle.bt.co.uk> From: To: X-OriginalArrivalTime: 19 Aug 2009 13:55:58.0520 (UTC) FILETIME=[C7788380:01CA20D4] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 13:56:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA20D4.C73B4268 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Toby, =20 my mail referred to MPLS TCs, DSCP bits 0-2. Which is to say, I included = EF and AF2-4. AF may be limited to the AFn1 classes. If that creates to = much controversy, PCN may express something like AF classes are for = further study (so that they don't seem to be excluded). =20 By the way, I'm interested in learning more about best current provider = practice, especially on CS/AF classes 1-4 and their treatment in the = backbone.=20 - whether three colour marking is applied at all - whether separate drop levels are offered as a service supported by an = IP backbone (or limited to edges only), and if separate drop levels, how = many. - or whether only DSCP bits 0-2 are evaluated for backbone transport = (let's call them precedence bits) - further options Carrier representatives interested may contact me privately. I'd like to = learn whether there's sense and interest in an interconnection cookbook = (an informational document written by provider representatives). =20 Regards, =20 Ruediger _____ =20 From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com]=20 Sent: Wednesday, August 19, 2009 3:28 PM To: rbriscoe@jungle.bt.co.uk; Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Leaving aside ASCII art. =20 >From Ruediger's list below and Fred's draft the following seems like a = possible list of DSCPs that might reasonably employ PCN marking: =20 CS2, CS3, CS4, CS5, AF4. =20 Phil in an earlier email suggested EF as well. =20 Does that seem like a sensible list? Should we actually play it safe and = reduce it slightly? =20 Toby =20 =20 From: Briscoe,RJ,Bob,XVR9 BRISCORJ R=20 Sent: 19 August 2009 13:51 To: Moncaster,T,Toby,DER3 R; Ruediger.Geib@telekom.de Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 =20 Toby, At 09:39 19/08/2009, toby.moncaster@bt.com wrote: That ASCII art is still unreadable because (for me at least) it is = getting displayed in a variable-width font (Times New Roman to be = exact). I ended up having to convert it to Courier to be able to see = what you meant... The Tao of email says that's your problem. I sent it as plain text (and = even if I didn't it would have been Courier New (fixed)).=20 I am in the process of drafting a reply setting out the background to = this confusion and hopefully solving it. In the meantime there seems to = be a consensus that the way ahead is to recommend PCN as suitable for 1 = or more EXISTING DSCPs (which means we need to decide which ones...). = But that still leaves the question of whether we need to say something = about what needs to happen in the future if someone (say Fred Baker) = wants to add PCN to a new DSCP. Ruediger has suggested some. Can you check them off against those that = Fred discusses in voice-admit. That should give a decent list. Bob Toby =20 From: Briscoe,RJ,Bob,XVR9 BRISCORJ R=20 Sent: 19 August 2009 09:29 To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 =20 Ruediger, Great. [As some people couldn't read it, I've also replaced the diag quoted in = the thread below with narrower ASCII-art to better survive word wrap] Cheers Bob At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: Hi Bob, =20 I agree to your suggestion to "scrub (ii) and only have (i)..[and that] = we should list classes that might be appropriate to associate with PCN = marking." =20 Regards, =20 Ruediger _____ =20 From: Bob Briscoe [ = mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: Tuesday, August 18, 2009 7:37 PM To: Geib, R=FCdiger; toby.moncaster@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Ruediger, The draft as it stands holds two inconsistent opinions: i) " the aim is for PCN to re-use existing DSCPs " (S.4.3.1) ii) the second half of Appx A.1, repeated below. Similarly, your posting, talks about: i) applying PCN to existing DSCPs ii) reserving DSCPs for PCN. I believe we should scrub (ii) and only have (i). In place of ii) we = should list the classes that might be appropriate to associate with PCN = marking. In other words, we should only say that an operator _applies_ PCN = marking to certain existing DSCPs. No-one needs any additional DSCPs to enable PCN marking. Otherwise that = would waste DSCPs just to get a different marking behaviour for packets = requiring the same scheduling behaviour as a pre-existing DSCP. The = non-wasteful way to do this is to use one DSCP for a certain scheduling = behaviour, but set the ECN field to a non-zero value to turn on PCN = marking (S.4.3.1). [In MPLS, as there is no ECN field, the efficient way is different. Then = RFC5129 describes how you would do it.] To be absolutely sure it's clear what I mean, here's an example: hi stat mux subnet ___________________ | same | | marking | | _____ ____:___ | | | || || --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- | | || || --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- | | ||________|| | | | = |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- | |_____| | | _____ | | | | | --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ | | | | --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- | |_____| | | : | | same | | scheduling | | (BA) | |___________________| - The text on each flow shows the DSCP-ECN combination used for that = segment - The boxes around DSCPA/B/C and around DSCPD/E represent the same = scheduling behaviour applied to multiple DSCPs in the aggregated region = (a behaviour aggregate). - The box around NM for the first two flows represents the same marking = behaviour (PCN) applied to multiple DSCPs. - The flows keep the same DSCP* along their whole path, so when they pop = out into the lo-stat-mux region on the other side, the DSCP is = preserved. - In practice, traffic might be tunnelled across the hi-stat mux region, = and at the same time common scheduling behaviours might be mapped to a = single DSCP in the outer headers. The diagram merely shows everything = can be done without tunnelling or layering. * Note: For some non-standardised DSCPs, the DSCP might not actually = stay the same along the whole path. It might be mapped to local DSCPs = that are each used for the same class at different points along the = path. Here's a copy of the 2nd half of Appx A.1, that I think needs to be =20 removed (sorry, I know I'm a co-author, but...): =20 " The choice of which DSCP is most suitable for =20 a given PCN-domain is dependant on the nature of the =20 traffic =20 entering =20 that domain and the link rates of all the links making up =20 that =20 domain. In PCN-domains with uniformly high link =20 rates, =20 the =20 appropriate DSCPs would currently be those for the Real =20 Time =20 Traffic =20 Class =20 [RFC5127 ]. If the =20 PCN domain includes lower speed links it =20 would also be appropriate to use the DSCPs of the other =20 traffic =20 classes that =20 =20 = =20 [ = =20 =20 =20 = =20 Voice-Admit = ] defines for use with admission control, =20 such as the three video classes CS4, CS3 and AF4 and the =20 Admitted =20 Telephony Class. The PCN working group will maintain =20 a =20 list of PCN- =20 compatible Diffserv Codepoints. " At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: Toby, PCN should express to the IANA, whether one or more new DSCP is=20 required to operate or carry out experiments on PCN. As soon as IANA maintains a list of DSCPs for any purpose, this=20 will have the status of a standard.=20 "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs=20 per traffic class (DSCP bit 0-2, let's call them traffic class=20 in this email) for PCN, that's 32 DSCPs in all. If possible, PCN should limit the number of traffic classes,=20 where to apply PCN. I don't think PCN will be applied in traffic classes 0 and 6. I'd expect PCN to be used within traffic classes 5 and 4,=20 may be also 3 or 2. Traffic classes 1 and 7 may be excluded too. The above clearly expresses personal views, but informational=20 RFC5127 to some extent backs these personal views. I'm aware that PCN WG shouldn't standardise traffic class usage=20 or come close to that. I however want to avoid repeating the biggest=20 flaw of the AF specification, which in my eyes is to reserve=20 12 DSCPs for 4 traffic classes. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com Sent: Friday, August 14, 2009 3:06 PM To: lars.eggert@nokia.com; pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Hi Lars, Sorry not to get back to you earlier - been busy at work so this went on a back-burner for a few days.=20 The original intention of having registration was to avoid confusion during any early experimental adoption of PCN however that could be done purely unofficially by having a list of DSCPs on the IETF wiki and just politely asking developers to consult it and add any new ones they are using. But there will need in future to be a process to formally register certain standards (pool 1) DSCPs as PCN-compatible since this effectively replaces ECN as the default behaviour for such DSCPs. So my suggestion is: Change the IANA section to say something along the following lines (I will get IANA assistance with crafting exact text): "IANA will be asked to set up a registry of PCN-compatible Diffserv codepoints. The decision as to whether to enable PCN for a given pool 1 codepoint must be made by the appropriate IETF Transport Area Working Group (TSVWG?) which will then request IANA to add this to the registry." Clarify at start of A.1 that the decision of which DSCPs to apply PCN to has to be made by TSVWG and is separate to this document which just defines the process and the encoding. Change the last sentence of A.1 to "IANA will maintain a list of PCN-compatible Diffserv Codepoints." Would this cover things appropriately? I did wonder about asking IANA to maintain the experimental registry but I am not sure if they are able to do that sort of thing? If so the following could be added to the IANA section: "During the early stages of adoption it is envisaged that PCN will be used experimentally using pool 2 or 3 DSCPs (experimental or local use). Whilst these DSCPs are not controlled by IANA normally, a request will be made to maintain a list of PCN experiments along with the DSCPs these experiments are using." Once I get the nod from WG I will release a new version of the I-D with these updates... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 14 August 2009 12:27 > To: pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm waiting to hear from the authors/WG. >=20 > Lars >=20 > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, > > > > this document is ready, except for one issue: > > > > Section 7., paragraph 1: > >> This document makes no direct request to IANA. However this > > document > >> allows for a set of Diffserv Codepoints to be assigned different > > ECN > >> semantics within a controlled domain as described in [RFC4774]. A > >> list of such DSCPs will be maintained by the PCN working group. > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > says > > "the WG will maintain a list of DSCPs that are OK", while the > > beginning of appendix A.1 says "the WG decided to not define with > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > maintaining a list again.) Which is it? If there is to be a list, > > you > > need to create an IANA registry, write management procedures for it > > (see RFC5226) and populate it with some initial values. (WGs are > > ephemeral, which is why the PCN WG can't be the maintainer of this > > list, IANA has to be.) If you want to leave it fully open for > > deployments, you need to remove this confusion from the text. > > > > Lars > > > > > > Nits: > > > > Section 4., paragraph 3: > >> to prevent future compatability issues. > > > > Nit: s/compatability/compatibility/ > > > > > > Section 4.2., paragraph 1: > >> that is guaranteeed to be copied down into the inner header upon > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > Section 6., paragraph 1: > >> always copy the CE codepoint from teh outer header into the inner > > > > Nit: s/teh/the/ > > > > > > Section 6., paragraph 2: > >> header in decapsulation (unless the inner packet is not-ECT). > > If an > >> operator it is essential that any operator wishing to allow ECN to > >> exist end-to-end ensures there are no tunnel end-points within the > >> PCN-domain. > > > > "If an operator it is essential that any operator..." - wording > > > > > > Section 12., paragraph 0: > >> 12. References > > > > Should be updated; see idnits report. > > > > > > Appendix A., paragraph 2: > >> a given PCN-domain is dependant on the nature of the traffic > > entering > > > > Nit: s/dependant/dependent/ > > > > _______________________________________________ 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 ------_=_NextPart_001_01CA20D4.C73B4268 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Toby,
 
my mail referred to MPLS TCs, DSCP bits 0-2. = Which is to=20 say, I included EF and AF2-4. AF may be limited to the AFn1 classes. If = that=20 creates to much controversy, PCN may express something like AF classes = are for=20 further study (so that they don't seem to be = excluded).
 
By the way, I'm interested in learning more = about best=20 current provider practice, especially on CS/AF classes 1-4 and = their=20 treatment in the backbone.
- whether three colour marking is applied at=20 all
- whether separate drop levels are offered as a = service=20 supported by an IP backbone (or limited to edges only), and if separate = drop=20 levels, how many.
- or whether only DSCP bits 0-2 are evaluated = for backbone=20 transport (let's call them precedence bits)
- further options
Carrier=20 representatives interested may contact me privately. I'd like to = learn=20 whether there's sense and interest in an interconnection cookbook = (an=20 informational document written by provider=20 representatives).
 
Regards,
 
Ruediger

From: toby.moncaster@bt.com=20 [mailto:toby.moncaster@bt.com]
Sent: Wednesday, August 19, = 2009 3:28=20 PM
To: rbriscoe@jungle.bt.co.uk; Geib, R=FCdiger
Cc: = pcn@ietf.org
Subject: RE: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04

Leaving aside = ASCII=20 art.

 

From = Ruediger’s list=20 below and Fred’s draft the following seems like a possible list of = DSCPs that=20 might reasonably employ PCN marking:

 

CS2, CS3, CS4, = CS5,=20 AF4.

 

Phil in an = earlier email=20 suggested EF as well.

 

Does that seem = like a=20 sensible list? Should we actually play it safe and reduce it=20 slightly?

 

Toby

 

 

From:=20 Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009=20 13:51
To: Moncaster,T,Toby,DER3 R;=20 Ruediger.Geib@telekom.de
Cc: pcn@ietf.org
Subject: = RE: [PCN]=20 AD review: = draft-ietf-pcn-baseline-encoding-04

 

Toby,

At 09:39 19/08/2009, = toby.moncaster@bt.com=20 wrote:

That ASCII art is still unreadable because (for me = at least)=20 it is getting displayed in a variable-width font (Times New Roman to be = exact).=20 I ended up having to convert it to Courier to be able to see what you=20 meant…


The Tao of email says that's your problem. I = sent it as=20 plain text (and even if I didn't it would have been Courier New = (fixed)).=20



I am in the process of drafting a reply setting = out the=20 background to this confusion and hopefully solving it. In the meantime = there=20 seems to be a consensus that the way ahead is to recommend PCN as = suitable for 1=20 or more EXISTING DSCPs (which means we need to decide which = ones…). But that=20 still leaves the question of whether we need to say something about what = needs=20 to happen in the future if someone (say Fred Baker) wants to add PCN to = a new=20 DSCP.


Ruediger has suggested some. Can you check them = off=20 against those that Fred discusses in voice-admit. That should give a = decent=20 list.


Bob



Toby
 
From: = Briscoe,RJ,Bob,XVR9=20 BRISCORJ R
Sent: 19 August 2009 09:29
To:=20 Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04
 
Ruediger,

Great.<= BR>
[As=20 some people couldn't read it, I've also replaced the diag quoted in the = thread=20 below with narrower ASCII-art to better survive word=20 wrap]

Cheers


Bob

At 07:27 19/08/2009,=20 Ruediger.Geib@telekom.de wrote:

Hi Bob,
 
I agree to = your=20 suggestion to "scrub (ii) and only have (i)..[and that] we should list = classes=20 that might be appropriate to associate with PCN=20 marking."
 
Regards,
 
Ruediger

From: Bob = Briscoe [ mailto:rbriscoe@jungle.bt.co.uk<= /A>]=20
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, = R=FCdiger;=20 toby.moncaster@bt.com
Cc: pcn@ietf.org
Subject: Re: = [PCN] AD=20 review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

The = draft as=20 it stands holds two inconsistent opinions:
i) = "

the aim is for PCN to re-use existing =
DSCPs



" = (S.4.3.1)
ii) the=20 second half of Appx A.1, repeated below.

Similarly, your posting, = talks=20 about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for=20 PCN.

I believe we should scrub (ii) and only have (i). In place = of ii) we=20 should list the classes that might be appropriate to associate with PCN=20 marking.

In other words, we should only say that an operator = _applies_=20 PCN marking to certain existing DSCPs.

No-one needs any = additional DSCPs=20 to enable PCN marking. Otherwise that would waste DSCPs just to get a = different=20 marking behaviour for packets requiring the same scheduling behaviour as = a=20 pre-existing DSCP. The non-wasteful way to do this is to use one DSCP = for a=20 certain scheduling behaviour, but set the ECN field to a non-zero value = to turn=20 on PCN marking (S.4.3.1).

[In MPLS, as there is no ECN field, the = efficient way is different. Then RFC5129 describes how you would do=20 it.]

To be absolutely sure it's clear what I mean, here's an=20 example:

         &nb= sp;        =20 hi stat mux=20 subnet
          &nb= sp;       =20 ___________________
        &n= bsp;        =20 |           =20 same  =20 |
           &n= bsp;     =20 |           marking=20 |
           &n= bsp;     =20 |   _____  ____:___=20 |
           &n= bsp;     =20 |  |     = ||       =20 ||
--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
 =             &= nbsp;   =20 |  |     = ||       =20 ||
--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
 =             &= nbsp;   =20 |  |    =20 ||________||
         &nb= sp;       =20 |  |    =20 |         =20 |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
  = ;            =    =20 |  |_____|         =20 |
           &n= bsp;     =20 |   = _____          =20 |
           &n= bsp;     =20 |  |    =20 |         =20 |
--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
 &= nbsp;           &n= bsp;   =20 |  |    =20 |         =20 |
--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
 &= nbsp;           &n= bsp;   =20 |  |_____|         =20 |
           &n= bsp;     =20 |    =20 :            = =20 |
           &n= bsp;     =20 |  =20 same           =20 |
           &n= bsp;     =20 | scheduling       =20 |
           &n= bsp;     =20 |  =20 (BA)           =20 |
           &n= bsp;     =20 |___________________|


- The text on each flow shows the = DSCP-ECN=20 combination used for that segment
- The boxes around DSCPA/B/C and = around=20 DSCPD/E represent the same scheduling behaviour applied to multiple = DSCPs in the=20 aggregated region (a behaviour aggregate).
- The box around NM for = the first=20 two flows represents the same marking behaviour (PCN) applied to = multiple=20 DSCPs.
- The flows keep the same DSCP* along their whole path, so = when they=20 pop out into the lo-stat-mux region on the other side, the DSCP is=20 preserved.
- In practice, traffic might be tunnelled across the = hi-stat mux=20 region, and at the same time common scheduling behaviours might be = mapped to a=20 single DSCP in the outer headers. The diagram merely shows everything = can be=20 done without tunnelling or layering.

* Note: For some = non-standardised=20 DSCPs, the DSCP might not actually stay the same along the whole path. = It might=20 be mapped to local DSCPs that are each used for the same class at = different=20 points along the path.


Here's a copy of =
the 2nd half of Appx A.1, that I think needs =
to
be

 

removed (sorry, I know I'm a co-author, =
but...):

 

"  The choice of which DSCP is most =
suitable
for

 

   a given PCN-domain is =
dependant on the nature of
the

 

traffic

 

entering

 

   that domain and the link =
rates of all the links making
up

 

that

 

   domain.  In =
PCN-domains with uniformly =
high
link

 

rates,

 

the

 

   appropriate DSCPs would =
currently be those for the
Real

 

Time

 

Traffic

 

   Class

 

[RFC5127].  =
If
the

 

PCN domain includes lower speed links =
it

 

   would also be appropriate =
to use the DSCPs of the
other

 

traffic

 

   classes =
that

 

 
[

 

 
Voice-Admit] defines for use with admission =
control,

 

   such as the three video =
classes CS4, CS3 and AF4 and
the

 

Admitted

 

   Telephony Class.  The =
PCN working group will
maintain

 

a

 

list of PCN-

 

   compatible Diffserv =
Codepoints.



"

At 08:55 18/08/2009,=20 Ruediger.Geib@telekom.de wrote:
Toby,

PCN should express to = the IANA,=20 whether one or more new DSCP is
required to operate or carry out = experiments=20 on PCN.

As soon as IANA maintains a list of DSCPs for any = purpose, this=20
will have the status of a standard.

"Using pool 2 or 3 = DSCPs" to me=20 sounds like reserving 4 DSCPs
per traffic class (DSCP bit 0-2, let's = call=20 them traffic class
in this email) for PCN, that's 32 DSCPs in = all.

If=20 possible, PCN should limit the number of traffic classes,
where to = apply=20 PCN.

I don't think PCN will be applied in traffic classes 0 and=20 6.

I'd expect PCN to be used within traffic classes 5 and 4, =
may be=20 also 3 or 2.
Traffic classes 1 and 7 may be excluded too.

The = above=20 clearly expresses personal views, but informational
RFC5127 to some = extent=20 backs these personal views.

I'm aware that PCN WG shouldn't = standardise=20 traffic class usage
or come close to that. I however want to avoid = repeating=20 the biggest
flaw of the AF specification, which in my eyes is to = reserve=20
12 DSCPs for 4 traffic=20 classes.

Regards,

Ruediger



-----Original=20 Message-----
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On = Behalf Of=20 toby.moncaster@bt.com
Sent: Friday, August 14, 2009 3:06 PM
To:=20 lars.eggert@nokia.com; pcn@ietf.org
Subject: Re: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not to = get back=20 to you earlier - been busy at work so this went on
a back-burner for = a few=20 days.

The original intention of having registration was to avoid = confusion
during any early experimental adoption of PCN however that = could be=20 done
purely unofficially by having a list of DSCPs on the IETF wiki = and=20 just
politely asking developers to consult it and add any new ones = they=20 are
using. But there will need in future to be a process to=20 formally
register certain standards (pool 1) DSCPs as PCN-compatible = since=20 this
effectively replaces ECN as the default  behaviour for such = DSCPs.=20 So my
suggestion is:

Change the IANA section to say something = along=20 the following lines (I
will get IANA assistance with crafting exact=20 text):

"IANA will be asked to set up a registry of PCN-compatible = Diffserv
codepoints. The decision as to whether to enable PCN for a = given=20 pool 1
codepoint must be made by the appropriate IETF Transport Area=20 Working
Group (TSVWG?) which will then request IANA to add this to=20 the
registry."

Clarify at start of A.1 that the decision of = which=20 DSCPs to apply PCN to
has to be made by TSVWG and is separate to this = document which just
defines the process and the = encoding.

Change the=20 last sentence of A.1 to "IANA will maintain a list of
PCN-compatible = Diffserv=20 Codepoints."

Would this cover things appropriately? I did wonder = about=20 asking IANA to
maintain the experimental registry but I am not sure = if they=20 are able to
do that sort of thing? If so the following could be added = to the=20 IANA
section:

"During the early stages of adoption it is = envisaged=20 that PCN will be
used experimentally using pool 2 or 3 DSCPs = (experimental or=20 local use).
Whilst these DSCPs are not controlled by IANA normally, a = request=20 will
be made to maintain a list of PCN experiments along with the = DSCPs=20 these
experiments are using."

Once I get the nod from WG I = will=20 release a new version of the I-D with
these=20 updates...

Toby

> -----Original Message-----
> = From:=20 pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On = Behalf=20 Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To:=20 pcn@ietf.org
> Subject: Re: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04
>
> Hi,
> =
> I'm=20 waiting to hear from the authors/WG.
>
> Lars
> =
> On=20 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
> =
> >=20 Hi,
> >
> > this document is ready, except for one=20 issue:
> >
> > Section 7., paragraph 1:
>=20 >>   This document makes no direct request to = IANA. =20 However this
> > document
> >>   allows = for a set=20 of Diffserv Codepoints to be assigned different
> > ECN
> = >>   semantics within a controlled domain as described = in=20 [RFC4774].
A
> >>   list of such DSCPs will be=20 maintained by the PCN working group.
> >
> = >  =20 DISCUSS: This text isn't aligned with appendix A.1. The text = here
> >=20 says
> >   "the WG will maintain a list of DSCPs that = are=20 OK", while the
> >   beginning of appendix A.1 says = "the WG=20 decided to not define with
> >   which DSCPs PCN can = be used"=20 (but then the end of A.1 talks about
> >   = maintaining a list=20 again.) Which is it? If there is to be a list,
> > you
>=20 >   need to create an IANA registry, write management = procedures=20 for
it
> >   (see RFC5226) and populate it with = some=20 initial values. (WGs are
> >   ephemeral, which is = why the=20 PCN WG can't be the maintainer of this
> >   list, = IANA has=20 to be.) If you want to leave it fully open for
> >  =20 deployments, you need to remove this confusion from the text.
>=20 >
> > Lars
> >
> >
> > = Nits:
>=20 >
> > Section 4., paragraph 3:
>=20 >>           = ;      =20 to prevent future compatability issues.
> >
> = >  =20 Nit: s/compatability/compatibility/
> >
> >
> = >=20 Section 4.2., paragraph 1:
> >>   that is = guaranteeed to=20 be copied down into the inner header upon
> >
> = >  =20 Nit: s/guaranteeed/guaranteed/
> >
> >
> > = Section=20 6., paragraph 1:
> >>   always copy the CE = codepoint from=20 teh outer header into the inner
> >
> >   = Nit:=20 s/teh/the/
> >
> >
> > Section 6., paragraph=20 2:
> >>   header in decapsulation (unless the = inner packet=20 is not-ECT).
> > If an
> >>   operator it = is=20 essential that any operator wishing to allow ECN
to
>=20 >>   exist end-to-end ensures there are no tunnel = end-points=20 within
the
> >>   PCN-domain.
> = >
>=20 >   "If an operator it is essential that any operator..." - = wording
> >
> >
> > Section 12., paragraph = 0:
>=20 >> 12.  References
> >
> >   = Should be=20 updated; see idnits report.
> >
> >
> > = Appendix A.,=20 paragraph 2:
> >>   a given PCN-domain is = dependant on the=20 nature of the traffic
> > entering
> >
>=20 >   Nit: s/dependant/dependent/
> >
> >=20 <smime.p7s><ATT00001.txt>

____________________________= ___________________
PCN=20 mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn
______________________________________________= _
PCN=20 mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn

------_=_NextPart_001_01CA20D4.C73B4268-- From rbriscoe@jungle.bt.co.uk Wed Aug 19 08:55: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 1C9E63A6B1E for ; Wed, 19 Aug 2009 08:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.126 X-Spam-Level: X-Spam-Status: No, score=0.126 tagged_above=-999 required=5 tests=[AWL=-1.811, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, 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 Qi2-+W3Tbyql for ; Wed, 19 Aug 2009 08:55:41 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E5D243A6ADA for ; Wed, 19 Aug 2009 08:55:40 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 16:55:45 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 16:55:44 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1250697343582; Wed, 19 Aug 2009 16:55:43 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7JFtegc025672; Wed, 19 Aug 2009 16:55:40 +0100 Message-Id: <200908191555.n7JFtegc025672@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Aug 2009 16:55:36 +0100 To: , From: Bob Briscoe In-Reply-To: References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <200908191251.n7JCpHG7021784@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Aug 2009 15:55:44.0808 (UTC) FILETIME=[82D50A80:01CA20E5] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 15:55:49 -0000 Toby,

At 14:27 19/08/2009, toby.moncaster@bt.com wrote:
Leaving aside ASCII art.
 
From Ruediger=92s list below and Fred=92s draft the following seems like a possible list of DSCPs that might reasonably employ PCN marking:
 
CS2, CS3, CS4, CS5, AF4.

From your list, I strongly suggest you don't include:
CS2     Ops, Admin & Mgmt (not predictably streamed enough for AC)
CS5     Call signalling (ditto)

In addition AF3 /might/ be admission controlled.

Suggested text to replace the end of Appx A.1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
It is recommended to use admission control for the following service classes listed with their recommended PHBs [I-D.ietf-tsvwg-admitted-realtime-dscp][RFC4594]:
- Telephony (*)
- Real-time interactive (CS4)
- Broadcast Video (CS3)
- Multimedia Conferencing (AF4)

*Note: The PHB of the the telephony service class is currently EF, but [I-D.ietf-tsvwg-admitted-realtime-dscp] proposes a new PHB called VOICE-ADMIT. It has identical scheduling behaviour to EF, but it is for use with admission control mechanisms in the network, rather than at the application layer. If this draft progresses on the standards track, VOICE-ADMIT rather than EF would become the appropriate Telephony PHB to which PCN marking would be applied.

PCN marking is intended to provide a scalable admission control mechanism for traffic with a high degree of statistical multiplexing. PCN marking would therefore be appropriate to apply to traffic in the above classes, but only  within a PCN region containing highly aggregated traffic.

In such cases, the above service classes may well all be subject to a single forwarding treatment (a treatment aggregate [RFC5127]). However, this does not imply all such IP traffic would necessarily be identified by one DSCP - each service class might keep a distinct DSCP within the highly aggregated region [RFC5127].

Additional service classes may be defined for which admission control is appropriate, whether through some future standards action or through local use by certain operators, e.g. the Multimedia Streaming service class (AF3). This document does not preclude the use of PCN in more cases than those listed above.

The above discussion is informative not normative, as operators are ultimately free to decide whether to use admission control for certain service classes and whether to use PCN as their mechanism of choice.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Bob



 
Phil in an earlier email suggested EF as well.
 
Does that seem like a sensible list? Should we actually play it safe and reduce it slightly?
 
Toby
 
 
From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009 13:51
To: Moncaster,T,Toby,DER3 R; Ruediger.Geib@telekom.de
Cc: pcn@ietf.org
Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
 
Toby,

At 09:39 19/08/2009, toby.moncaster@bt.com wrote:

That ASCII art is still unreadable because (for me at least) it is getting displayed in a variable-width font (Times New Roman to be exact). I ended up having to convert it to Courier to be able to see what you meant=85

The Tao of email says that's your problem. I sent it as plain text (and even if I didn't it would have been Courier New (fixed)).


 
I am in the process of drafting a reply setting out the background to this confusion and hopefully solving it. In the meantime there seems to be a consensus that the way ahead is to recommend PCN as suitable for 1 or more EXISTING DSCPs (which means we need to decide which ones=85). But that still leaves the question of whether we need to say something about what needs to happen in the future if someone (say Fred Baker) wants to add PCN to a new DSCP.

Ruediger has suggested some. Can you check them off against those that Fred discusses in voice-admit. That should give a decent list.


Bob


 
Toby
 
From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009 09:29
To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R
Cc: pcn@ietf.org
Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
 
Ruediger,

Great.

[As some people couldn't read it, I've also replaced the diag quoted in the thread below with narrower ASCII-art to better survive word wrap]

Cheers


Bob

At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote:

Hi Bob,
 
I agree to your suggestion to "scrub (ii) and only have (i)..[and that] we should list classes that might be appropriate to associate with PCN marking."
 
Regards,
 
Ruediger
From: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, R=FCdiger; toby.moncaster@bt.com
Cc: pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Ruediger,

The draft as it stands holds two inconsistent opinions:
i) "

the aim is for PCN to re-use existing DSCPs



" (S.4.3.1)
ii) the second half of Appx A.1, repeated below.

Similarly, your posting, talks about:
i) applying PCN to existing DSCPs
ii) reserving DSCPs for PCN.

I believe we should scrub (ii) and only have (i). In place of ii) we should list the classes that might be appropriate to associate with PCN marking.

In other words, we should only say that an operator _applies_ PCN marking to certain existing DSCPs.

No-one needs any additional DSCPs to enable PCN marking. Otherwise that would waste DSCPs just to get a different marking behaviour for packets requiring the same scheduling behaviour as a pre-existing DSCP. The non-wasteful way to do this is to use one DSCP for a certain scheduling behaviour, but set the ECN field to a non-zero value to turn on PCN marking (S.4.3.1).
[In MPLS, as there is no ECN field, the efficient way is different. Then RFC5129 describes how you would do it.]

To be absolutely sure it's clear what I mean, here's an example:

            &nbs= p;      hi stat mux subnet
            &nbs= p;      ___________________
            &nbs= p;     |            same   |
            &nbs= p;     |           marking |
            &nbs= p;     |   _____  ____:___ |
            &nbs= p;     |  |     ||        ||
--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
            &nbs= p;     |  |     ||        ||
--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
            &nbs= p;     |  |     ||________||
            &nbs= p;     |  |     |          |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
            &nbs= p;     |  |_____|          |
            &nbs= p;     |   _____           |
            &nbs= p;     |  |     |          |
--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
            &nbs= p;     |  |     |          |
--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
            &nbs= p;     |  |_____|          |
            &nbs= p;     |     :             |
            &nbs= p;     |   same            |
            &nbs= p;     | scheduling        |
            &nbs= p;     |   (BA)            |
            &nbs= p;     |___________________|


- The text on each flow shows the DSCP-ECN combination used for that segment
- The boxes around DSCPA/B/C and around DSCPD/E represent the same scheduling behaviour applied to multiple DSCPs in the aggregated region (a behaviour aggregate).
- The box around NM for the first two flows represents the same marking behaviour (PCN) applied to multiple DSCPs.
- The flows keep the same DSCP* along their whole path, so when they pop out into the lo-stat-mux region on the other side, the DSCP is preserved.
- In practice, traffic might be tunnelled across the hi-stat mux region, and at the same time common scheduling behaviours might be mapped to a single DSCP in the outer headers. The diagram merely shows everything can be done without tunnelling or layering.

* Note: For some non-standardised DSCPs, the DSCP might not actually stay the same along the whole path. It might be mapped to local DSCPs that are each used for the same class at different points along the path.



Here's a copy of the 2nd half of Appx A.1, that I think needs
to


be

 

removed (sorry, I know I'm a co-author, but...):

 

"  The choice of which DSCP is most
suitable


for

 

   a given PCN-domain is dependant on the nature
of


the

 

traffic

 

entering

 

   that domain and the link rates of all the links
making


up

 

that

 

   domain.  In PCN-domains with uniformly
high


link

 

rates,

 

the

 

   appropriate DSCPs would currently be those for
the


Real

 

Time

 

Traffic

 

   Class

 

[RFC5127]. 
If


the

 

PCN domain includes lower speed links it

 

   would also be appropriate to use the DSCPs of
the


other

 

traffic

 

   classes that

 

 





[

 

 





Voice-Admit] defines for use with admission control,

 

   such as the three video classes CS4, CS3 and AF4
and


the

 

Admitted

 

   Telephony Class.  The PCN working group
will


maintain

 

a

 

list of PCN-

 

   compatible Diffserv Codepoints.



"

At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:
Toby,

PCN should express to the IANA, whether one or more new DSCP is
required to operate or carry out experiments on PCN.

As soon as IANA maintains a list of DSCPs for any purpose, this
will have the status of a standard.

"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs
per traffic class (DSCP bit 0-2, let's call them traffic class
in this email) for PCN, that's 32 DSCPs in all.

If possible, PCN should limit the number of traffic classes,
where to apply PCN.

I don't think PCN will be applied in traffic classes 0 and 6.

I'd expect PCN to be used within traffic classes 5 and 4,
may be also 3 or 2.
Traffic classes 1 and 7 may be excluded too.

The above clearly expresses personal views, but informational
RFC5127 to some extent backs these personal views.

I'm aware that PCN WG shouldn't standardise traffic class usage
or come close to that. I however want to avoid repeating the biggest
flaw of the AF specification, which in my eyes is to reserve
12 DSCPs for 4 traffic classes.

Regards,

Ruediger



-----Original Message-----
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com
Sent: Friday, August 14, 2009 3:06 PM
To: lars.eggert@nokia.com; pcn@ietf.org
Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not to get back to you earlier - been busy at work so this went on
a back-burner for a few days.

The original intention of having registration was to avoid confusion
during any early experimental adoption of PCN however that could be done
purely unofficially by having a list of DSCPs on the IETF wiki and just
politely asking developers to consult it and add any new ones they are
using. But there will need in future to be a process to formally
register certain standards (pool 1) DSCPs as PCN-compatible since this
effectively replaces ECN as the default  behaviour for such DSCPs. So my
suggestion is:

Change the IANA section to say something along the following lines (I
will get IANA assistance with crafting exact text):

"IANA will be asked to set up a registry of PCN-compatible Diffserv
codepoints. The decision as to whether to enable PCN for a given pool 1
codepoint must be made by the appropriate IETF Transport Area Working
Group (TSVWG?) which will then request IANA to add this to the
registry."

Clarify at start of A.1 that the decision of which DSCPs to apply PCN to
has to be made by TSVWG and is separate to this document which just
defines the process and the encoding.

Change the last sentence of A.1 to "IANA will maintain a list of
PCN-compatible Diffserv Codepoints."

Would this cover things appropriately? I did wonder about asking IANA to
maintain the experimental registry but I am not sure if they are able to
do that sort of thing? If so the following could be added to the IANA
section:

"During the early stages of adoption it is envisaged that PCN will be
used experimentally using pool 2 or 3 DSCPs (experimental or local use).
Whilst these DSCPs are not controlled by IANA normally, a request will
be made to maintain a list of PCN experiments along with the DSCPs these
experiments are using."

Once I get the nod from WG I will release a new version of the I-D with
these updates...

Toby

> -----Original Message-----
> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To: pcn@ietf.org
> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04
>
> Hi,
>
> I'm waiting to hear from the authors/WG.
>
> Lars
>
> On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
>
> > Hi,
> >
> > this document is ready, except for one issue:
> >
> > Section 7., paragraph 1:
> >>   This document makes no direct request to IANA.  However this
> > document
> >>   allows for a set of Diffserv Codepoints to be assigned different
> > ECN
> >>   semantics within a controlled domain as described in [RFC4774].
A
> >>   list of such DSCPs will be maintained by the PCN working group.
> >
> >   DISCUSS: This text isn't aligned with appendix A.1. The text here
> > says
> >   "the WG will maintain a list of DSCPs that are OK", while the
> >   beginning of appendix A.1 says "the WG decided to not define with
> >   which DSCPs PCN can be used" (but then the end of A.1 talks about
> >   maintaining a list again.) Which is it? If there is to be a list,
> > you
> >   need to create an IANA registry, write management procedures for
it
> >   (see RFC5226) and populate it with some initial values. (WGs are
> >   ephemeral, which is why the PCN WG can't be the maintainer of this
> >   list, IANA has to be.) If you want to leave it fully open for
> >   deployments, you need to remove this confusion from the text.
> >
> > Lars
> >
> >
> > Nits:
> >
> > Section 4., paragraph 3:
> >>           &n= bsp;      to prevent future compatability issues.
> >
> >   Nit: s/compatability/compatibility/
> >
> >
> > Section 4.2., paragraph 1:
> >>   that is guaranteeed to be copied down into the inner header upon
> >
> >   Nit: s/guaranteeed/guaranteed/
> >
> >
> > Section 6., paragraph 1:
> >>   always copy the CE codepoint from teh outer header into the inner
> >
> >   Nit: s/teh/the/
> >
> >
> > Section 6., paragraph 2:
> >>   header in decapsulation (unless the inner packet is not-ECT).
> > If an
> >>   operator it is essential that any operator wishing to allow ECN
to
> >>   exist end-to-end ensures there are no tunnel end-points within
the
> >>   PCN-domain.
> >
> >   "If an operator it is essential that any operator..." - wording
> >
> >
> > Section 12., paragraph 0:
> >> 12.  References
> >
> >   Should be updated; see idnits report.
> >
> >
> > Appendix A., paragraph 2:
> >>   a given PCN-domain is dependant on the nature of the traffic
> > entering
> >
> >   Nit: s/dependant/dependent/
> >
> > <smime.p7s><ATT00001.txt>

_______________________________________________
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 menth@informatik.uni-wuerzburg.de Wed Aug 19 09:44: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 514453A69FB for ; Wed, 19 Aug 2009 09:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q8y4h2OPxKI for ; Wed, 19 Aug 2009 09:44:52 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A32893A68E8 for ; Wed, 19 Aug 2009 09:44:51 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 96E09199536; Wed, 19 Aug 2009 18:44:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 89BCB199525; Wed, 19 Aug 2009 18:44:56 +0200 (CEST) Received: from [192.168.1.2] (e181183006.adsl.alicedsl.de [85.181.183.6]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1156EA0D00; Wed, 19 Aug 2009 18:44:56 +0200 (CEST) Message-ID: <4A8C2C05.5050609@informatik.uni-wuerzburg.de> Date: Wed, 19 Aug 2009 18:44:53 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Bob Briscoe References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <200908191251.n7JCpHG7021784@bagheera.jungle.bt.co.uk> <200908191555.n7JFtegc025672@bagheera.jungle.bt.co.uk> In-Reply-To: <200908191555.n7JFtegc025672@bagheera.jungle.bt.co.uk> 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] AD review: draft-ietf-pcn-baseline-encoding-04 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, 19 Aug 2009 16:44:54 -0000 Hi, PCN means admission control in practice. If we have non-PCN and PCN traffic in the same BA, that does not sound very reasonable from my perspective, because it just prevent PCN traffic hitting the QoS of non-PCN traffic but not vice-versa. But that was not the ideo of PCN, right? That could be another constraint for usable DSCPs. Regards, Michael Bob Briscoe schrieb: > Toby, > > At 14:27 19/08/2009, toby.moncaster@bt.com wrote: >> Leaving aside ASCII art. >> >> From Ruediger’s list below and Fred’s draft the following seems like >> a possible list of DSCPs that might reasonably employ PCN marking: >> >> CS2, CS3, CS4, CS5, AF4. > > From your list, I strongly suggest you don't include: > CS2 Ops, Admin & Mgmt (not predictably streamed enough for AC) > CS5 Call signalling (ditto) > > In addition AF3 /might/ be admission controlled. > > Suggested text to replace the end of Appx A.1: > > ============================================================================ > It is recommended to use admission control for the following service > classes listed with their recommended PHBs > [I-D.ietf-tsvwg-admitted-realtime-dscp][RFC4594]: > - Telephony (*) > - Real-time interactive (CS4) > - Broadcast Video (CS3) > - Multimedia Conferencing (AF4) > > *Note: The PHB of the the telephony service class is currently EF, but > [I-D.ietf-tsvwg-admitted-realtime-dscp] proposes a new PHB called > VOICE-ADMIT. It has identical scheduling behaviour to EF, but it is > for use with admission control mechanisms in the network, rather than > at the application layer. If this draft progresses on the standards > track, VOICE-ADMIT rather than EF would become the appropriate > Telephony PHB to which PCN marking would be applied. > > PCN marking is intended to provide a scalable admission control > mechanism for traffic with a high degree of statistical multiplexing. > PCN marking would therefore be appropriate to apply to traffic in the > above classes, but only within a PCN region containing highly > aggregated traffic. > > In such cases, the above service classes may well all be subject to a > single forwarding treatment (a treatment aggregate [RFC5127]). > However, this does not imply all such IP traffic would necessarily be > identified by one DSCP - each service class might keep a distinct DSCP > within the highly aggregated region [RFC5127]. > > Additional service classes may be defined for which admission control > is appropriate, whether through some future standards action or > through local use by certain operators, e.g. the Multimedia Streaming > service class (AF3). This document does not preclude the use of PCN in > more cases than those listed above. > > The above discussion is informative not normative, as operators are > ultimately free to decide whether to use admission control for certain > service classes and whether to use PCN as their mechanism of choice. > ============================================================================== > > Bob > > > >> >> Phil in an earlier email suggested EF as well. >> >> Does that seem like a sensible list? Should we actually play it safe >> and reduce it slightly? >> >> Toby >> >> >> *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R >> *Sent:* 19 August 2009 13:51 >> *To:* Moncaster,T,Toby,DER3 R; Ruediger.Geib@telekom.de >> *Cc:* pcn@ietf.org >> *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> >> Toby, >> >> At 09:39 19/08/2009, toby.moncaster@bt.com wrote: >> >> That ASCII art is still unreadable because (for me at least) it is >> getting displayed in a variable-width font (Times New Roman to be >> exact). I ended up having to convert it to Courier to be able to see >> what you meant… >> >> The Tao of email says that's your problem. I sent it as plain text >> (and even if I didn't it would have been Courier New (fixed)). >> >> >> >> I am in the process of drafting a reply setting out the background to >> this confusion and hopefully solving it. In the meantime there seems >> to be a consensus that the way ahead is to recommend PCN as suitable >> for 1 or more EXISTING DSCPs (which means we need to decide which >> ones…). But that still leaves the question of whether we need to say >> something about what needs to happen in the future if someone (say >> Fred Baker) wants to add PCN to a new DSCP. >> >> Ruediger has suggested some. Can you check them off against those >> that Fred discusses in voice-admit. That should give a decent list. >> >> >> Bob >> >> >> >> Toby >> >> *From:* Briscoe,RJ,Bob,XVR9 BRISCORJ R >> *Sent:* 19 August 2009 09:29 >> *To:* Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R >> *Cc:* pcn@ietf.org >> *Subject:* RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> >> Ruediger, >> >> Great. >> >> [As some people couldn't read it, I've also replaced the diag quoted >> in the thread below with narrower ASCII-art to better survive word wrap] >> >> Cheers >> >> >> Bob >> >> At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: >> >> Hi Bob, >> >> I agree to your suggestion to "scrub (ii) and only have (i)..[and >> that] we should list classes that might be appropriate to associate >> with PCN marking." >> >> Regards, >> >> Ruediger >> ------------------------------------------------------------------------ >> *From:* Bob Briscoe [ >> mailto:rbriscoe@jungle.bt.co.uk] >> *Sent:* Tuesday, August 18, 2009 7:37 PM >> *To:* Geib, Rüdiger; toby.moncaster@bt.com >> *Cc:* pcn@ietf.org >> *Subject:* Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> >> Ruediger, >> >> The draft as it stands holds two inconsistent opinions: >> i) " >> >> the aim is for PCN to re-use existing DSCPs >> >> >> >> " (S.4.3.1) >> ii) the second half of Appx A.1, repeated below. >> >> Similarly, your posting, talks about: >> i) applying PCN to existing DSCPs >> ii) reserving DSCPs for PCN. >> >> I believe we should scrub (ii) and only have (i). In place of ii) we >> should list the classes that might be appropriate to associate with >> PCN marking. >> >> In other words, we should only say that an operator _applies_ PCN >> marking to certain existing DSCPs. >> >> No-one needs any additional DSCPs to enable PCN marking. Otherwise >> that would waste DSCPs just to get a different marking behaviour for >> packets requiring the same scheduling behaviour as a pre-existing >> DSCP. The non-wasteful way to do this is to use one DSCP for a >> certain scheduling behaviour, but set the ECN field to a non-zero >> value to turn on PCN marking (S.4.3.1). >> [In MPLS, as there is no ECN field, the efficient way is different. >> Then RFC5129 describes how you would do it.] >> >> To be absolutely sure it's clear what I mean, here's an example: >> >> hi stat mux subnet >> ___________________ >> | same | >> | marking | >> | _____ ____:___ | >> | | || || >> --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- >> | | || || >> --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- >> | | ||________|| >> | | | |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- >> | |_____| | >> | _____ | >> | | | | >> --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ >> | | | | >> --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- >> | |_____| | >> | : | >> | same | >> | scheduling | >> | (BA) | >> |___________________| >> >> >> - The text on each flow shows the DSCP-ECN combination used for that >> segment >> - The boxes around DSCPA/B/C and around DSCPD/E represent the same >> scheduling behaviour applied to multiple DSCPs in the aggregated >> region (a behaviour aggregate). >> - The box around NM for the first two flows represents the same >> marking behaviour (PCN) applied to multiple DSCPs. >> - The flows keep the same DSCP* along their whole path, so when they >> pop out into the lo-stat-mux region on the other side, the DSCP is >> preserved. >> - In practice, traffic might be tunnelled across the hi-stat mux >> region, and at the same time common scheduling behaviours might be >> mapped to a single DSCP in the outer headers. The diagram merely >> shows everything can be done without tunnelling or layering. >> >> * Note: For some non-standardised DSCPs, the DSCP might not actually >> stay the same along the whole path. It might be mapped to local DSCPs >> that are each used for the same class at different points along the path. >> >> >> >> Here's a copy of the 2nd half of Appx A.1, that I think needs >> to >> >> >> be >> >> >> >> removed (sorry, I know I'm a co-author, but...): >> >> >> >> " The choice of which DSCP is most >> suitable >> >> >> for >> >> >> >> a given PCN-domain is dependant on the nature >> of >> >> >> the >> >> >> >> traffic >> >> >> >> entering >> >> >> >> that domain and the link rates of all the links >> making >> >> >> up >> >> >> >> that >> >> >> >> domain. In PCN-domains with uniformly >> high >> >> >> link >> >> >> >> rates, >> >> >> >> the >> >> >> >> appropriate DSCPs would currently be those for >> the >> >> >> Real >> >> >> >> Time >> >> >> >> Traffic >> >> >> >> Class >> >> >> >> [RFC5127 ]. >> If >> >> >> the >> >> >> >> PCN domain includes lower speed links it >> >> >> >> would also be appropriate to use the DSCPs of >> the >> >> >> other >> >> >> >> traffic >> >> >> >> classes that >> >> >> >> >> >> >> >> >> >> [ >> >> >> >> >> >> >> >> >> >> Voice-Admit ] defines for use with admission control, >> >> >> >> such as the three video classes CS4, CS3 and AF4 >> and >> >> >> the >> >> >> >> Admitted >> >> >> >> Telephony Class. The PCN working group >> will >> >> >> maintain >> >> >> >> a >> >> >> >> list of PCN- >> >> >> >> compatible Diffserv Codepoints. >> >> >> >> " >> >> At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: >> Toby, >> >> PCN should express to the IANA, whether one or more new DSCP is >> required to operate or carry out experiments on PCN. >> >> As soon as IANA maintains a list of DSCPs for any purpose, this >> will have the status of a standard. >> >> "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs >> per traffic class (DSCP bit 0-2, let's call them traffic class >> in this email) for PCN, that's 32 DSCPs in all. >> >> If possible, PCN should limit the number of traffic classes, >> where to apply PCN. >> >> I don't think PCN will be applied in traffic classes 0 and 6. >> >> I'd expect PCN to be used within traffic classes 5 and 4, >> may be also 3 or 2. >> Traffic classes 1 and 7 may be excluded too. >> >> The above clearly expresses personal views, but informational >> RFC5127 to some extent backs these personal views. >> >> I'm aware that PCN WG shouldn't standardise traffic class usage >> or come close to that. I however want to avoid repeating the biggest >> flaw of the AF specification, which in my eyes is to reserve >> 12 DSCPs for 4 traffic classes. >> >> Regards, >> >> Ruediger >> >> >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf >> Of toby.moncaster@bt.com >> Sent: Friday, August 14, 2009 3:06 PM >> To: lars.eggert@nokia.com; pcn@ietf.org >> Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> >> Hi Lars, >> >> Sorry not to get back to you earlier - been busy at work so this went on >> a back-burner for a few days. >> >> The original intention of having registration was to avoid confusion >> during any early experimental adoption of PCN however that could be done >> purely unofficially by having a list of DSCPs on the IETF wiki and just >> politely asking developers to consult it and add any new ones they are >> using. But there will need in future to be a process to formally >> register certain standards (pool 1) DSCPs as PCN-compatible since this >> effectively replaces ECN as the default behaviour for such DSCPs. So my >> suggestion is: >> >> Change the IANA section to say something along the following lines (I >> will get IANA assistance with crafting exact text): >> >> "IANA will be asked to set up a registry of PCN-compatible Diffserv >> codepoints. The decision as to whether to enable PCN for a given pool 1 >> codepoint must be made by the appropriate IETF Transport Area Working >> Group (TSVWG?) which will then request IANA to add this to the >> registry." >> >> Clarify at start of A.1 that the decision of which DSCPs to apply PCN to >> has to be made by TSVWG and is separate to this document which just >> defines the process and the encoding. >> >> Change the last sentence of A.1 to "IANA will maintain a list of >> PCN-compatible Diffserv Codepoints." >> >> Would this cover things appropriately? I did wonder about asking IANA to >> maintain the experimental registry but I am not sure if they are able to >> do that sort of thing? If so the following could be added to the IANA >> section: >> >> "During the early stages of adoption it is envisaged that PCN will be >> used experimentally using pool 2 or 3 DSCPs (experimental or local use). >> Whilst these DSCPs are not controlled by IANA normally, a request will >> be made to maintain a list of PCN experiments along with the DSCPs these >> experiments are using." >> >> Once I get the nod from WG I will release a new version of the I-D with >> these updates... >> >> Toby >> >> > -----Original Message----- >> > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of >> > Lars Eggert >> > Sent: 14 August 2009 12:27 >> > To: pcn@ietf.org >> > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >> > >> > Hi, >> > >> > I'm waiting to hear from the authors/WG. >> > >> > Lars >> > >> > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >> > >> > > Hi, >> > > >> > > this document is ready, except for one issue: >> > > >> > > Section 7., paragraph 1: >> > >> This document makes no direct request to IANA. However this >> > > document >> > >> allows for a set of Diffserv Codepoints to be assigned different >> > > ECN >> > >> semantics within a controlled domain as described in [RFC4774]. >> A >> > >> list of such DSCPs will be maintained by the PCN working group. >> > > >> > > DISCUSS: This text isn't aligned with appendix A.1. The text here >> > > says >> > > "the WG will maintain a list of DSCPs that are OK", while the >> > > beginning of appendix A.1 says "the WG decided to not define with >> > > which DSCPs PCN can be used" (but then the end of A.1 talks about >> > > maintaining a list again.) Which is it? If there is to be a list, >> > > you >> > > need to create an IANA registry, write management procedures for >> it >> > > (see RFC5226) and populate it with some initial values. (WGs are >> > > ephemeral, which is why the PCN WG can't be the maintainer of this >> > > list, IANA has to be.) If you want to leave it fully open for >> > > deployments, you need to remove this confusion from the text. >> > > >> > > Lars >> > > >> > > >> > > Nits: >> > > >> > > Section 4., paragraph 3: >> > >> to prevent future compatability issues. >> > > >> > > Nit: s/compatability/compatibility/ >> > > >> > > >> > > Section 4.2., paragraph 1: >> > >> that is guaranteeed to be copied down into the inner header upon >> > > >> > > Nit: s/guaranteeed/guaranteed/ >> > > >> > > >> > > Section 6., paragraph 1: >> > >> always copy the CE codepoint from teh outer header into the inner >> > > >> > > Nit: s/teh/the/ >> > > >> > > >> > > Section 6., paragraph 2: >> > >> header in decapsulation (unless the inner packet is not-ECT). >> > > If an >> > >> operator it is essential that any operator wishing to allow ECN >> to >> > >> exist end-to-end ensures there are no tunnel end-points within >> the >> > >> PCN-domain. >> > > >> > > "If an operator it is essential that any operator..." - wording >> > > >> > > >> > > Section 12., paragraph 0: >> > >> 12. References >> > > >> > > Should be updated; see idnits report. >> > > >> > > >> > > Appendix A., paragraph 2: >> > >> a given PCN-domain is dependant on the nature of the traffic >> > > entering >> > > >> > > Nit: s/dependant/dependent/ >> > > >> > > >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- 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 Ruediger.Geib@telekom.de Wed Aug 19 23:57: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 54BB93A6907 for ; Wed, 19 Aug 2009 23:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 bZfSY0B5u0Ys for ; Wed, 19 Aug 2009 23:57:30 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 136CC3A68C1 for ; Wed, 19 Aug 2009 23:57:28 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 20 Aug 2009 08:57:29 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 08:57:28 +0200 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_01CA2163.7B0D18A8" Date: Thu, 20 Aug 2009 08:57:25 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501E99439@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <200908191555.n7JFtegc025672@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Thread-Index: Acog5ZfSBptr3BZlTtyHm1gbn/jFKwAeLCXw References: <713C2B6C-6DAF-4A1B-8071-882EBCA9C8DC@nokia.com> <151C164FE2E066418D8D44D0801543A501E56C7B@S4DE8PSAAQA.mitte.t-com.de> <200908181736.n7IHaZjk032639@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A501E5746A@S4DE8PSAAQA.mitte.t-com.de> <200908190829.n7J8TTgm015982@bagheera.jungle.bt.co.uk> <200908191251.n7JCpHG7021784@bagheera.jungle.bt.co.uk> <200908191555.n7JFtegc025672@bagheera.jungle.bt.co.uk> From: To: X-OriginalArrivalTime: 20 Aug 2009 06:57:28.0886 (UTC) FILETIME=[7B602D60:01CA2163] Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 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, 20 Aug 2009 06:57:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2163.7B0D18A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bob, =20 I largely agree to what you propose below. From the point of view=20 of a carrier operating an MPLS LDP based backbone, the following=20 situation arises: - the carrier may offer public telephony. This service is fully=20 controlled by the carrier and if this carrier deploys any=20 network based admission control, it doesn't matter, whteher the=20 DSCP is EF or Voice admit. It will however be one of both only. - the same carrier may offer VPN services with EF transport. The=20 interface to access a VPN may be Ethernet, IP or MPLS. - if such a carrier supports four traffic classes in the MPLS=20 backbone, Voice admit and EF are likely to be transported in=20 the same queue. - there's one MPLS TC available for not congested traffic and=20 one indicating congestion experienced. As all in all only 8 TCs=20 are available, this is a scarce resource making it unlikely=20 to get one MPLS TC for EF, one for Voice_admit and another=20 one for Voice_admit_congestion_experienced. =20 Carriers usually have little control about how VPN customers use EF. =20 While the above may sound disappointing, I don't look at it to=20 prevent deployment of PCN or other solutions offering network=20 based admission control. Diffserv isn't a greenfield approach,=20 so dealing with existing environments is a natural provider task.=20 Traffic levels are an issue. VPN EF traffic may in future=20 contribute a small percentage of load as compared to public=20 VoIP traffic. But I'm not having any numbers, that's an=20 assumption only. =20 Separation of EF and Voice_admit may only exist on IP=20 level - but I don't want to discuss this now. PCN to me=20 is to far from being ready for deployment. =20 =20 Regards, =20 Ruediger =20 _____ =20 From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: Wednesday, August 19, 2009 5:56 PM To: toby.moncaster@bt.com; Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Toby, At 14:27 19/08/2009, toby.moncaster@bt.com wrote: Leaving aside ASCII art. =20 >From Ruediger's list below and Fred's draft the following seems like a = possible list of DSCPs that might reasonably employ PCN marking: =20 CS2, CS3, CS4, CS5, AF4. >From your list, I strongly suggest you don't include: CS2 Ops, Admin & Mgmt (not predictably streamed enough for AC) CS5 Call signalling (ditto) In addition AF3 /might/ be admission controlled. Suggested text to replace the end of Appx A.1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D It is recommended to use admission control for the following service = classes listed with their recommended PHBs = [I-D.ietf-tsvwg-admitted-realtime-dscp][RFC4594]: - Telephony (*) - Real-time interactive (CS4) - Broadcast Video (CS3) - Multimedia Conferencing (AF4) *Note: The PHB of the the telephony service class is currently EF, but = [I-D.ietf-tsvwg-admitted-realtime-dscp] proposes a new PHB called = VOICE-ADMIT. It has identical scheduling behaviour to EF, but it is for = use with admission control mechanisms in the network, rather than at the = application layer. If this draft progresses on the standards track, = VOICE-ADMIT rather than EF would become the appropriate Telephony PHB to = which PCN marking would be applied.=20 PCN marking is intended to provide a scalable admission control = mechanism for traffic with a high degree of statistical multiplexing. = PCN marking would therefore be appropriate to apply to traffic in the = above classes, but only within a PCN region containing highly = aggregated traffic. In such cases, the above service classes may well all be subject to a = single forwarding treatment (a treatment aggregate [RFC5127]). However, = this does not imply all such IP traffic would necessarily be identified = by one DSCP - each service class might keep a distinct DSCP within the = highly aggregated region [RFC5127]. Additional service classes may be defined for which admission control is = appropriate, whether through some future standards action or through = local use by certain operators, e.g. the Multimedia Streaming service = class (AF3). This document does not preclude the use of PCN in more = cases than those listed above.=20 The above discussion is informative not normative, as operators are = ultimately free to decide whether to use admission control for certain = service classes and whether to use PCN as their mechanism of choice. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Bob Phil in an earlier email suggested EF as well. =20 Does that seem like a sensible list? Should we actually play it safe and = reduce it slightly? =20 Toby =20 =20 From: Briscoe,RJ,Bob,XVR9 BRISCORJ R=20 Sent: 19 August 2009 13:51 To: Moncaster,T,Toby,DER3 R; Ruediger.Geib@telekom.de Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 =20 Toby, At 09:39 19/08/2009, toby.moncaster@bt.com wrote: That ASCII art is still unreadable because (for me at least) it is = getting displayed in a variable-width font (Times New Roman to be = exact). I ended up having to convert it to Courier to be able to see = what you meant... The Tao of email says that's your problem. I sent it as plain text (and = even if I didn't it would have been Courier New (fixed)).=20 =20 I am in the process of drafting a reply setting out the background to = this confusion and hopefully solving it. In the meantime there seems to = be a consensus that the way ahead is to recommend PCN as suitable for 1 = or more EXISTING DSCPs (which means we need to decide which ones...). = But that still leaves the question of whether we need to say something = about what needs to happen in the future if someone (say Fred Baker) = wants to add PCN to a new DSCP. Ruediger has suggested some. Can you check them off against those that = Fred discusses in voice-admit. That should give a decent list. Bob =20 Toby =20 From: Briscoe,RJ,Bob,XVR9 BRISCORJ R=20 Sent: 19 August 2009 09:29 To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3 R Cc: pcn@ietf.org Subject: RE: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 =20 Ruediger, Great. [As some people couldn't read it, I've also replaced the diag quoted in = the thread below with narrower ASCII-art to better survive word wrap] Cheers Bob At 07:27 19/08/2009, Ruediger.Geib@telekom.de wrote: Hi Bob, =20 I agree to your suggestion to "scrub (ii) and only have (i)..[and that] = we should list classes that might be appropriate to associate with PCN = marking." =20 Regards, =20 Ruediger _____ =20 From: Bob Briscoe [ = mailto:rbriscoe@jungle.bt.co.uk]=20 Sent: Tuesday, August 18, 2009 7:37 PM To: Geib, R=FCdiger; toby.moncaster@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Ruediger, The draft as it stands holds two inconsistent opinions: i) " the aim is for PCN to re-use existing DSCPs " (S.4.3.1) ii) the second half of Appx A.1, repeated below. Similarly, your posting, talks about: i) applying PCN to existing DSCPs ii) reserving DSCPs for PCN. I believe we should scrub (ii) and only have (i). In place of ii) we = should list the classes that might be appropriate to associate with PCN = marking. In other words, we should only say that an operator _applies_ PCN = marking to certain existing DSCPs. No-one needs any additional DSCPs to enable PCN marking. Otherwise that = would waste DSCPs just to get a different marking behaviour for packets = requiring the same scheduling behaviour as a pre-existing DSCP. The = non-wasteful way to do this is to use one DSCP for a certain scheduling = behaviour, but set the ECN field to a non-zero value to turn on PCN = marking (S.4.3.1). [In MPLS, as there is no ECN field, the efficient way is different. Then = RFC5129 describes how you would do it.] To be absolutely sure it's clear what I mean, here's an example: hi stat mux subnet ___________________ | same | | marking | | _____ ____:___ | | | || || --DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT-- | | || || --DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT-- | | ||________|| | | | = |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT-- | |_____| | | _____ | | | | | --DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------ | | | | --DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT-- | |_____| | | : | | same | | scheduling | | (BA) | |___________________| - The text on each flow shows the DSCP-ECN combination used for that = segment - The boxes around DSCPA/B/C and around DSCPD/E represent the same = scheduling behaviour applied to multiple DSCPs in the aggregated region = (a behaviour aggregate). - The box around NM for the first two flows represents the same marking = behaviour (PCN) applied to multiple DSCPs. - The flows keep the same DSCP* along their whole path, so when they pop = out into the lo-stat-mux region on the other side, the DSCP is = preserved. - In practice, traffic might be tunnelled across the hi-stat mux region, = and at the same time common scheduling behaviours might be mapped to a = single DSCP in the outer headers. The diagram merely shows everything = can be done without tunnelling or layering. * Note: For some non-standardised DSCPs, the DSCP might not actually = stay the same along the whole path. It might be mapped to local DSCPs = that are each used for the same class at different points along the = path. Here's a copy of the 2nd half of Appx A.1, that I think needs to be =20 removed (sorry, I know I'm a co-author, but...): =20 " The choice of which DSCP is most suitable for =20 a given PCN-domain is dependant on the nature of the =20 traffic =20 entering =20 that domain and the link rates of all the links making up =20 that =20 domain. In PCN-domains with uniformly high link =20 rates, =20 the =20 appropriate DSCPs would currently be those for the Real =20 Time =20 Traffic =20 Class =20 [RFC5127 ].=20 If the =20 PCN domain includes lower speed links it =20 would also be appropriate to use the DSCPs of the other =20 traffic =20 classes that =20 =20 = =20 [ =20 =20 = =20 Voice-Admit] defines for use with admission control, =20 such as the three video classes CS4, CS3 and AF4 and the =20 Admitted =20 Telephony Class. The PCN working group will maintain =20 a =20 list of PCN- =20 compatible Diffserv Codepoints. " At 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote: Toby, PCN should express to the IANA, whether one or more new DSCP is=20 required to operate or carry out experiments on PCN. As soon as IANA maintains a list of DSCPs for any purpose, this=20 will have the status of a standard.=20 "Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs=20 per traffic class (DSCP bit 0-2, let's call them traffic class=20 in this email) for PCN, that's 32 DSCPs in all. If possible, PCN should limit the number of traffic classes,=20 where to apply PCN. I don't think PCN will be applied in traffic classes 0 and 6. I'd expect PCN to be used within traffic classes 5 and 4,=20 may be also 3 or 2. Traffic classes 1 and 7 may be excluded too. The above clearly expresses personal views, but informational=20 RFC5127 to some extent backs these personal views. I'm aware that PCN WG shouldn't standardise traffic class usage=20 or come close to that. I however want to avoid repeating the biggest=20 flaw of the AF specification, which in my eyes is to reserve=20 12 DSCPs for 4 traffic classes. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com Sent: Friday, August 14, 2009 3:06 PM To: lars.eggert@nokia.com; pcn@ietf.org Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 Hi Lars, Sorry not to get back to you earlier - been busy at work so this went on a back-burner for a few days.=20 The original intention of having registration was to avoid confusion during any early experimental adoption of PCN however that could be done purely unofficially by having a list of DSCPs on the IETF wiki and just politely asking developers to consult it and add any new ones they are using. But there will need in future to be a process to formally register certain standards (pool 1) DSCPs as PCN-compatible since this effectively replaces ECN as the default behaviour for such DSCPs. So my suggestion is: Change the IANA section to say something along the following lines (I will get IANA assistance with crafting exact text): "IANA will be asked to set up a registry of PCN-compatible Diffserv codepoints. The decision as to whether to enable PCN for a given pool 1 codepoint must be made by the appropriate IETF Transport Area Working Group (TSVWG?) which will then request IANA to add this to the registry." Clarify at start of A.1 that the decision of which DSCPs to apply PCN to has to be made by TSVWG and is separate to this document which just defines the process and the encoding. Change the last sentence of A.1 to "IANA will maintain a list of PCN-compatible Diffserv Codepoints." Would this cover things appropriately? I did wonder about asking IANA to maintain the experimental registry but I am not sure if they are able to do that sort of thing? If so the following could be added to the IANA section: "During the early stages of adoption it is envisaged that PCN will be used experimentally using pool 2 or 3 DSCPs (experimental or local use). Whilst these DSCPs are not controlled by IANA normally, a request will be made to maintain a list of PCN experiments along with the DSCPs these experiments are using." Once I get the nod from WG I will release a new version of the I-D with these updates... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 14 August 2009 12:27 > To: pcn@ietf.org > Subject: Re: [PCN] AD review: draft-ietf-pcn-baseline-encoding-04 >=20 > Hi, >=20 > I'm waiting to hear from the authors/WG. >=20 > Lars >=20 > On 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, > > > > this document is ready, except for one issue: > > > > Section 7., paragraph 1: > >> This document makes no direct request to IANA. However this > > document > >> allows for a set of Diffserv Codepoints to be assigned different > > ECN > >> semantics within a controlled domain as described in [RFC4774]. A > >> list of such DSCPs will be maintained by the PCN working group. > > > > DISCUSS: This text isn't aligned with appendix A.1. The text here > > says > > "the WG will maintain a list of DSCPs that are OK", while the > > beginning of appendix A.1 says "the WG decided to not define with > > which DSCPs PCN can be used" (but then the end of A.1 talks about > > maintaining a list again.) Which is it? If there is to be a list, > > you > > need to create an IANA registry, write management procedures for it > > (see RFC5226) and populate it with some initial values. (WGs are > > ephemeral, which is why the PCN WG can't be the maintainer of this > > list, IANA has to be.) If you want to leave it fully open for > > deployments, you need to remove this confusion from the text. > > > > Lars > > > > > > Nits: > > > > Section 4., paragraph 3: > >> to prevent future compatability issues. > > > > Nit: s/compatability/compatibility/ > > > > > > Section 4.2., paragraph 1: > >> that is guaranteeed to be copied down into the inner header upon > > > > Nit: s/guaranteeed/guaranteed/ > > > > > > Section 6., paragraph 1: > >> always copy the CE codepoint from teh outer header into the inner > > > > Nit: s/teh/the/ > > > > > > Section 6., paragraph 2: > >> header in decapsulation (unless the inner packet is not-ECT). > > If an > >> operator it is essential that any operator wishing to allow ECN to > >> exist end-to-end ensures there are no tunnel end-points within the > >> PCN-domain. > > > > "If an operator it is essential that any operator..." - wording > > > > > > Section 12., paragraph 0: > >> 12. References > > > > Should be updated; see idnits report. > > > > > > Appendix A., paragraph 2: > >> a given PCN-domain is dependant on the nature of the traffic > > entering > > > > Nit: s/dependant/dependent/ > > > > _______________________________________________ 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 ------_=_NextPart_001_01CA2163.7B0D18A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bob,
 
I largely agree to what you propose below. = >From the=20 point of view
of a carrier operating an MPLS LDP based = backbone,=20 the following
situation arises:
- the carrier may offer public telephony. = This service=20 is fully
  controlled by the carrier and if = this=20 carrier deploys any
  network based admission=20 control, it doesn't matter, whteher the
  DSCP is EF or Voice admit. It will = however be=20 one of both only.
- the same carrier may offer VPN services = with EF=20 transport. The
  interface to access a VPN may be = Ethernet, IP or=20 MPLS.
- if such a carrier supports four traffic = classes in=20 the MPLS
  backbone, Voice admit and EF are=20 likely to be transported in
  the same queue.
- there's one MPLS TC available for not = congested=20 traffic and
  one indicating congestion experienced. = As all in=20 all only 8 TCs
  are available,=20 this is a scarce resource making it unlikely=20
  to get one MPLS TC for EF, one = for=20 Voice_admit and another
  one for=20 Voice_admit_congestion_experienced.
 
Carriers usually have little control about = how VPN=20 customers use EF.
 
While the above may sound disappointing, = I don't=20 look at it to
prevent deployment of PCN or other solutions = offering=20 network
based admission control. Diffserv isn't a = greenfield=20 approach,
so dealing with existing environments is a = natural=20 provider task.
Traffic levels are an = issue. VPN EF=20 traffic may in future 
contribute a small = percentage of load=20 as compared to public
VoIP traffic. But I'm not = having any=20 numbers, that's an
assumption only.
 
Separation of EF and Voice_admit may only = exist on=20 IP
level - but I don't want to discuss this now. = PCN to me=20
is to far = from being ready=20 for deployment.
 
 
Regards,
 
Ruediger
 

From: Bob Briscoe=20 [mailto:rbriscoe@jungle.bt.co.uk]
Sent: Wednesday, August 19, = 2009=20 5:56 PM
To: toby.moncaster@bt.com; Geib, = R=FCdiger
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04

Toby,

At 14:27 19/08/2009, toby.moncaster@bt.com = wrote:
Leaving aside ASCII=20 art.
 
From Ruediger’s list below and Fred’s = draft the following=20 seems like a possible list of DSCPs that might reasonably employ PCN=20 marking:
 
CS2, CS3, CS4, CS5, AF4.

From = your list, I=20 strongly suggest you don't=20 include:
CS2     Ops, Admin = &=20 Mgmt (not predictably streamed enough for=20 AC)
CS5     Call signalling=20 (ditto)

In addition AF3 /might/ be admission = controlled.

Suggested=20 text to replace the end of Appx=20 A.1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
It=20 is recommended to use admission control for the following service = classes listed=20 with their recommended PHBs=20 [I-D.ietf-tsvwg-admitted-realtime-dscp][RFC4594]:
- Telephony = (*)
-=20 Real-time interactive (CS4)
- Broadcast Video (CS3)
- Multimedia=20 Conferencing (AF4)

*Note: The PHB of the the telephony service = class is=20 currently EF, but [I-D.ietf-tsvwg-admitted-realtime-dscp] proposes a new = PHB=20 called VOICE-ADMIT. It has identical scheduling behaviour to EF, but it = is for=20 use with admission control mechanisms in the network, rather than at the = application layer. If this draft progresses on the standards track, = VOICE-ADMIT=20 rather than EF would become the appropriate Telephony PHB to which PCN = marking=20 would be applied.

PCN marking is intended to provide a scalable=20 admission control mechanism for traffic with a high degree of = statistical=20 multiplexing. PCN marking would therefore be appropriate to apply to = traffic in=20 the above classes, but only  within a PCN region containing highly=20 aggregated traffic.

In such cases, the above service classes may = well all=20 be subject to a single forwarding treatment (a treatment aggregate = [RFC5127]).=20 However, this does not imply all such IP traffic would necessarily be = identified=20 by one DSCP - each service class might keep a distinct DSCP within the = highly=20 aggregated region [RFC5127].

Additional service classes may be = defined=20 for which admission control is appropriate, whether through some future=20 standards action or through local use by certain operators, e.g. the = Multimedia=20 Streaming service class (AF3). This document does not preclude the use = of PCN in=20 more cases than those listed above.

The above discussion is = informative=20 not normative, as operators are ultimately free to decide whether to use = admission control for certain service classes and whether to use PCN as = their=20 mechanism of=20 choice.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Bob




Phil in an earlier = email=20 suggested EF as well.
 
Does that seem like a sensible = list? Should=20 we actually play it safe and reduce it=20 slightly?
 
Toby
 
 
From:=20 Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009=20 13:51
To: Moncaster,T,Toby,DER3 R;=20 Ruediger.Geib@telekom.de
Cc: pcn@ietf.org
Subject: = RE:=20 [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04
 
Toby,

At 09:39 = 19/08/2009, toby.moncaster@bt.com wrote:

That ASCII art is = still=20 unreadable because (for me at least) it is getting displayed in a=20 variable-width font (Times New Roman to be exact). I ended up having = to=20 convert it to Courier to be able to see what you = meant…

The Tao of=20 email says that's your problem. I sent it as plain text (and even if I = didn't=20 it would have been Courier New (fixed)).


 
I am in = the=20 process of drafting a reply setting out the background to this = confusion and=20 hopefully solving it. In the meantime there seems to be a consensus = that the=20 way ahead is to recommend PCN as suitable for 1 or more EXISTING DSCPs = (which=20 means we need to decide which ones…). But that still leaves the = question of=20 whether we need to say something about what needs to happen in the = future if=20 someone (say Fred Baker) wants to add PCN to a new = DSCP.

Ruediger has=20 suggested some. Can you check them off against those that Fred = discusses in=20 voice-admit. That should give a decent=20 = list.


Bob


 
Toby
 
From: = Briscoe,RJ,Bob,XVR9 BRISCORJ R
Sent: 19 August 2009=20 09:29
To: Ruediger.Geib@telekom.de; Moncaster,T,Toby,DER3=20 R
Cc: pcn@ietf.org
Subject: RE: [PCN] AD review:=20 = draft-ietf-pcn-baseline-encoding-04
 
Ruediger,

Great.<= BR>
[As=20 some people couldn't read it, I've also replaced the diag quoted in = the thread=20 below with narrower ASCII-art to better survive word=20 wrap]

Cheers


Bob

At 07:27 19/08/2009,=20 Ruediger.Geib@telekom.de wrote:

Hi Bob,
 
I agree to = your=20 suggestion to "scrub (ii) and only have (i)..[and that] we should list = classes=20 that might be appropriate to associate with PCN=20 marking."
 
Regards,
 
Ruediger
From: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk<= /A>]=20
Sent: Tuesday, August 18, 2009 7:37 PM
To: Geib, = R=FCdiger;=20 toby.moncaster@bt.com
Cc: pcn@ietf.org
Subject: = Re: [PCN]=20 AD review: = draft-ietf-pcn-baseline-encoding-04

Ruediger,

The=20 draft as it stands holds two inconsistent opinions:
i) = "

the aim is for PCN to re-use existing =
DSCPs



"=20 (S.4.3.1)
ii) the second half of Appx A.1, repeated=20 below.

Similarly, your posting, talks about:
i) applying PCN = to=20 existing DSCPs
ii) reserving DSCPs for PCN.

I believe we = should=20 scrub (ii) and only have (i). In place of ii) we should list the = classes that=20 might be appropriate to associate with PCN marking.

In other = words, we=20 should only say that an operator _applies_ PCN marking to certain = existing=20 DSCPs.

No-one needs any additional DSCPs to enable PCN marking. = Otherwise that would waste DSCPs just to get a different marking = behaviour for=20 packets requiring the same scheduling behaviour as a pre-existing = DSCP. The=20 non-wasteful way to do this is to use one DSCP for a certain = scheduling=20 behaviour, but set the ECN field to a non-zero value to turn on PCN = marking=20 (S.4.3.1).
[In MPLS, as there is no ECN field, the efficient way is = different. Then RFC5129 describes how you would do it.]

To be=20 absolutely sure it's clear what I mean, here's an=20 = example:

         &nb= sp;        =20 hi stat mux=20 = subnet
          &nb= sp;       =20 = ___________________
        &n= bsp;        =20 |           =20 same  =20 = |
           &n= bsp;     =20 |           marking=20 = |
           &n= bsp;     =20 |   _____  ____:___=20 = |
           &n= bsp;     =20 |  |     = ||       =20 = ||
--DSCPA--Not-ECT------DSCPA--NM----------DSCPA--Not-ECT--
 =             &= nbsp;   =20 |  |     = ||       =20 = ||
--DSCPB--Not-ECT------DSCPB--NM----------DSCPB--Not-ECT--
 =             &= nbsp;   =20 |  |    =20 = ||________||
         &nb= sp;       =20 |  |    =20 |         =20 = |--DSCPC--Not-ECT------DSCPC--Not-PCN-----DSCPC--Not-ECT--
  = ;            =    =20 |  |_____|         =20 = |
           &n= bsp;     =20 |  =20 _____          =20 = |
           &n= bsp;     =20 |  |    =20 |         =20 = |
--DSCPD--ECT----------DSCPD--ECT---------DSCPD--ECT------
 &= nbsp;           &n= bsp;   =20 |  |    =20 |         =20 = |
--DSCPE--Not-ECT------DSCPE--Not-PCN-----DSCPE--Not-ECT--
 &= nbsp;           &n= bsp;   =20 |  |_____|         =20 = |
           &n= bsp;     =20 |    =20 = :            = =20 = |
           &n= bsp;     =20 |  =20 same            = = |
           &n= bsp;     =20 | scheduling       =20 = |
           &n= bsp;     =20 |  =20 (BA)            = = |
           &n= bsp;     =20 |___________________|


- The text on each flow shows the = DSCP-ECN=20 combination used for that segment
- The boxes around DSCPA/B/C and = around=20 DSCPD/E represent the same scheduling behaviour applied to multiple = DSCPs in=20 the aggregated region (a behaviour aggregate).
- The box around NM = for the=20 first two flows represents the same marking behaviour (PCN) applied to = multiple DSCPs.
- The flows keep the same DSCP* along their whole = path, so=20 when they pop out into the lo-stat-mux region on the other side, the = DSCP is=20 preserved.
- In practice, traffic might be tunnelled across the = hi-stat mux=20 region, and at the same time common scheduling behaviours might be = mapped to a=20 single DSCP in the outer headers. The diagram merely shows everything = can be=20 done without tunnelling or layering.

* Note: For some = non-standardised=20 DSCPs, the DSCP might not actually stay the same along the whole path. = It=20 might be mapped to local DSCPs that are each used for the same class = at=20 different points along the path.



Here's a copy of =
the 2nd half of Appx A.1, that I think needs
to


be

 

removed (sorry, I =
know I'm a co-author, but...):

 

"  The =
choice of which DSCP is most
suitable


for

 

   =
a given PCN-domain is dependant on the nature
of


the

 

traffic

&nb= sp;

entering

 

   that =
domain and the link rates of all the links
making


up

 

that

&nb= sp;

   domain.  In PCN-domains with uniformly
high


link

 

rates,

&= nbsp;

the

 

   =
appropriate DSCPs would currently be those for
the


Real

 

Time

&nbs= p;

Traffic

 

   =
Class

 

[RFC5127]. 
If


the

 

PCN domain includes =
lower speed links it

 

   would also =
be appropriate to use the DSCPs of
the


other

 

traffic

=  

   classes =
that

 

 





[

 

 





Voice-Admit] defines for use with admission =
control,

 

   such as the three =
video classes CS4, CS3 and AF4
and


the

 

Admitted

&= nbsp;

   Telephony Class.  The PCN working =
group
will


maintain

 

a

&n= bsp;

list of PCN-

 

   =
compatible Diffserv Codepoints.



"

At=20 08:55 18/08/2009, Ruediger.Geib@telekom.de wrote:
Toby,

PCN = should=20 express to the IANA, whether one or more new DSCP is
required to = operate=20 or carry out experiments on PCN.

As soon as IANA maintains a = list of=20 DSCPs for any purpose, this
will have the status of a standard.=20

"Using pool 2 or 3 DSCPs" to me sounds like reserving 4 DSCPs =
per=20 traffic class (DSCP bit 0-2, let's call them traffic class
in this = email)=20 for PCN, that's 32 DSCPs in all.

If possible, PCN should limit = the=20 number of traffic classes,
where to apply PCN.

I don't = think PCN=20 will be applied in traffic classes 0 and 6.

I'd expect PCN to = be used=20 within traffic classes 5 and 4,
may be also 3 or 2.
Traffic = classes 1=20 and 7 may be excluded too.

The above clearly expresses personal = views,=20 but informational
RFC5127 to some extent backs these personal=20 views.

I'm aware that PCN WG shouldn't standardise traffic = class usage=20
or come close to that. I however want to avoid repeating the = biggest=20
flaw of the AF specification, which in my eyes is to reserve =
12 DSCPs=20 for 4 traffic=20 classes.

Regards,

Ruediger



-----Original=20 Message-----
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] = On Behalf=20 Of toby.moncaster@bt.com
Sent: Friday, August 14, 2009 3:06 = PM
To:=20 lars.eggert@nokia.com; pcn@ietf.org
Subject: Re: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04

Hi Lars,

Sorry not = to get=20 back to you earlier - been busy at work so this went on
a = back-burner for a=20 few days.

The original intention of having registration was to = avoid=20 confusion
during any early experimental adoption of PCN however = that could=20 be done
purely unofficially by having a list of DSCPs on the IETF = wiki and=20 just
politely asking developers to consult it and add any new ones = they=20 are
using. But there will need in future to be a process to=20 formally
register certain standards (pool 1) DSCPs as = PCN-compatible since=20 this
effectively replaces ECN as the default  behaviour for = such=20 DSCPs. So my
suggestion is:

Change the IANA section to say = something=20 along the following lines (I
will get IANA assistance with crafting = exact=20 text):

"IANA will be asked to set up a registry of = PCN-compatible=20 Diffserv
codepoints. The decision as to whether to enable PCN for a = given=20 pool 1
codepoint must be made by the appropriate IETF Transport = Area=20 Working
Group (TSVWG?) which will then request IANA to add this to=20 the
registry."

Clarify at start of A.1 that the decision of = which=20 DSCPs to apply PCN to
has to be made by TSVWG and is separate to = this=20 document which just
defines the process and the = encoding.

Change the=20 last sentence of A.1 to "IANA will maintain a list = of
PCN-compatible=20 Diffserv Codepoints."

Would this cover things appropriately? I = did=20 wonder about asking IANA to
maintain the experimental registry but = I am not=20 sure if they are able to
do that sort of thing? If so the following = could=20 be added to the IANA
section:

"During the early stages of = adoption=20 it is envisaged that PCN will be
used experimentally using pool 2 = or 3=20 DSCPs (experimental or local use).
Whilst these DSCPs are not = controlled by=20 IANA normally, a request will
be made to maintain a list of PCN = experiments=20 along with the DSCPs these
experiments are using."

Once I = get the=20 nod from WG I will release a new version of the I-D with
these=20 updates...

Toby

> -----Original Message-----
> = From:=20 pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] = On Behalf=20 Of
> Lars Eggert
> Sent: 14 August 2009 12:27
> To:=20 pcn@ietf.org
> Subject: Re: [PCN] AD review:=20 draft-ietf-pcn-baseline-encoding-04
>
> Hi,
> =
> I'm=20 waiting to hear from the authors/WG.
>
> Lars
> =
> On=20 2009-8-5, at 17:19, Eggert Lars (Nokia-NRC/Espoo) wrote:
> =
> >=20 Hi,
> >
> > this document is ready, except for one=20 issue:
> >
> > Section 7., paragraph 1:
>=20 >>   This document makes no direct request to = IANA. =20 However this
> > document
> >>   allows = for a=20 set of Diffserv Codepoints to be assigned different
> > = ECN
>=20 >>   semantics within a controlled domain as described = in=20 [RFC4774].
A
> >>   list of such DSCPs will = be=20 maintained by the PCN working group.
> >
> = >  =20 DISCUSS: This text isn't aligned with appendix A.1. The text = here
> >=20 says
> >   "the WG will maintain a list of DSCPs = that are=20 OK", while the
> >   beginning of appendix A.1 says = "the WG=20 decided to not define with
> >   which DSCPs PCN = can be=20 used" (but then the end of A.1 talks about
> >  =20 maintaining a list again.) Which is it? If there is to be a = list,
> >=20 you
> >   need to create an IANA registry, write = management=20 procedures for
it
> >   (see RFC5226) and = populate it=20 with some initial values. (WGs are
> >   ephemeral, = which=20 is why the PCN WG can't be the maintainer of this
> = >  =20 list, IANA has to be.) If you want to leave it fully open for
>=20 >   deployments, you need to remove this confusion from = the=20 text.
> >
> > Lars
> >
> >
> = >=20 Nits:
> >
> > Section 4., paragraph 3:
>=20 = >>           = ;      =20 to prevent future compatability issues.
> >
> = >  =20 Nit: s/compatability/compatibility/
> >
> >
> = >=20 Section 4.2., paragraph 1:
> >>   that is = guaranteeed to=20 be copied down into the inner header upon
> >
>=20 >   Nit: s/guaranteeed/guaranteed/
> >
>=20 >
> > Section 6., paragraph 1:
> = >>   always=20 copy the CE codepoint from teh outer header into the inner
>=20 >
> >   Nit: s/teh/the/
> >
>=20 >
> > Section 6., paragraph 2:
> = >>   header=20 in decapsulation (unless the inner packet is not-ECT).
> > If = an
> >>   operator it is essential that any = operator=20 wishing to allow ECN
to
> >>   exist = end-to-end=20 ensures there are no tunnel end-points within
the
>=20 >>   PCN-domain.
> >
> >   = "If an=20 operator it is essential that any operator..." - wording
> = >
>=20 >
> > Section 12., paragraph 0:
> >> 12.  = References
> >
> >   Should be updated; = see idnits=20 report.
> >
> >
> > Appendix A., paragraph=20 2:
> >>   a given PCN-domain is dependant on the = nature=20 of the traffic
> > entering
> >
> = >  =20 Nit: s/dependant/dependent/
> >
> >=20 = <smime.p7s><ATT00001.txt>

____________________________= ___________________
PCN=20 mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn
______________________________________________= _
PCN=20 mailing list
PCN@ietf.org
https://www.ietf.org/m= ailman/listinfo/pcn
------_=_NextPart_001_01CA2163.7B0D18A8-- From toby.moncaster@bt.com Thu Aug 20 08:19:40 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D044B3A6A22 for ; Thu, 20 Aug 2009 08:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X96DJVwO2Kf for ; Thu, 20 Aug 2009 08:19:40 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id DAB213A6951 for ; Thu, 20 Aug 2009 08:19:37 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 16:19:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 20 Aug 2009 16:19:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-pcn-baseline-encoding-05 Thread-Index: AcohqVRCRkfjHFl+RP+teOdiDYI7HgAAAmoA From: To: , X-OriginalArrivalTime: 20 Aug 2009 15:19:42.0313 (UTC) FILETIME=[A44C3D90:01CA21A9] Subject: [PCN] FW: New Version Notification for draft-ietf-pcn-baseline-encoding-05 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, 20 Aug 2009 15:19:40 -0000 SSBob3BlIHRoaXMgYWNjdXJhdGVseSByZWZsZWN0cyB0aGUgTUwgZGlzY3Vzc2lvbnMgb3ZlciB0 aGUgcGFzdCBmZXcgZGF5cz8gSSBoYXZlIGFsc28gY29ycmVjdGVkIGFsbCB0aGUgbml0cyBhbmQg aG9wZWZ1bGx5IGhhdmVuJ3QgbGVmdCBhbnkgc3BlbGxpbmcgbWlzdGFrZXMgb3IgdHlwb3MuLi4N Cg0KVG9ieQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyANClRvYnkgTW9uY2FzdGVyLCA8dG9ieS5tb25jYXN0ZXJA YnQuY29tPiBOZXR3b3JrcyBSZXNlYXJjaCBDZW50cmUsIEJUIA0KQjU0LzcwIEFkYXN0cmFsIFBh cmssIElwc3dpY2gsIElQNTNSRSwgVUsuwqAgKzQ0IDc5MTggOTAxMTcwIA0KDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFp bHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50OiAyMCBBdWd1c3QgMjAwOSAxNjoxNw0K VG86IE1vbmNhc3RlcixULFRvYnksREVSMyBSDQpDYzogQnJpc2NvZSxSSixCb2IsREVSMyBSOyBt ZW50aEBpbmZvcm1hdGlrLnVuaS13dWVyemJ1cmcuZGUNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1wY24tYmFzZWxpbmUtZW5jb2RpbmctMDUgDQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtcGNuLWJhc2VsaW5lLWVuY29kaW5nLTA1 LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgVCBNb25jYXN0ZXIgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtcGNu LWJhc2VsaW5lLWVuY29kaW5nDQpSZXZpc2lvbjoJIDA1DQpUaXRsZToJCSBCYXNlbGluZSBFbmNv ZGluZyBhbmQgVHJhbnNwb3J0IG9mIFByZS1Db25nZXN0aW9uIEluZm9ybWF0aW9uDQpDcmVhdGlv bl9kYXRlOgkgMjAwOS0wOC0yMA0KV0cgSUQ6CQkgcGNuDQpOdW1iZXJfb2ZfcGFnZXM6IDE0DQoN CkFic3RyYWN0Og0KVGhlIG9iamVjdGl2ZSBvZiBQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24g KFBDTikgaXMgdG8gcHJvdGVjdCB0aGUNCnF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKSBvZiBpbmVs YXN0aWMgZmxvd3Mgd2l0aGluIGEgRGlmZnNlcnYgZG9tYWluLg0KVGhlIG92ZXJhbGwgcmF0ZSBv ZiB0aGUgUENOLXRyYWZmaWMgaXMgbWV0ZXJlZCBvbiBldmVyeSBsaW5rIGluIHRoZQ0KUENOLWRv bWFpbiwgYW5kIFBDTi1wYWNrZXRzIGFyZSBhcHByb3ByaWF0ZWx5IG1hcmtlZCB3aGVuIGNlcnRh aW4NCmNvbmZpZ3VyZWQgcmF0ZXMgYXJlIGV4Y2VlZGVkLiAgVGhlIGxldmVsIG9mIG1hcmtpbmcg YWxsb3dzIHRoZQ0KYm91bmRhcnkgbm9kZXMgdG8gbWFrZSBkZWNpc2lvbnMgYWJvdXQgd2hldGhl ciB0byBhZG1pdCBvciBibG9jayBhDQpuZXcgZmxvdyByZXF1ZXN0LCBhbmQgKGluIGFibm9ybWFs IGNpcmN1bXN0YW5jZXMpIHdoZXRoZXIgdG8NCnRlcm1pbmF0ZSBzb21lIG9mIHRoZSBleGlzdGlu ZyBmbG93cywgdGhlcmVieSBwcm90ZWN0aW5nIHRoZSBRb1Mgb2YNCnByZXZpb3VzbHkgYWRtaXR0 ZWQgZmxvd3MuICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgc3VjaCBtYXJrcw0KYXJlIHRv IGJlIGVuY29kZWQgaW50byB0aGUgSVAgaGVhZGVyIGJ5IHJlLXVzaW5nIHRoZSBFeHBsaWNpdA0K Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgY29kZXBvaW50cyB3aXRoaW4gdGhpcyBjb250 cm9sbGVkDQpkb21haW4uICBUaGUgYmFzZWxpbmUgZW5jb2RpbmcgZGVzY3JpYmVkIGhlcmUgcHJv dmlkZXMgZm9yIG9ubHkgdHdvDQpQQ04gZW5jb2Rpbmcgc3RhdGVzLCBOb3QtbWFya2VkIGFuZCBQ Q04tbWFya2VkLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0Lg0KDQoNCg== From root@core3.amsl.com Thu Aug 20 08:30:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8693C3A6D18; Thu, 20 Aug 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: <20090820153001.8693C3A6D18@core3.amsl.com> Date: Thu, 20 Aug 2009 08:30:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 15:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Baseline Encoding and Transport of Pre-Congestion Information Author(s) : T. Moncaster, et al. Filename : draft-ietf-pcn-baseline-encoding-05.txt Pages : 14 Date : 2009-08-20 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-baseline-encoding-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-20081717.I-D@ietf.org> --NextPart-- From philip.eardley@bt.com Thu Aug 20 09:37:00 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 D30873A6A4D for ; Thu, 20 Aug 2009 09:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 279ke-ia7f57 for ; Thu, 20 Aug 2009 09:36:59 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 629443A6D87 for ; Thu, 20 Aug 2009 09:36:59 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 17:37:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Aug 2009 17:37:00 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363777@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcohqVRCRkfjHFl+RP+teOdiDYI7HgAAAmoAAADq2EA= From: To: , , X-OriginalArrivalTime: 20 Aug 2009 16:37:00.0290 (UTC) FILETIME=[70BF5E20:01CA21B4] Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 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, 20 Aug 2009 16:37:00 -0000 Few minor comments: Table 1 has >EXP(01)* >Valid* [in IN EXP(01) OUT PM(11) box] > * This SHOULD cause an alarm to be raised at a higher layer. The packet MUST be treated as if it carried the NM codepoint. I think your comment ["*This SHOULD.."] really only applies to the = "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as = this shouldn't happen. Both the "Valid" boxes in this row could have a comment: ** these transitions MAY be allowed be some future experimental = extensions to the baseline encoding. However a PCN-node that hasn't be = upgraded (ie is still doing baseline) mustn't block this so it MUST = treat this transition as valid; it MAY also raise an alarm.=20 [Not sure " MAY also raise an alarm" is needed, since alarm already = raised since EXP(01) is the codepoint in] > alarm to be raised at a higher layer is 'higher layer' right? how about "management alarm"? > A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all packets it forwards out of the PCN-domain. The only exception to this is if the PCN-egress-node is certain that revealing other codepoints outside the PCN-domain won't contravene the guidance given in [RFC4774]. I wonder if this needs a bit more explanation about how to do this, or = where to find more guidance? 4.3.1 Co-existence of PCN and not-PCN traffic I wonder if it's worth adding pointer to S3.5 rfc5559 (or = draft-ietf-pcn-marking-behaviour Section B.1) which says >> It is not advised to have competing-non-PCN-traffic but, if there is such traffic, there needs to be a mechanism to limit it. "Competing-non-PCN-traffic" means traffic that shares a link with PCN-traffic and competes for its forwarding bandwidth. Hence, more competing-non-PCN-traffic results in poorer QoS for PCN. Further, the unpredictable amount of competing-non-PCN-traffic makes the PCN mechanisms less accurate and so reduces PCN's ability to protect the QoS of admitted PCN-flows. 5 > The 11 codepoint in the ECN field MUST indicate PCN-marked (though this does not exclude the 01 Experimental codepoint from carrying the same meaning). I think better would be " Experimental codepoint from also indicating = PCN-marking" [it would indicate a 2nd level of pcn-marking, which you = could say is not the "same" meaning] A.1 The approach & wording is basically good. >In PCN-domains with uniformly high link rates, the appropriate DSCPs would currently be those for the Real Time Traffic Class [RFC5127]. To be clear the PCN Working Group recommends using admission control for the following service classes: o Telephony (EF) o Real-time interactive (CS4) o Broadcast Video (CS3) o Multimedia Conferencing (AF4) I think "sufficient aggregation" would be better than "uniformly high = link rates" [similarly, "sufficiently" not "highly" in the next para] " Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at least = in Fig 2 you might want to say why CS5 is excluded from pcn (all the other dscps = in the RT treatement aggregate are included] rfc4594 needed as a ref somewhere here as that defines these dscps Typos etc Abstract >This document specifies how such marks are to be encoded delete 'to be' 4.0 >implementiors 4.2 > There are a number of factors that were considered before choosing to set 10 could have a new paragraph before this 4.3.0=20 > Thirdly PCN should be seen as being essentially a marking behaviour similar to ECN but intended for inelastic traffic. =20 Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it = should be seen as being essentially a marking behaviour similar to ECN = but intended for inelastic traffic. 6 > in decapsulation 'upon' better? 6 > If an operator wishes to allow ECN to exist end-to-end they must ensure there are no tunnel end-points within the PCN-domain to prevent any risk of PCN-markings being exposed to endpoints. Earlier in the paragraph you talk about a tunnel across the pcn-domain - = then there might be another tunnel wholly within the pcn-domain, and = this would be ok. (I know what you mean - perhaps slight re-ordering of = the para would do the trick) A.1 >PCn region PCN-domain Thanks phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { toby.moncaster@bt.com { Sent: 20 August 2009 16:19 { To: pcn@ietf.org; lars.eggert@nokia.com { Subject: [PCN] FW: New Version Notification = fordraft-ietf-pcn-baseline- { encoding-05 {=20 { I hope this accurately reflects the ML discussions over the past few = days? { I have also corrected all the nits and hopefully haven't left any = spelling { mistakes or typos... {=20 { Toby {=20 { ____________________________________________________________________ { Toby Moncaster, Networks Research Centre, BT { B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170 {=20 {=20 {=20 { -----Original Message----- { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] { Sent: 20 August 2009 16:17 { To: Moncaster,T,Toby,DER3 R { Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de { Subject: New Version Notification for = draft-ietf-pcn-baseline-encoding-05 {=20 {=20 { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been { successfuly submitted by T Moncaster and posted to the IETF = repository. {=20 { Filename: draft-ietf-pcn-baseline-encoding { Revision: 05 { Title: Baseline Encoding and Transport of Pre-Congestion { Information { Creation_date: 2009-08-20 { WG ID: pcn { Number_of_pages: 14 {=20 { Abstract: { The objective of Pre-Congestion Notification (PCN) is to protect the { quality of service (QoS) of inelastic flows within a Diffserv domain. { The overall rate of the PCN-traffic is metered on every link in the { PCN-domain, and PCN-packets are appropriately marked when certain { configured rates are exceeded. The level of marking allows the { boundary nodes to make decisions about whether to admit or block a { new flow request, and (in abnormal circumstances) whether to { terminate some of the existing flows, thereby protecting the QoS of { previously admitted flows. This document specifies how such marks { are to be encoded into the IP header by re-using the Explicit { Congestion Notification (ECN) codepoints within this controlled { domain. The baseline encoding described here provides for only two { PCN encoding states, Not-marked and PCN-marked. {=20 {=20 {=20 { The IETF Secretariat. {=20 {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From wwwrun@core3.amsl.com Thu Aug 20 10:45:51 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 E890A3A6951; Thu, 20 Aug 2009 10:45:51 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090820174551.E890A3A6951@core3.amsl.com> Date: Thu, 20 Aug 2009 10:45:51 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] Last Call: draft-ietf-pcn-baseline-encoding (Baseline Encoding and Transport of Pre-Congestion Information) 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, 20 Aug 2009 17:45:52 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'Baseline Encoding and Transport of Pre-Congestion Information ' 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-09-03. 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-baseline-encoding-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17737&rfc_flag=0 From slblake@petri-meat.com Thu Aug 20 19:39:43 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801D33A6B46 for ; Thu, 20 Aug 2009 19:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTOh2CEJXkep for ; Thu, 20 Aug 2009 19:39:42 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id CDC5D3A659A for ; Thu, 20 Aug 2009 19:39:42 -0700 (PDT) Received: from cpe-071-065-229-025.nc.res.rr.com ([71.65.229.25]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MeK2c-0001AW-22 for pcn@ietf.org; Thu, 20 Aug 2009 22:39:46 -0400 From: Steven Blake To: pcn@ietf.org In-Reply-To: <8376254de9eef3a0e2f2156e887a5b37@petri-meat.com> References: <8376254de9eef3a0e2f2156e887a5b37@petri-meat.com> Content-Type: text/plain Date: Thu, 20 Aug 2009 22:39:45 -0400 Message-Id: <1250822385.2969.13.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.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 Subject: Re: [PCN] IETF 75 meeting draft minutes 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, 21 Aug 2009 02:39:43 -0000 On Sat, 2009-08-01 at 23:35 -0400, slblake@petri-meat.com wrote: > I've uploaded the draft meeting minutes to: > http://www.ietf.org/proceedings/75/minutes/pcn.txt > > Please review and send comments/corrections to the list. Thanks to Andrew > for volunteering to be minute taker! As there were no proposed changes, I finalized the meeting minutes as is. Regards, // Steve From Ruediger.Geib@telekom.de Thu Aug 20 23:48:32 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 4672F3A6A74 for ; Thu, 20 Aug 2009 23:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQFtheybYXQm for ; Thu, 20 Aug 2009 23:48:31 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id EF44F3A6D8F for ; Thu, 20 Aug 2009 23:48:30 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 21 Aug 2009 08:48:30 +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); Fri, 21 Aug 2009 08:48:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 08:48:27 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501E99D41@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcohqVRCRkfjHFl+RP+teOdiDYI7HgAAAmoAAB/sDPA= References: From: To: , , X-OriginalArrivalTime: 21 Aug 2009 06:48:30.0058 (UTC) FILETIME=[649F4CA0:01CA222B] Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 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, 21 Aug 2009 06:48:32 -0000 I've read A1 only and think this text is allright from what it intends = to say.=20 Phil had some comments, one of which was related to CS5. While I'm aware = of EF=20 and some AF codepoints to be commercially deployed, I'd have to study my = archived material to see, whether any of the class/codepoint schemes = I've seen=20 uses CS5 on IP level.=20 But I don't fundamentally object to adding CS5 to the A1 list of = recommended=20 DSCP's (as I only know a few class/codepoint concepts). Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = toby.moncaster@bt.com Sent: Thursday, August 20, 2009 5:19 PM To: pcn@ietf.org; lars.eggert@nokia.com Subject: [PCN] FW: New Version Notification = fordraft-ietf-pcn-baseline-encoding-05 I hope this accurately reflects the ML discussions over the past few = days? I have also corrected all the nits and hopefully haven't left any = spelling mistakes or typos... Toby ____________________________________________________________________=20 Toby Moncaster, Networks Research Centre, BT=20 B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170=20 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 20 August 2009 16:17 To: Moncaster,T,Toby,DER3 R Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de Subject: New Version Notification for = draft-ietf-pcn-baseline-encoding-05=20 A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been = successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-ietf-pcn-baseline-encoding Revision: 05 Title: Baseline Encoding and Transport of Pre-Congestion Information Creation_date: 2009-08-20 WG ID: pcn Number_of_pages: 14 Abstract: The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked. = =20 The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Fri Aug 21 00:49:29 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 494E13A6A03 for ; Fri, 21 Aug 2009 00:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJFj3SpqyvdJ for ; Fri, 21 Aug 2009 00:49:28 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 4850D3A6B0D for ; Fri, 21 Aug 2009 00:49:12 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 08:49:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 08:49:15 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0636377A@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <151C164FE2E066418D8D44D0801543A501E99D41@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notificationfordraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcohqVRCRkfjHFl+RP+teOdiDYI7HgAAAmoAAB/sDPAAApc5kA== From: To: , , , X-OriginalArrivalTime: 21 Aug 2009 07:49:15.0906 (UTC) FILETIME=[E1B78E20:01CA2233] Subject: Re: [PCN] FW: New Version Notificationfordraft-ietf-pcn-baseline-encoding-05 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, 21 Aug 2009 07:49:29 -0000 Hi ruediger I'm not sure that cs5 should be added - it's signalling, and adm ctrl = should I think be for the data part not for the couple of signalling = msgs.=20 I was just saying that this was the one RT traffic aggregate dscp not = included and that was worth a quick explanation. { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Ruediger.Geib@telekom.de { Sent: 21 August 2009 07:48 { To: Moncaster,T,Toby,DER3 R; pcn@ietf.org; lars.eggert@nokia.com { Subject: Re: [PCN] FW: New Version = Notificationfordraft-ietf-pcn-baseline- { encoding-05 {=20 { I've read A1 only and think this text is allright from what it intends = to { say. {=20 { Phil had some comments, one of which was related to CS5. While I'm = aware { of EF { and some AF codepoints to be commercially deployed, I'd have to study = my { archived material to see, whether any of the class/codepoint schemes = I've { seen { uses CS5 on IP level. {=20 { But I don't fundamentally object to adding CS5 to the A1 list of { recommended { DSCP's (as I only know a few class/codepoint concepts). {=20 { Regards, {=20 { Ruediger {=20 { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { toby.moncaster@bt.com { Sent: Thursday, August 20, 2009 5:19 PM { To: pcn@ietf.org; lars.eggert@nokia.com { Subject: [PCN] FW: New Version Notification = fordraft-ietf-pcn-baseline- { encoding-05 {=20 { I hope this accurately reflects the ML discussions over the past few = days? { I have also corrected all the nits and hopefully haven't left any = spelling { mistakes or typos... {=20 { Toby {=20 { ____________________________________________________________________ { Toby Moncaster, Networks Research Centre, BT { B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170 {=20 {=20 {=20 { -----Original Message----- { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] { Sent: 20 August 2009 16:17 { To: Moncaster,T,Toby,DER3 R { Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de { Subject: New Version Notification for = draft-ietf-pcn-baseline-encoding-05 {=20 {=20 { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been { successfuly submitted by T Moncaster and posted to the IETF = repository. {=20 { Filename: draft-ietf-pcn-baseline-encoding { Revision: 05 { Title: Baseline Encoding and Transport of Pre-Congestion { Information { Creation_date: 2009-08-20 { WG ID: pcn { Number_of_pages: 14 {=20 { Abstract: { The objective of Pre-Congestion Notification (PCN) is to protect the { quality of service (QoS) of inelastic flows within a Diffserv domain. { The overall rate of the PCN-traffic is metered on every link in the { PCN-domain, and PCN-packets are appropriately marked when certain { configured rates are exceeded. The level of marking allows the { boundary nodes to make decisions about whether to admit or block a { new flow request, and (in abnormal circumstances) whether to { terminate some of the existing flows, thereby protecting the QoS of { previously admitted flows. This document specifies how such marks { are to be encoded into the IP header by re-using the Explicit { Congestion Notification (ECN) codepoints within this controlled { domain. The baseline encoding described here provides for only two { PCN encoding states, Not-marked and PCN-marked. {=20 {=20 {=20 { The IETF Secretariat. {=20 {=20 { _______________________________________________ { 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 Fri Aug 21 01:02: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 86B6F3A68EB for ; Fri, 21 Aug 2009 01:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZwjtLMtPcWJ for ; Fri, 21 Aug 2009 01:02:54 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 31A3E3A67F6 for ; Fri, 21 Aug 2009 01:02:54 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 21 Aug 2009 10:02:33 +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); Fri, 21 Aug 2009 10:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 10:02:32 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501E99E6F@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0636377A@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notificationfordraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcohqVRCRkfjHFl+RP+teOdiDYI7HgAAAmoAAB/sDPAAApc5kAAAKy+g References: <151C164FE2E066418D8D44D0801543A501E99D41@S4DE8PSAAQA.mitte.t-com.de> <4A916DBC72536E419A0BD955EDECEDEC0636377A@E03MVB1-UKBR.domain1.systemhost.net> From: To: X-OriginalArrivalTime: 21 Aug 2009 08:02:33.0183 (UTC) FILETIME=[BCEE5EF0:01CA2235] Cc: pcn@ietf.org Subject: Re: [PCN] FW: New Version Notificationfordraft-ietf-pcn-baseline-encoding-05 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, 21 Aug 2009 08:02:55 -0000 Hi Phil, I agree, signalling doesn't need PCN.=20 Regards, Ruediger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Friday, August 21, 2009 9:49 AM To: Geib, R=FCdiger; toby.moncaster@bt.com; pcn@ietf.org; = lars.eggert@nokia.com Subject: RE: [PCN] FW: New Version = Notificationfordraft-ietf-pcn-baseline-encoding-05 Hi ruediger I'm not sure that cs5 should be added - it's signalling, and adm ctrl = should I think be for the data part not for the couple of signalling = msgs.=20 I was just saying that this was the one RT traffic aggregate dscp not = included and that was worth a quick explanation. { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Ruediger.Geib@telekom.de { Sent: 21 August 2009 07:48 { To: Moncaster,T,Toby,DER3 R; pcn@ietf.org; lars.eggert@nokia.com { Subject: Re: [PCN] FW: New Version = Notificationfordraft-ietf-pcn-baseline- { encoding-05 {=20 { I've read A1 only and think this text is allright from what it intends = to { say. {=20 { Phil had some comments, one of which was related to CS5. While I'm = aware { of EF { and some AF codepoints to be commercially deployed, I'd have to study = my { archived material to see, whether any of the class/codepoint schemes = I've { seen { uses CS5 on IP level. {=20 { But I don't fundamentally object to adding CS5 to the A1 list of { recommended { DSCP's (as I only know a few class/codepoint concepts). {=20 { Regards, {=20 { Ruediger {=20 { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { toby.moncaster@bt.com { Sent: Thursday, August 20, 2009 5:19 PM { To: pcn@ietf.org; lars.eggert@nokia.com { Subject: [PCN] FW: New Version Notification = fordraft-ietf-pcn-baseline- { encoding-05 {=20 { I hope this accurately reflects the ML discussions over the past few = days? { I have also corrected all the nits and hopefully haven't left any = spelling { mistakes or typos... {=20 { Toby {=20 { ____________________________________________________________________ { Toby Moncaster, Networks Research Centre, BT { B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170 {=20 {=20 {=20 { -----Original Message----- { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] { Sent: 20 August 2009 16:17 { To: Moncaster,T,Toby,DER3 R { Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de { Subject: New Version Notification for = draft-ietf-pcn-baseline-encoding-05 {=20 {=20 { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been { successfuly submitted by T Moncaster and posted to the IETF = repository. {=20 { Filename: draft-ietf-pcn-baseline-encoding { Revision: 05 { Title: Baseline Encoding and Transport of Pre-Congestion { Information { Creation_date: 2009-08-20 { WG ID: pcn { Number_of_pages: 14 {=20 { Abstract: { The objective of Pre-Congestion Notification (PCN) is to protect the { quality of service (QoS) of inelastic flows within a Diffserv domain. { The overall rate of the PCN-traffic is metered on every link in the { PCN-domain, and PCN-packets are appropriately marked when certain { configured rates are exceeded. The level of marking allows the { boundary nodes to make decisions about whether to admit or block a { new flow request, and (in abnormal circumstances) whether to { terminate some of the existing flows, thereby protecting the QoS of { previously admitted flows. This document specifies how such marks { are to be encoded into the IP header by re-using the Explicit { Congestion Notification (ECN) codepoints within this controlled { domain. The baseline encoding described here provides for only two { PCN encoding states, Not-marked and PCN-marked. {=20 {=20 {=20 { The IETF Secretariat. {=20 {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From toby.moncaster@bt.com Fri Aug 21 01:25: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 7957F3A6801 for ; Fri, 21 Aug 2009 01:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idkG3UUfonnH for ; Fri, 21 Aug 2009 01:25:48 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id AC6CB3A6884 for ; Fri, 21 Aug 2009 01:25:47 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 09:25:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 09:24:57 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363777@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcohqVRCRkfjHFl+RP+teOdiDYI7HgAAAmoAAADq2EAAIn7HQA== References: <4A916DBC72536E419A0BD955EDECEDEC06363777@E03MVB1-UKBR.domain1.systemhost.net> From: To: , , X-OriginalArrivalTime: 21 Aug 2009 08:25:52.0086 (UTC) FILETIME=[FEBE0760:01CA2238] Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 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, 21 Aug 2009 08:25:50 -0000 Hi Phil, Thanks for the comments. I will try and incorporate all of them into the = (hopefully) final version after the IETF LC ends in 2 weeks time. More inline > -----Original Message----- > From: Eardley,PL,Philip,DER3 R > Sent: 20 August 2009 17:37 > To: Moncaster,T,Toby,DER3 R; pcn@ietf.org; lars.eggert@nokia.com > Subject: RE: [PCN] FW: New Version Notification fordraft-ietf-pcn- > baseline-encoding-05 >=20 > Few minor comments: >=20 > Table 1 has > >EXP(01)* > >Valid* [in IN EXP(01) OUT PM(11) box] > > * This SHOULD cause an alarm to be raised at a higher layer. The > packet MUST be treated as if it carried the NM codepoint. >=20 > I think your comment ["*This SHOULD.."] really only applies to the > "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as > this shouldn't happen. I think that is what I meant, yes. I will have a look at re-jigging the = table to clarify >=20 > Both the "Valid" boxes in this row could have a comment: > ** these transitions MAY be allowed be some future experimental > extensions to the baseline encoding. However a PCN-node that hasn't be > upgraded (ie is still doing baseline) mustn't block this so it MUST > treat this transition as valid; it MAY also raise an alarm. > [Not sure " MAY also raise an alarm" is needed, since alarm already > raised since EXP(01) is the codepoint in] Or something about "In order not to block future extensions from using = these transitions..."? I will try and sort something out >=20 > > alarm to be raised at a higher layer > is 'higher layer' right? how about "management alarm"? Yep, by higher layer I meant control or management layer >=20 >=20 > > A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all > packets it forwards out of the PCN-domain. The only exception to > this is if the PCN-egress-node is certain that revealing other > codepoints outside the PCN-domain won't contravene the guidance > given > in [RFC4774]. > I wonder if this needs a bit more explanation about how to do this, or > where to find more guidance? Would an example count as guidance? "For example where the = PCN-egress-node has been explicitly informed by the PCN-ingress-node = that this flow is ECN-capable" In terms of where to find guidance, = currently only in experimental schemes (I think) >=20 > 4.3.1 > Co-existence of PCN and not-PCN traffic > I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft-ietf- > pcn-marking-behaviour Section B.1) which says > >> It is not advised to have competing-non-PCN-traffic but, if there > is such traffic, there needs to be a mechanism to limit it. > "Competing-non-PCN-traffic" means traffic that shares a link = with > PCN-traffic and competes for its forwarding bandwidth. Hence, > more competing-non-PCN-traffic results in poorer QoS for PCN. > Further, the unpredictable amount of competing-non-PCN-traffic > makes the PCN mechanisms less accurate and so reduces PCN's > ability to protect the QoS of admitted PCN-flows. >=20 Yep, will do > 5 > > The 11 codepoint in the ECN field MUST indicate PCN-marked (though > this does not exclude the 01 Experimental codepoint from = carrying > the same meaning). > I think better would be " Experimental codepoint from also indicating > PCN-marking" [it would indicate a 2nd level of pcn-marking, which you > could say is not the "same" meaning] But I define PCN-marked as having the meaning "...codepoint indicating = packets that have been marked at a PCN-interior-node using some PCN = marking behaviour..." Which is the same regardless of the relative level = of each of those marks! However I am happy to be explicit and say EXP is = not excluded from meaning PCN-marked >=20 > A.1 > The approach & wording is basically good. > >In PCN-domains with uniformly high link rates, the > appropriate DSCPs would currently be those for the Real Time = Traffic > Class [RFC5127]. To be clear the PCN Working Group recommends = using > admission control for the following service classes: >=20 > o Telephony (EF) >=20 > o Real-time interactive (CS4) >=20 > o Broadcast Video (CS3) >=20 > o Multimedia Conferencing (AF4) >=20 > I think "sufficient aggregation" would be better than "uniformly high > link rates" [similarly, "sufficiently" not "highly" in the next para] Yep > " Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at > least in Fig 2 > you might want to say why CS5 is excluded from pcn (all the other = dscps > in the RT treatement aggregate are included] > rfc4594 needed as a ref somewhere here as that defines these dscps Will just put "CS5 is excluded since PCN is not expected to be applied = to signalling traffic". However that does raise an interesting question = with regards to Michael's proposed approach of using admission marking = on RSVP PATH messages in PSDM as I would count those as signalling = traffic? >=20 >=20 > Typos etc > Abstract > >This document specifies how such marks are to be encoded > delete 'to be' OK >=20 > 4.0 >implementiors Already spotted... >=20 > 4.2 > > There are a number of factors that > were considered before choosing to set 10 > could have a new paragraph before this >=20 OK > 4.3.0 > > Thirdly PCN > should be seen as being essentially a marking behaviour similar to > ECN but intended for inelastic traffic. > Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it > should be seen as being essentially a marking behaviour similar to ECN > but intended for inelastic traffic. >=20 OK > 6 > > in decapsulation > 'upon' better? >=20 Will decide > 6 > > If an > operator wishes to allow ECN to exist end-to-end they must ensure > there are no tunnel end-points within the PCN-domain to prevent any > risk of PCN-markings being exposed to endpoints. > Earlier in the paragraph you talk about a tunnel across the pcn-domain > - then there might be another tunnel wholly within the pcn-domain, and > this would be ok. (I know what you mean - perhaps slight re-ordering = of > the para would do the trick) Will have a think about whether I can word this any better... >=20 > A.1 > >PCn region > PCN-domain >=20 Oops! > Thanks > phil >=20 > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of > { toby.moncaster@bt.com > { Sent: 20 August 2009 16:19 > { To: pcn@ietf.org; lars.eggert@nokia.com > { Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn- > baseline- > { encoding-05 > { > { I hope this accurately reflects the ML discussions over the past few > days? > { I have also corrected all the nits and hopefully haven't left any > spelling > { mistakes or typos... > { > { Toby > { > { ____________________________________________________________________ > { Toby Moncaster, Networks Research Centre, BT > { B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170 > { > { > { > { -----Original Message----- > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > { Sent: 20 August 2009 16:17 > { To: Moncaster,T,Toby,DER3 R > { Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de > { Subject: New Version Notification for draft-ietf-pcn-baseline- > encoding-05 > { > { > { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has > been > { successfuly submitted by T Moncaster and posted to the IETF > repository. > { > { Filename: draft-ietf-pcn-baseline-encoding > { Revision: 05 > { Title: Baseline Encoding and Transport of Pre-Congestion > { Information > { Creation_date: 2009-08-20 > { WG ID: pcn > { Number_of_pages: 14 > { > { Abstract: > { The objective of Pre-Congestion Notification (PCN) is to protect the > { quality of service (QoS) of inelastic flows within a Diffserv = domain. > { The overall rate of the PCN-traffic is metered on every link in the > { PCN-domain, and PCN-packets are appropriately marked when certain > { configured rates are exceeded. The level of marking allows the > { boundary nodes to make decisions about whether to admit or block a > { new flow request, and (in abnormal circumstances) whether to > { terminate some of the existing flows, thereby protecting the QoS of > { previously admitted flows. This document specifies how such marks > { are to be encoded into the IP header by re-using the Explicit > { Congestion Notification (ECN) codepoints within this controlled > { domain. The baseline encoding described here provides for only two > { PCN encoding states, Not-marked and PCN-marked. > { > { > { > { The IETF Secretariat. > { > { > { _______________________________________________ > { PCN mailing list > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn From rbriscoe@jungle.bt.co.uk Fri Aug 21 03:45: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 B1F563A67F2 for ; Fri, 21 Aug 2009 03:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 diSGSs-CZmzJ for ; Fri, 21 Aug 2009 03:45:26 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id C75653A681D for ; Fri, 21 Aug 2009 03:45:25 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 11:45:30 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 11:45:30 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1250851529278; Fri, 21 Aug 2009 11:45:29 +0100 Received: from BTG127939.jungle.bt.co.uk ([10.215.130.227]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n7LAjPkO012716; Fri, 21 Aug 2009 11:45:25 +0100 Message-Id: <200908211045.n7LAjPkO012716@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Aug 2009 11:45:06 +0100 To: , , , From: Bob Briscoe In-Reply-To: References: <4A916DBC72536E419A0BD955EDECEDEC06363777@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Aug 2009 10:45:30.0664 (UTC) FILETIME=[80C39280:01CA224C] Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 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, 21 Aug 2009 10:45:33 -0000 Toby, I just re-reviewed -05 as a whole and my list of comments included every single one of Phil's comments (even tho I hadn't read his email first). == S.4.1. para 2 == " The only valid codepoint transitions within a PCN-interior-node are ... and from EXP to PM (which MAY be allowed by some future experimental extensions)." Delete parenthesis and add: PCN nodes that only implement the baseline encoding MUST be able to PCN mark packets that arrive with the EXP codepoint. This should ease the design of experimental schemes that want to allow partial deployment of experimental nodes alongside nodes that only implement the baseline encoding. The codepoint transition constraints given here apply only to the baseline encoding scheme. Constraints on codepoint transitions for future experimental scheme are discussed in S.5. == Table 2. == s/* This SHOULD cause an alarm/ /* This MAY cause an alarm/ == S.6. last sentence == " If an operator wishes to allow ECN to exist end-to-end they must ensure there are no tunnel end-points within the PCN-domain to prevent any risk of PCN-markings being exposed to endpoints. " Rather than ruling out tunnel endpoints, I suggest you refer to the tunnel guidelines in RFC5559, which lays down the conditions under which tunnel endpoints can be used (i.e. the tunnel endpoint must act as an appropriate PCN edge node). Nits: == S.4.3 last line == s/appendix Appendix/Appendix/ == S.5. == s/a packet within a PCN-compatible Diffserv Codepoint /a packet with a PCN-compatible Diffserv Codepoint/ === 5th bullet === " o Any experimental scheme MUST NOT update the meaning of the 00 and 11 codepoints defined above. " Same problem here as Phil pointed out for the 2nd bullet. An experimental scheme will probably refine the meaning of the 11 codepoint (which would update the meaning contrary to the literal interpretation of this rule). == S.6. == s/Standard IP-in-IP or IPsec tunnels/ /RFC3168 IP-in-IP or RFC4301 IPsec tunnels/ == S.8. 1st para == " PCN-marking only carries a meaning within the confines of a PCN- domain. Packets wishing to be treated as belonging to a PCN-flow must carry a PCN-compatible DSCP and a PCN-Enabled ECN codepoint. This encoding document is intended to stand independently of the architecture used to determine how specific packets are authorised to be PCN-marked, which will be described in separate documents on PCN- boundary-node behaviour. " Delete the middle (2nd) sentence, which could be read as implying that packets arriving at the PCN ingress have to already carry a PCN-compatible DSCP and a PCN-Enabled ECN codepoint. == Repetitions that read OK, but may not have been intended == 2nd sentence of S.4.1. repeats the last bullet of the preceding section (but they are both relevant in their respective sections). Opening sentences of A.1 repeat 3rd para of S.4.3. HTH Bob At 09:24 21/08/2009, toby.moncaster@bt.com wrote: >Hi Phil, > >Thanks for the comments. I will try and incorporate all of them into >the (hopefully) final version after the IETF LC ends in 2 weeks time. > >More inline > > > -----Original Message----- > > From: Eardley,PL,Philip,DER3 R > > Sent: 20 August 2009 17:37 > > To: Moncaster,T,Toby,DER3 R; pcn@ietf.org; lars.eggert@nokia.com > > Subject: RE: [PCN] FW: New Version Notification fordraft-ietf-pcn- > > baseline-encoding-05 > > > > Few minor comments: > > > > Table 1 has > > >EXP(01)* > > >Valid* [in IN EXP(01) OUT PM(11) box] > > > * This SHOULD cause an alarm to be raised at a higher layer. The > > packet MUST be treated as if it carried the NM codepoint. > > > > I think your comment ["*This SHOULD.."] really only applies to the > > "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as > > this shouldn't happen. > >I think that is what I meant, yes. I will have a look at re-jigging >the table to clarify > > > > > > Both the "Valid" boxes in this row could have a comment: > > ** these transitions MAY be allowed be some future experimental > > extensions to the baseline encoding. However a PCN-node that hasn't be > > upgraded (ie is still doing baseline) mustn't block this so it MUST > > treat this transition as valid; it MAY also raise an alarm. > > [Not sure " MAY also raise an alarm" is needed, since alarm already > > raised since EXP(01) is the codepoint in] > >Or something about "In order not to block future extensions from >using these transitions..."? I will try and sort something out > > > > > > > alarm to be raised at a higher layer > > is 'higher layer' right? how about "management alarm"? > >Yep, by higher layer I meant control or management layer > > > > > > > > A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all > > packets it forwards out of the PCN-domain. The only exception to > > this is if the PCN-egress-node is certain that revealing other > > codepoints outside the PCN-domain won't contravene the guidance > > given > > in [RFC4774]. > > I wonder if this needs a bit more explanation about how to do this, or > > where to find more guidance? > >Would an example count as guidance? "For example where the >PCN-egress-node has been explicitly informed by the PCN-ingress-node >that this flow is ECN-capable" In terms of where to find guidance, >currently only in experimental schemes (I think) > > > > > 4.3.1 > > Co-existence of PCN and not-PCN traffic > > I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft-ietf- > > pcn-marking-behaviour Section B.1) which says > > >> It is not advised to have competing-non-PCN-traffic but, if there > > is such traffic, there needs to be a mechanism to limit it. > > "Competing-non-PCN-traffic" means traffic that shares a link with > > PCN-traffic and competes for its forwarding bandwidth. Hence, > > more competing-non-PCN-traffic results in poorer QoS for PCN. > > Further, the unpredictable amount of competing-non-PCN-traffic > > makes the PCN mechanisms less accurate and so reduces PCN's > > ability to protect the QoS of admitted PCN-flows. > > > >Yep, will do > > > 5 > > > The 11 codepoint in the ECN field MUST indicate PCN-marked (though > > this does not exclude the 01 Experimental codepoint from carrying > > the same meaning). > > I think better would be " Experimental codepoint from also indicating > > PCN-marking" [it would indicate a 2nd level of pcn-marking, which you > > could say is not the "same" meaning] > >But I define PCN-marked as having the meaning "...codepoint >indicating packets that have been marked at a PCN-interior-node >using some PCN marking behaviour..." Which is the same regardless of >the relative level of each of those marks! However I am happy to be >explicit and say EXP is not excluded from meaning PCN-marked > > > > > A.1 > > The approach & wording is basically good. > > >In PCN-domains with uniformly high link rates, the > > appropriate DSCPs would currently be those for the Real Time Traffic > > Class [RFC5127]. To be clear the PCN Working Group recommends using > > admission control for the following service classes: > > > > o Telephony (EF) > > > > o Real-time interactive (CS4) > > > > o Broadcast Video (CS3) > > > > o Multimedia Conferencing (AF4) > > > > I think "sufficient aggregation" would be better than "uniformly high > > link rates" [similarly, "sufficiently" not "highly" in the next para] > >Yep > > > " Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at > > least in Fig 2 > > you might want to say why CS5 is excluded from pcn (all the other dscps > > in the RT treatement aggregate are included] > > rfc4594 needed as a ref somewhere here as that defines these dscps > >Will just put "CS5 is excluded since PCN is not expected to be >applied to signalling traffic". However that does raise an >interesting question with regards to Michael's proposed approach of >using admission marking on RSVP PATH messages in PSDM as I would >count those as signalling traffic? > > > > > > > Typos etc > > Abstract > > >This document specifies how such marks are to be encoded > > delete 'to be' > >OK > > > > > 4.0 >implementiors > >Already spotted... > > > > > 4.2 > > > There are a number of factors that > > were considered before choosing to set 10 > > could have a new paragraph before this > > >OK > > > 4.3.0 > > > Thirdly PCN > > should be seen as being essentially a marking behaviour similar to > > ECN but intended for inelastic traffic. > > Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it > > should be seen as being essentially a marking behaviour similar to ECN > > but intended for inelastic traffic. > > >OK > > > 6 > > > in decapsulation > > 'upon' better? > > >Will decide > > > 6 > > > If an > > operator wishes to allow ECN to exist end-to-end they must ensure > > there are no tunnel end-points within the PCN-domain to prevent any > > risk of PCN-markings being exposed to endpoints. > > Earlier in the paragraph you talk about a tunnel across the pcn-domain > > - then there might be another tunnel wholly within the pcn-domain, and > > this would be ok. (I know what you mean - perhaps slight re-ordering of > > the para would do the trick) >Will have a think about whether I can word this any better... > > > > > A.1 > > >PCn region > > PCN-domain > > >Oops! > > > Thanks > > phil > > > > { -----Original Message----- > > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > { toby.moncaster@bt.com > > { Sent: 20 August 2009 16:19 > > { To: pcn@ietf.org; lars.eggert@nokia.com > > { Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn- > > baseline- > > { encoding-05 > > { > > { I hope this accurately reflects the ML discussions over the past few > > days? > > { I have also corrected all the nits and hopefully haven't left any > > spelling > > { mistakes or typos... > > { > > { Toby > > { > > { ____________________________________________________________________ > > { Toby Moncaster, Networks Research Centre, BT > > { B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 7918 901170 > > { > > { > > { > > { -----Original Message----- > > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > { Sent: 20 August 2009 16:17 > > { To: Moncaster,T,Toby,DER3 R > > { Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de > > { Subject: New Version Notification for draft-ietf-pcn-baseline- > > encoding-05 > > { > > { > > { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has > > been > > { successfuly submitted by T Moncaster and posted to the IETF > > repository. > > { > > { Filename: draft-ietf-pcn-baseline-encoding > > { Revision: 05 > > { Title: Baseline Encoding and Transport of Pre-Congestion > > { Information > > { Creation_date: 2009-08-20 > > { WG ID: pcn > > { Number_of_pages: 14 > > { > > { Abstract: > > { The objective of Pre-Congestion Notification (PCN) is to protect the > > { quality of service (QoS) of inelastic flows within a Diffserv domain. > > { The overall rate of the PCN-traffic is metered on every link in the > > { PCN-domain, and PCN-packets are appropriately marked when certain > > { configured rates are exceeded. The level of marking allows the > > { boundary nodes to make decisions about whether to admit or block a > > { new flow request, and (in abnormal circumstances) whether to > > { terminate some of the existing flows, thereby protecting the QoS of > > { previously admitted flows. This document specifies how such marks > > { are to be encoded into the IP header by re-using the Explicit > > { Congestion Notification (ECN) codepoints within this controlled > > { domain. The baseline encoding described here provides for only two > > { PCN encoding states, Not-marked and PCN-marked. > > { > > { > > { > > { The IETF Secretariat. > > { > > { > > { _______________________________________________ > > { PCN mailing list > > { PCN@ietf.org > > { https://www.ietf.org/mailman/listinfo/pcn >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From toby.moncaster@bt.com Fri Aug 21 04:02:44 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 670273A6DBD for ; Fri, 21 Aug 2009 04:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZvhpMs2Hs6f for ; Fri, 21 Aug 2009 04:02:43 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 657833A681D for ; Fri, 21 Aug 2009 04:02:42 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 12:02:46 +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, 21 Aug 2009 12:01:50 +0100 Message-ID: In-Reply-To: <200908211045.n7LAjPkO012716@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcoiTIDyLJIjdgOsRNqm328wyDIM2AAAbcpA References: <4A916DBC72536E419A0BD955EDECEDEC06363777@E03MVB1-UKBR.domain1.systemhost.net> <200908211045.n7LAjPkO012716@bagheera.jungle.bt.co.uk> From: To: , , , X-OriginalArrivalTime: 21 Aug 2009 11:02:46.0260 (UTC) FILETIME=[EA06FB40:01CA224E] Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05 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, 21 Aug 2009 11:02:44 -0000 Thanks, I will add these to the other corrections/comments...=20 1 inline response > -----Original Message----- > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R > Sent: 21 August 2009 11:45 > To: Moncaster,T,Toby,DER3 R; Eardley,PL,Philip,DER3 R; pcn@ietf.org; > lars.eggert@nokia.com > Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn- > baseline-encoding-05 >=20 > Toby, >=20 > I just re-reviewed -05 as a whole and my list of comments included > every single one of Phil's comments (even tho I hadn't read his email > first). >=20 > =3D=3D S.4.1. para 2 =3D=3D > " The only valid codepoint transitions within a PCN-interior-node are > ... and from EXP to > PM (which MAY be allowed by some future experimental extensions)." >=20 > Delete parenthesis and add: >=20 > PCN nodes that only implement the baseline encoding MUST be able to > PCN mark packets that arrive with the EXP codepoint. This should ease > the design of experimental schemes that want to allow partial > deployment of experimental nodes alongside nodes that only implement > the baseline encoding. >=20 > The codepoint transition constraints given here apply only to the > baseline encoding scheme. Constraints on codepoint transitions for > future experimental scheme are discussed in S.5. >=20 > =3D=3D Table 2. =3D=3D > s/* This SHOULD cause an alarm/ > /* This MAY cause an alarm/ >=20 > =3D=3D S.6. last sentence =3D=3D > " If an > operator wishes to allow ECN to exist end-to-end they must ensure > there are no tunnel end-points within the PCN-domain to prevent any > risk of PCN-markings being exposed to endpoints. > " > Rather than ruling out tunnel endpoints, I suggest you refer to the > tunnel guidelines in RFC5559, which lays down the conditions under > which tunnel endpoints can be used (i.e. the tunnel endpoint must act > as an appropriate PCN edge node). >=20 > Nits: > =3D=3D S.4.3 last line =3D=3D > s/appendix Appendix/Appendix/ >=20 > =3D=3D S.5. =3D=3D > s/a packet within a PCN-compatible Diffserv Codepoint > /a packet with a PCN-compatible Diffserv Codepoint/ >=20 > =3D=3D=3D 5th bullet =3D=3D=3D > " o Any experimental scheme MUST NOT update the meaning of the 00 and > 11 codepoints defined above. > " > Same problem here as Phil pointed out for the 2nd bullet. An > experimental scheme will probably refine the meaning of the 11 > codepoint (which would update the meaning contrary to the literal > interpretation of this rule). My response here is the same as my response to Phil's comment - this document defines 11 as meaning PCN-marked. PCN-marked is defined as having been marked as a result of a PCN-marking function - it doesn't specify which sort of mark this is. In the context of the baseline encoding, any experimental scheme also needs to ensure that 11 means PCN-marked... >=20 > =3D=3D S.6. =3D=3D > s/Standard IP-in-IP or IPsec tunnels/ > /RFC3168 IP-in-IP or RFC4301 IPsec tunnels/ > =3D=3D S.8. 1st para =3D=3D >=20 > " PCN-marking only carries a meaning within the confines of a PCN- > domain. Packets wishing to be treated as belonging to a PCN-flow > must carry a PCN-compatible DSCP and a PCN-Enabled ECN codepoint. > This encoding document is intended to stand independently of the > architecture used to determine how specific packets are authorised > to > be PCN-marked, which will be described in separate documents on > PCN- > boundary-node behaviour. > " > Delete the middle (2nd) sentence, which could be read as implying > that packets arriving at the PCN ingress have to already carry a > PCN-compatible DSCP and a PCN-Enabled ECN codepoint. >=20 > =3D=3D Repetitions that read OK, but may not have been intended =3D=3D >=20 > 2nd sentence of S.4.1. repeats the last bullet of the preceding > section (but they are both relevant in their respective sections). >=20 > Opening sentences of A.1 repeat 3rd para of S.4.3. >=20 >=20 > HTH >=20 >=20 > Bob >=20 >=20 > At 09:24 21/08/2009, toby.moncaster@bt.com wrote: > >Hi Phil, > > > >Thanks for the comments. I will try and incorporate all of them into > >the (hopefully) final version after the IETF LC ends in 2 weeks time. > > > >More inline > > > > > -----Original Message----- > > > From: Eardley,PL,Philip,DER3 R > > > Sent: 20 August 2009 17:37 > > > To: Moncaster,T,Toby,DER3 R; pcn@ietf.org; lars.eggert@nokia.com > > > Subject: RE: [PCN] FW: New Version Notification fordraft-ietf-pcn- > > > baseline-encoding-05 > > > > > > Few minor comments: > > > > > > Table 1 has > > > >EXP(01)* > > > >Valid* [in IN EXP(01) OUT PM(11) box] > > > > * This SHOULD cause an alarm to be raised at a higher layer. The > > > packet MUST be treated as if it carried the NM codepoint. > > > > > > I think your comment ["*This SHOULD.."] really only applies to the > > > "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm > as > > > this shouldn't happen. > > > >I think that is what I meant, yes. I will have a look at re-jigging > >the table to clarify > > > > > > > > > > Both the "Valid" boxes in this row could have a comment: > > > ** these transitions MAY be allowed be some future experimental > > > extensions to the baseline encoding. However a PCN-node that hasn't > be > > > upgraded (ie is still doing baseline) mustn't block this so it MUST > > > treat this transition as valid; it MAY also raise an alarm. > > > [Not sure " MAY also raise an alarm" is needed, since alarm already > > > raised since EXP(01) is the codepoint in] > > > >Or something about "In order not to block future extensions from > >using these transitions..."? I will try and sort something out > > > > > > > > > > > alarm to be raised at a higher layer > > > is 'higher layer' right? how about "management alarm"? > > > >Yep, by higher layer I meant control or management layer > > > > > > > > > > > > A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all > > > packets it forwards out of the PCN-domain. The only exception > to > > > this is if the PCN-egress-node is certain that revealing other > > > codepoints outside the PCN-domain won't contravene the guidance > > > given > > > in [RFC4774]. > > > I wonder if this needs a bit more explanation about how to do this, > or > > > where to find more guidance? > > > >Would an example count as guidance? "For example where the > >PCN-egress-node has been explicitly informed by the PCN-ingress-node > >that this flow is ECN-capable" In terms of where to find guidance, > >currently only in experimental schemes (I think) > > > > > > > > 4.3.1 > > > Co-existence of PCN and not-PCN traffic > > > I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft- > ietf- > > > pcn-marking-behaviour Section B.1) which says > > > >> It is not advised to have competing-non-PCN-traffic but, if > there > > > is such traffic, there needs to be a mechanism to limit it. > > > "Competing-non-PCN-traffic" means traffic that shares a link > with > > > PCN-traffic and competes for its forwarding bandwidth. > Hence, > > > more competing-non-PCN-traffic results in poorer QoS for PCN. > > > Further, the unpredictable amount of competing-non-PCN- > traffic > > > makes the PCN mechanisms less accurate and so reduces PCN's > > > ability to protect the QoS of admitted PCN-flows. > > > > > > >Yep, will do > > > > > 5 > > > > The 11 codepoint in the ECN field MUST indicate PCN-marked > (though > > > this does not exclude the 01 Experimental codepoint from > carrying > > > the same meaning). > > > I think better would be " Experimental codepoint from also > indicating > > > PCN-marking" [it would indicate a 2nd level of pcn-marking, which > you > > > could say is not the "same" meaning] > > > >But I define PCN-marked as having the meaning "...codepoint > >indicating packets that have been marked at a PCN-interior-node > >using some PCN marking behaviour..." Which is the same regardless of > >the relative level of each of those marks! However I am happy to be > >explicit and say EXP is not excluded from meaning PCN-marked > > > > > > > > A.1 > > > The approach & wording is basically good. > > > >In PCN-domains with uniformly high link rates, the > > > appropriate DSCPs would currently be those for the Real Time > Traffic > > > Class [RFC5127]. To be clear the PCN Working Group recommends > using > > > admission control for the following service classes: > > > > > > o Telephony (EF) > > > > > > o Real-time interactive (CS4) > > > > > > o Broadcast Video (CS3) > > > > > > o Multimedia Conferencing (AF4) > > > > > > I think "sufficient aggregation" would be better than "uniformly > high > > > link rates" [similarly, "sufficiently" not "highly" in the next > para] > > > >Yep > > > > > " Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at > > > least in Fig 2 > > > you might want to say why CS5 is excluded from pcn (all the other > dscps > > > in the RT treatement aggregate are included] > > > rfc4594 needed as a ref somewhere here as that defines these dscps > > > >Will just put "CS5 is excluded since PCN is not expected to be > >applied to signalling traffic". However that does raise an > >interesting question with regards to Michael's proposed approach of > >using admission marking on RSVP PATH messages in PSDM as I would > >count those as signalling traffic? > > > > > > > > > > > Typos etc > > > Abstract > > > >This document specifies how such marks are to be encoded > > > delete 'to be' > > > >OK > > > > > > > > 4.0 >implementiors > > > >Already spotted... > > > > > > > > 4.2 > > > > There are a number of factors that > > > were considered before choosing to set 10 > > > could have a new paragraph before this > > > > >OK > > > > > 4.3.0 > > > > Thirdly PCN > > > should be seen as being essentially a marking behaviour similar > to > > > ECN but intended for inelastic traffic. > > > Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it > > > should be seen as being essentially a marking behaviour similar to > ECN > > > but intended for inelastic traffic. > > > > >OK > > > > > 6 > > > > in decapsulation > > > 'upon' better? > > > > >Will decide > > > > > 6 > > > > If an > > > operator wishes to allow ECN to exist end-to-end they must > ensure > > > there are no tunnel end-points within the PCN-domain to prevent > any > > > risk of PCN-markings being exposed to endpoints. > > > Earlier in the paragraph you talk about a tunnel across the pcn- > domain > > > - then there might be another tunnel wholly within the pcn-domain, > and > > > this would be ok. (I know what you mean - perhaps slight re- > ordering of > > > the para would do the trick) > >Will have a think about whether I can word this any better... > > > > > > > > A.1 > > > >PCn region > > > PCN-domain > > > > >Oops! > > > > > Thanks > > > phil > > > > > > { -----Original Message----- > > > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > > { toby.moncaster@bt.com > > > { Sent: 20 August 2009 16:19 > > > { To: pcn@ietf.org; lars.eggert@nokia.com > > > { Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn- > > > baseline- > > > { encoding-05 > > > { > > > { I hope this accurately reflects the ML discussions over the past > few > > > days? > > > { I have also corrected all the nits and hopefully haven't left any > > > spelling > > > { mistakes or typos... > > > { > > > { Toby > > > { > > > { > ____________________________________________________________________ > > > { Toby Moncaster, Networks Research Centre, > BT > > > { B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 7918 901170 > > > { > > > { > > > { > > > { -----Original Message----- > > > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > { Sent: 20 August 2009 16:17 > > > { To: Moncaster,T,Toby,DER3 R > > > { Cc: Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de > > > { Subject: New Version Notification for draft-ietf-pcn-baseline- > > > encoding-05 > > > { > > > { > > > { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has > > > been > > > { successfuly submitted by T Moncaster and posted to the IETF > > > repository. > > > { > > > { Filename: draft-ietf-pcn-baseline-encoding > > > { Revision: 05 > > > { Title: Baseline Encoding and Transport of Pre- > Congestion > > > { Information > > > { Creation_date: 2009-08-20 > > > { WG ID: pcn > > > { Number_of_pages: 14 > > > { > > > { Abstract: > > > { The objective of Pre-Congestion Notification (PCN) is to protect > the > > > { quality of service (QoS) of inelastic flows within a Diffserv > domain. > > > { The overall rate of the PCN-traffic is metered on every link in > the > > > { PCN-domain, and PCN-packets are appropriately marked when certain > > > { configured rates are exceeded. The level of marking allows the > > > { boundary nodes to make decisions about whether to admit or block > a > > > { new flow request, and (in abnormal circumstances) whether to > > > { terminate some of the existing flows, thereby protecting the QoS > of > > > { previously admitted flows. This document specifies how such > marks > > > { are to be encoded into the IP header by re-using the Explicit > > > { Congestion Notification (ECN) codepoints within this controlled > > > { domain. The baseline encoding described here provides for only > two > > > { PCN encoding states, Not-marked and PCN-marked. > > > { > > > { > > > { > > > { The IETF Secretariat. > > > { > > > { > > > { _______________________________________________ > > > { PCN mailing list > > > { PCN@ietf.org > > > { https://www.ietf.org/mailman/listinfo/pcn > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www.ietf.org/mailman/listinfo/pcn From slblake@petri-meat.com Mon Aug 24 21:10:08 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 6C8603A6D81 for ; Mon, 24 Aug 2009 21:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=-0.463, 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 8HM6c2UD22T3 for ; Mon, 24 Aug 2009 21:10:07 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id C4C003A6B4F for ; Mon, 24 Aug 2009 21:10:07 -0700 (PDT) Received: from cpe-071-065-229-025.nc.res.rr.com ([71.65.229.25]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MfnMK-0002zf-9t for pcn@ietf.org; Tue, 25 Aug 2009 00:10:12 -0400 From: Steven Blake To: pcn Content-Type: text/plain Date: Tue, 25 Aug 2009 00:10:12 -0400 Message-Id: <1251173412.4347.3.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.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 Subject: [PCN] Updated IETF 75 working group meeting minutes 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, 25 Aug 2009 04:10:08 -0000 I updated the minutes of the Stockholm meeting again based on late comments by Georgios, correcting references to the LCN-PCN draft (rather than the PCN-CL draft). http://www.ietf.org/proceedings/75/minutes/pcn.txt Further comments welcome, but they need to happen soon. Regards, // Steve From lars.eggert@nokia.com Tue Aug 25 07:11:52 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 408D03A6F2B for ; Tue, 25 Aug 2009 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, SARE_OBFU_COULD=0.917] 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 jiJk7QF58x2m for ; Tue, 25 Aug 2009 07:11:51 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id D046E3A6BAD for ; Tue, 25 Aug 2009 07:11:50 -0700 (PDT) Received: from wifi-visiteurs-107.sri.ucl.ac.be (wifi-visiteurs-107.sri.ucl.ac.be [130.104.202.235]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7PEBlja028340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Aug 2009 17:11:48 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> From: Lars Eggert To: pcn@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-62-171881117; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 16:11:44 +0200 References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> X-Mailer: Apple Mail (2.936) Subject: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05 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, 25 Aug 2009 14:11:52 -0000 --Apple-Mail-62-171881117 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Spencer Dawkins > Date: August 25, 2009 14:47:49 GMT+02:00 > To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > > Cc: General Area Review Team , "ietf@ietf.org > " > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > encoding-05 > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for > this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd or AD before > posting a > new version of the draft. > > Document: draft-ietf-pcn-baseline-encoding-05 > Reviewer: Spencer Dawkins > IETF LC End Date: 2009-09-03 > Review Date: 2009-08-21 > IESG Telechat date: (not known) > > Summary: this specification is almost ready for publication as a > Proposed > Standard. I have one minor question below (flagged as "Spencer > (minor)"), > along with some editorial suggestions to be considered when this > document is > edited (either in the working group or by the RFC Editor). > > Abstract > > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv > domain. > > Spencer (clarity): I'm not sure what the relationship between a > Diffserv > domain and a PCN-domain is - this couuld be clearer, especially in an > Abstract. I note that RFC 5559 doesn't use the term PCN-domain in its > Abstract ... I can guess, but I'm just guessing. > > The overall rate of the PCN-traffic is metered on every link in the > PCN-domain, and PCN-packets are appropriately marked when certain > configured rates are exceeded. The level of marking allows the > boundary nodes to make decisions about whether to admit or block a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are to be encoded into the IP header by re-using the Explicit > Congestion Notification (ECN) codepoints within this controlled > domain. The baseline encoding described here provides for only two > PCN encoding states, Not-marked and PCN-marked. > > 4. Encoding two PCN States in IP > > The following rules apply to all PCN traffic: > > o PCN-traffic MUST be marked with a PCN-compatible Diffserv > Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > chosen that are already defined for use with admission controlled > traffic. Appendix A.1 gives guidance to implementiors on > suitable > > Spencer (clarity): s/implementiors/implementers/? > > DSCPs. Guidelines for mixing traffic-types within a PCN-domain > are given in [I-D.ietf-pcn-marking-behaviour]. > > o Any packet that is not-PCN but which shares the same Diffserv > codepoint as PCN-enabled traffic MUST have the ECN field of its > outermost IP header equal to 00. > > Spencer (minor): this is the only point in the specification (that I > can > find) that makes reference to the "outermost IP header". I'm not sure > whether to suggest s/outermost// here or to ask that a statement be > added > earlier in the document to clearly state that PCN encoding only > protects > inelastic traffic when it's used for the outermost IP header, but the > current text seems to call attention to this in a way that makes the > reader > wonder what is special about THIS requirement that isn't true of the > other > requirements listed. > > 4.3. PCN-Compatible Diffserv Codepoints > > Enabling PCN marking behaviour for a specific DSCP disables any > other > marking behaviour (e.g. enabling PCN disables the default ECN > marking > behaviour introduced in [RFC3168]). All traffic metering and > marking > > Spencer (clarity): here, and in Section 6, the text uses "disables" to > describe the relationship between PCN and ECN. If I understand the > point, > the domain is substituting one behavior for another. I might suggest > "replaces" to describe the relationship in both locations. > > behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. This > ensures compliance with the BCP guidance set out in [RFC4774]. > > 4.3.1. Co-existence of PCN and not-PCN traffic > > The scarcity of pool 1 DSCPs coupled with the fact that PCN is > envisaged as a marking behaviour that could be applied to a number > of > different DSCPs makes it essential that we provide a not-PCN state. > As stated above (and expanded in Appendix A.1) the aim is for PCN to > re-use existing DSCPs. Because PCN re-defines the meaning of the > ECN > > Spencer (clarity): here, the text uses "re-defines", which I like > better > than "disables", but if you go for "replaces" previously and in > section 6, > you might want to use the same wording here. > > field for such DSCPs it is important to allow an operator to still > use the DSCP for traffic that isn't PCN-enabled. This is achieved > by > providing a not-PCN state within the encoding scheme. > > A.1. Choice of Suitable DSCPs > > The PCN Working Group chose not to define a single DSCP for use with > PCN for several reasons. Firstly the PCN mechanism is applicable to > a variety of different traffic classes. Secondly standards track > DSCPs are in increasingly short supply. Thirdly PCN should be seen > as being essentially a marking behaviour similar to ECN but intended > for inelastic traffic. The choice of which DSCP is most suitable > for > a given PCN-domain is dependent on the nature of the traffic > entering > that domain and the link rates of all the links making up that > domain. In PCN-domains with uniformly high link rates, the > appropriate DSCPs would currently be those for the Real Time Traffic > Class [RFC5127]. To be clear the PCN Working Group recommends using > > Spencer (clarity): is this 2119 language (apparently not, since this > section > is not normative), or are you saying "suggests"? My suggestion is > that we > not use 2119 language, even lowercased, except for normative text - > this > seems to cause confusion from time to time. But please check with your > shepherding AD to see if he agrees. > > admission control for the following service classes: > > o Telephony (EF) > > o Real-time interactive (CS4) > > o Broadcast Video (CS3) > > o Multimedia Conferencing (AF4) > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail-62-171881117 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MDgyNTE0MTE0NFowIwYJKoZIhvcNAQkEMRYEFLYDhrY0/lII7hzCsUqcstogOjU/MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDH6oiPVTJCWQdTcOtoAABk8rhoLIkuVKf+iHohJyNG4dRN/+K6+1MrNVbAUfiKPsT5HGYM HCUvkq3CF7McsOw9rXUDTEVNK8tizOnIlz8/9qRbe+voCIJ4VY92A4ATVaUlAFD6uutbKiJowOu5 c1btd2R0PWUhvvqWh6wmub+/AFOVcceN0qU9WJlkbvN7Hdei1vfYBekMnkzen4e5k7I89JofEvH0 c4Bdy+rjjTsL6j+vbtzEU5ZjBsmZ5J7Lqok//vss+5dNEvepomHQQ/uAYxPHytdz05Anz5ubJ2P+ NbVcCs2W5Q1J7pv5o2hSTFvoTpEYQICCwKq7fO6S3zH/AAAAAAAA --Apple-Mail-62-171881117-- From slblake@petri-meat.com Tue Aug 25 07:48:15 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19DC28C112 for ; Tue, 25 Aug 2009 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, SARE_OBFU_COULD=0.917] 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 LPqzaxDfbAuB for ; Tue, 25 Aug 2009 07:48:14 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 4C44E3A6D95 for ; Tue, 25 Aug 2009 07:48:14 -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 1MfxJn-0007JE-Oy; Tue, 25 Aug 2009 10:48:15 -0400 MIME-Version: 1.0 Date: Tue, 25 Aug 2009 10:48:15 -0400 From: To: Spencer Dawkins In-Reply-To: <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> 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] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05 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, 25 Aug 2009 14:48:15 -0000 Spencer, Thanks for the careful review. Comments in-line. >> From: Spencer Dawkins >> Date: August 25, 2009 14:47:49 GMT+02:00 >> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >> > > >> Cc: General Area Review Team , "ietf@ietf.org >> " >> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >> encoding-05 >> >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for >> this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >> Please wait for direction from your document shepherd or AD before >> posting a >> new version of the draft. >> >> Document: draft-ietf-pcn-baseline-encoding-05 >> Reviewer: Spencer Dawkins >> IETF LC End Date: 2009-09-03 >> Review Date: 2009-08-21 >> IESG Telechat date: (not known) >> >> Summary: this specification is almost ready for publication as a >> Proposed >> Standard. I have one minor question below (flagged as "Spencer >> (minor)"), >> along with some editorial suggestions to be considered when this >> document is >> edited (either in the working group or by the RFC Editor). >> >> Abstract >> >> The objective of Pre-Congestion Notification (PCN) is to protect the >> quality of service (QoS) of inelastic flows within a Diffserv >> domain. >> >> Spencer (clarity): I'm not sure what the relationship between a >> Diffserv >> domain and a PCN-domain is - this couuld be clearer, especially in an >> Abstract. I note that RFC 5559 doesn't use the term PCN-domain in its >> Abstract ... I can guess, but I'm just guessing. I agree that we should clarify that. >> The overall rate of the PCN-traffic is metered on every link in the >> PCN-domain, and PCN-packets are appropriately marked when certain >> configured rates are exceeded. The level of marking allows the >> boundary nodes to make decisions about whether to admit or block a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS of >> previously admitted flows. This document specifies how such marks >> are to be encoded into the IP header by re-using the Explicit >> Congestion Notification (ECN) codepoints within this controlled >> domain. The baseline encoding described here provides for only two >> PCN encoding states, Not-marked and PCN-marked. >> >> 4. Encoding two PCN States in IP >> >> The following rules apply to all PCN traffic: >> >> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be >> chosen that are already defined for use with admission controlled >> traffic. Appendix A.1 gives guidance to implementiors on >> suitable >> >> Spencer (clarity): s/implementiors/implementers/? >> >> DSCPs. Guidelines for mixing traffic-types within a PCN-domain >> are given in [I-D.ietf-pcn-marking-behaviour]. >> >> o Any packet that is not-PCN but which shares the same Diffserv >> codepoint as PCN-enabled traffic MUST have the ECN field of its >> outermost IP header equal to 00. >> >> Spencer (minor): this is the only point in the specification (that I >> can >> find) that makes reference to the "outermost IP header". I'm not sure >> whether to suggest s/outermost// here or to ask that a statement be >> added >> earlier in the document to clearly state that PCN encoding only >> protects >> inelastic traffic when it's used for the outermost IP header, but the >> current text seems to call attention to this in a way that makes the >> reader >> wonder what is special about THIS requirement that isn't true of the >> other >> requirements listed. I'm sorry, but I'm having a hard time following this comment. Could you please clarify? >> >> 4.3. PCN-Compatible Diffserv Codepoints >> >> Enabling PCN marking behaviour for a specific DSCP disables any >> other >> marking behaviour (e.g. enabling PCN disables the default ECN >> marking >> behaviour introduced in [RFC3168]). All traffic metering and >> marking >> >> Spencer (clarity): here, and in Section 6, the text uses "disables" to >> describe the relationship between PCN and ECN. If I understand the >> point, >> the domain is substituting one behavior for another. I might suggest >> "replaces" to describe the relationship in both locations. Ok >> >> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. This >> ensures compliance with the BCP guidance set out in [RFC4774]. >> >> 4.3.1. Co-existence of PCN and not-PCN traffic >> >> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >> envisaged as a marking behaviour that could be applied to a number >> of >> different DSCPs makes it essential that we provide a not-PCN state. >> As stated above (and expanded in Appendix A.1) the aim is for PCN to >> re-use existing DSCPs. Because PCN re-defines the meaning of the >> ECN >> >> Spencer (clarity): here, the text uses "re-defines", which I like >> better >> than "disables", but if you go for "replaces" previously and in >> section 6, >> you might want to use the same wording here. Ok >> >> field for such DSCPs it is important to allow an operator to still >> use the DSCP for traffic that isn't PCN-enabled. This is achieved >> by >> providing a not-PCN state within the encoding scheme. >> >> A.1. Choice of Suitable DSCPs >> >> The PCN Working Group chose not to define a single DSCP for use with >> PCN for several reasons. Firstly the PCN mechanism is applicable to >> a variety of different traffic classes. Secondly standards track >> DSCPs are in increasingly short supply. Thirdly PCN should be seen >> as being essentially a marking behaviour similar to ECN but intended >> for inelastic traffic. The choice of which DSCP is most suitable >> for >> a given PCN-domain is dependent on the nature of the traffic >> entering >> that domain and the link rates of all the links making up that >> domain. In PCN-domains with uniformly high link rates, the >> appropriate DSCPs would currently be those for the Real Time Traffic >> Class [RFC5127]. To be clear the PCN Working Group recommends using >> >> Spencer (clarity): is this 2119 language (apparently not, since this >> section >> is not normative), or are you saying "suggests"? My suggestion is >> that we >> not use 2119 language, even lowercased, except for normative text - >> this >> seems to cause confusion from time to time. But please check with your >> shepherding AD to see if he agrees. What is your opinion Lars? >> >> admission control for the following service classes: >> >> o Telephony (EF) >> >> o Real-time interactive (CS4) >> >> o Broadcast Video (CS3) >> >> o Multimedia Conferencing (AF4) Regards, // Steve From toby.moncaster@bt.com Tue Aug 25 07:54: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 421F328C370 for ; Tue, 25 Aug 2009 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 USGU50asrLkk for ; Tue, 25 Aug 2009 07:54:45 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AD5AD28C2A9 for ; Tue, 25 Aug 2009 07:53:53 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 15:53:59 +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, 25 Aug 2009 15:53:51 +0100 Message-ID: In-Reply-To: <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: Acoljgh0pdfHzWI2R3i+5BsNpCTWtgABNk1Q References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> From: To: X-OriginalArrivalTime: 25 Aug 2009 14:53:59.0561 (UTC) FILETIME=[E0CFB790:01CA2593] Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 25 Aug 2009 14:54:46 -0000 This potentially raises an issue for all future PCN documents since the abstract was based on our agreed standard elevator-pitch introduction to PCN... Specifically Spencer raises the question of using the defined term PCN-domain in the abstract. Any thoughts from anyone as to whether this is confusing? Would it be clearer to just use "domain" (e.g. drop the "PCN-"). In which case should I alter the whole abstract as follows (note: I realise this is strictly incorrect as it now doesn't seek to distinguish the non-PCN and PCN traffic from each other but is this clearer for a casual reader?): The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the traffic is metered on every link in the domain, and packets are appropriately marked when certain configured rates are exceeded. Boundary nodes can measure the level of marking and thus make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked. Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Lars Eggert > Sent: 25 August 2009 15:12 > To: pcn@ietf.org > Subject: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline- > encoding-05 >=20 >=20 >=20 > Begin forwarded message: >=20 > > From: Spencer Dawkins > > Date: August 25, 2009 14:47:49 GMT+02:00 > > To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" pcn-baseline-encoding@tools.ietf.org > > > > > Cc: General Area Review Team , > "ietf@ietf.org > > " > > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > > encoding-05 > > > > I have been selected as the General Area Review Team (Gen-ART) > > reviewer for this draft (for background on Gen-ART, please see > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > > > Please wait for direction from your document shepherd or AD before > > posting a new version of the draft. > > > > Document: draft-ietf-pcn-baseline-encoding-05 > > Reviewer: Spencer Dawkins > > IETF LC End Date: 2009-09-03 > > Review Date: 2009-08-21 > > IESG Telechat date: (not known) > > > > Summary: this specification is almost ready for publication as a > > Proposed Standard. I have one minor question below (flagged as > > "Spencer (minor)"), along with some editorial suggestions to be > > considered when this document is edited (either in the working group > > or by the RFC Editor). > > > > Abstract > > > > The objective of Pre-Congestion Notification (PCN) is to protect > the > > quality of service (QoS) of inelastic flows within a Diffserv > > domain. > > > > Spencer (clarity): I'm not sure what the relationship between a > > Diffserv domain and a PCN-domain is - this couuld be clearer, > > especially in an Abstract. I note that RFC 5559 doesn't use the term > > PCN-domain in its Abstract ... I can guess, but I'm just guessing. > > > > The overall rate of the PCN-traffic is metered on every link in the > > PCN-domain, and PCN-packets are appropriately marked when certain > > configured rates are exceeded. The level of marking allows the > > boundary nodes to make decisions about whether to admit or block a > > new flow request, and (in abnormal circumstances) whether to > > terminate some of the existing flows, thereby protecting the QoS of > > previously admitted flows. This document specifies how such marks > > are to be encoded into the IP header by re-using the Explicit > > Congestion Notification (ECN) codepoints within this controlled > > domain. The baseline encoding described here provides for only two > > PCN encoding states, Not-marked and PCN-marked. > > > > 4. Encoding two PCN States in IP > > > > The following rules apply to all PCN traffic: > > > > o PCN-traffic MUST be marked with a PCN-compatible Diffserv > > Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > > chosen that are already defined for use with admission > controlled > > traffic. Appendix A.1 gives guidance to implementiors on > > suitable > > > > Spencer (clarity): s/implementiors/implementers/? > > > > DSCPs. Guidelines for mixing traffic-types within a PCN-domain > > are given in [I-D.ietf-pcn-marking-behaviour]. > > > > o Any packet that is not-PCN but which shares the same Diffserv > > codepoint as PCN-enabled traffic MUST have the ECN field of its > > outermost IP header equal to 00. > > > > Spencer (minor): this is the only point in the specification (that I > > can > > find) that makes reference to the "outermost IP header". I'm not sure > > whether to suggest s/outermost// here or to ask that a statement be > > added earlier in the document to clearly state that PCN encoding only > > protects inelastic traffic when it's used for the outermost IP > header, > > but the current text seems to call attention to this in a way that > > makes the reader wonder what is special about THIS requirement that > > isn't true of the other requirements listed. > > > > 4.3. PCN-Compatible Diffserv Codepoints > > > > Enabling PCN marking behaviour for a specific DSCP disables any > > other > > marking behaviour (e.g. enabling PCN disables the default ECN > > marking > > behaviour introduced in [RFC3168]). All traffic metering and > > marking > > > > Spencer (clarity): here, and in Section 6, the text uses "disables" > to > > describe the relationship between PCN and ECN. If I understand the > > point, the domain is substituting one behavior for another. I might > > suggest "replaces" to describe the relationship in both locations. > > > > behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. This > > ensures compliance with the BCP guidance set out in [RFC4774]. > > > > 4.3.1. Co-existence of PCN and not-PCN traffic > > > > The scarcity of pool 1 DSCPs coupled with the fact that PCN is > > envisaged as a marking behaviour that could be applied to a number > > of > > different DSCPs makes it essential that we provide a not-PCN state. > > As stated above (and expanded in Appendix A.1) the aim is for PCN > to > > re-use existing DSCPs. Because PCN re-defines the meaning of the > > ECN > > > > Spencer (clarity): here, the text uses "re-defines", which I like > > better than "disables", but if you go for "replaces" previously and > in > > section 6, you might want to use the same wording here. > > > > field for such DSCPs it is important to allow an operator to still > > use the DSCP for traffic that isn't PCN-enabled. This is achieved > > by > > providing a not-PCN state within the encoding scheme. > > > > A.1. Choice of Suitable DSCPs > > > > The PCN Working Group chose not to define a single DSCP for use > with > > PCN for several reasons. Firstly the PCN mechanism is applicable > to > > a variety of different traffic classes. Secondly standards track > > DSCPs are in increasingly short supply. Thirdly PCN should be seen > > as being essentially a marking behaviour similar to ECN but > intended > > for inelastic traffic. The choice of which DSCP is most suitable > > for > > a given PCN-domain is dependent on the nature of the traffic > > entering > > that domain and the link rates of all the links making up that > > domain. In PCN-domains with uniformly high link rates, the > > appropriate DSCPs would currently be those for the Real Time > Traffic > > Class [RFC5127]. To be clear the PCN Working Group recommends > using > > > > Spencer (clarity): is this 2119 language (apparently not, since this > > section is not normative), or are you saying "suggests"? My > suggestion > > is that we not use 2119 language, even lowercased, except for > > normative text - this seems to cause confusion from time to time. But > > please check with your shepherding AD to see if he agrees. > > > > admission control for the following service classes: > > > > o Telephony (EF) > > > > o Real-time interactive (CS4) > > > > o Broadcast Video (CS3) > > > > o Multimedia Conferencing (AF4) > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art From tom.taylor@rogers.com Tue Aug 25 11:38:13 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 087923A6C7F for ; Tue, 25 Aug 2009 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, SARE_OBFU_COULD=0.917] 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 Q40xzSzYDhtB for ; Tue, 25 Aug 2009 11:38:11 -0700 (PDT) Received: from smtp106.rog.mail.re2.yahoo.com (smtp106.rog.mail.re2.yahoo.com [68.142.225.204]) by core3.amsl.com (Postfix) with SMTP id 7EC563A6B75 for ; Tue, 25 Aug 2009 11:38:11 -0700 (PDT) Received: (qmail 75107 invoked from network); 25 Aug 2009 18:38:14 -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=TTejKCiM8QJogSsILEqkqnpKXvqDAwLanoHEQUoJtrmFnPjV4BZDVXeelB4ikuarM2Eh7AIFovtuGf4uTatOdzggEHU0fYhx1SjiBqbD7KKeeTg/Axt0t1Xbt6F9T7h7zSAto4/OQTmqvw3bBsDj2bHmpjOU3f6rymiX+UmvW6w= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp106.rog.mail.re2.yahoo.com with SMTP; 25 Aug 2009 18:38:14 -0000 X-YMail-OSG: mgXZYNUVM1m2npwIf7tieOpUHB7M5ZdxS1C_uDFoblqAsjRTp7YQsw6Tw7O9vcD_Ow-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A942F95.90309@rogers.com> Date: Tue, 25 Aug 2009 14:38:13 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 25 Aug 2009 18:38:13 -0000 How about adding "PCN" in front of "traffic" in: "The overall rate of the traffic is metered ...", and in front of each instance of "flow"? toby.moncaster@bt.com wrote: > This potentially raises an issue for all future PCN documents since the > abstract was based on our agreed standard elevator-pitch introduction to > PCN... Specifically Spencer raises the question of using the defined > term PCN-domain in the abstract. Any thoughts from anyone as to whether > this is confusing? Would it be clearer to just use "domain" (e.g. drop > the "PCN-"). In which case should I alter the whole abstract as follows > (note: I realise this is strictly incorrect as it now doesn't seek to > distinguish the non-PCN and PCN traffic from each other but is this > clearer for a casual reader?): > > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv domain. > The overall rate of the traffic is metered on every link in the > domain, and packets are appropriately marked when certain > configured rates are exceeded. Boundary nodes can measure the level > of marking and thus make decisions about whether to admit or block a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. The > baseline encoding described here provides for only two PCN encoding > states, Not-marked and PCN-marked. > > Toby > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Lars Eggert >> Sent: 25 August 2009 15:12 >> To: pcn@ietf.org >> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > ofdraft-ietf-pcn-baseline- >> encoding-05 >> >> >> >> Begin forwarded message: >> >>> From: Spencer Dawkins >>> Date: August 25, 2009 14:47:49 GMT+02:00 >>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > > pcn-baseline-encoding@tools.ietf.org >>> Cc: General Area Review Team , >> "ietf@ietf.org >>> " >>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>> encoding-05 >>> >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please wait for direction from your document shepherd or AD before >>> posting a new version of the draft. >>> >>> Document: draft-ietf-pcn-baseline-encoding-05 >>> Reviewer: Spencer Dawkins >>> IETF LC End Date: 2009-09-03 >>> Review Date: 2009-08-21 >>> IESG Telechat date: (not known) >>> >>> Summary: this specification is almost ready for publication as a >>> Proposed Standard. I have one minor question below (flagged as >>> "Spencer (minor)"), along with some editorial suggestions to be >>> considered when this document is edited (either in the working group >>> or by the RFC Editor). >>> >>> Abstract >>> >>> The objective of Pre-Congestion Notification (PCN) is to protect >> the >>> quality of service (QoS) of inelastic flows within a Diffserv >>> domain. >>> >>> Spencer (clarity): I'm not sure what the relationship between a >>> Diffserv domain and a PCN-domain is - this couuld be clearer, >>> especially in an Abstract. I note that RFC 5559 doesn't use the term >>> PCN-domain in its Abstract ... I can guess, but I'm just guessing. >>> >>> The overall rate of the PCN-traffic is metered on every link in > the >>> PCN-domain, and PCN-packets are appropriately marked when certain >>> configured rates are exceeded. The level of marking allows the >>> boundary nodes to make decisions about whether to admit or block a >>> new flow request, and (in abnormal circumstances) whether to >>> terminate some of the existing flows, thereby protecting the QoS > of >>> previously admitted flows. This document specifies how such marks >>> are to be encoded into the IP header by re-using the Explicit >>> Congestion Notification (ECN) codepoints within this controlled >>> domain. The baseline encoding described here provides for only > two >>> PCN encoding states, Not-marked and PCN-marked. >>> >>> 4. Encoding two PCN States in IP >>> >>> The following rules apply to all PCN traffic: >>> >>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be >>> chosen that are already defined for use with admission >> controlled >>> traffic. Appendix A.1 gives guidance to implementiors on >>> suitable >>> >>> Spencer (clarity): s/implementiors/implementers/? >>> >>> DSCPs. Guidelines for mixing traffic-types within a PCN-domain >>> are given in [I-D.ietf-pcn-marking-behaviour]. >>> >>> o Any packet that is not-PCN but which shares the same Diffserv >>> codepoint as PCN-enabled traffic MUST have the ECN field of its >>> outermost IP header equal to 00. >>> >>> Spencer (minor): this is the only point in the specification (that I >>> can >>> find) that makes reference to the "outermost IP header". I'm not > sure >>> whether to suggest s/outermost// here or to ask that a statement be >>> added earlier in the document to clearly state that PCN encoding > only >>> protects inelastic traffic when it's used for the outermost IP >> header, >>> but the current text seems to call attention to this in a way that >>> makes the reader wonder what is special about THIS requirement that >>> isn't true of the other requirements listed. >>> >>> 4.3. PCN-Compatible Diffserv Codepoints >>> >>> Enabling PCN marking behaviour for a specific DSCP disables any >>> other >>> marking behaviour (e.g. enabling PCN disables the default ECN >>> marking >>> behaviour introduced in [RFC3168]). All traffic metering and >>> marking >>> >>> Spencer (clarity): here, and in Section 6, the text uses "disables" >> to >>> describe the relationship between PCN and ECN. If I understand the >>> point, the domain is substituting one behavior for another. I might >>> suggest "replaces" to describe the relationship in both locations. >>> >>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > This >>> ensures compliance with the BCP guidance set out in [RFC4774]. >>> >>> 4.3.1. Co-existence of PCN and not-PCN traffic >>> >>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >>> envisaged as a marking behaviour that could be applied to a number >>> of >>> different DSCPs makes it essential that we provide a not-PCN > state. >>> As stated above (and expanded in Appendix A.1) the aim is for PCN >> to >>> re-use existing DSCPs. Because PCN re-defines the meaning of the >>> ECN >>> >>> Spencer (clarity): here, the text uses "re-defines", which I like >>> better than "disables", but if you go for "replaces" previously and >> in >>> section 6, you might want to use the same wording here. >>> >>> field for such DSCPs it is important to allow an operator to still >>> use the DSCP for traffic that isn't PCN-enabled. This is achieved >>> by >>> providing a not-PCN state within the encoding scheme. >>> >>> A.1. Choice of Suitable DSCPs >>> >>> The PCN Working Group chose not to define a single DSCP for use >> with >>> PCN for several reasons. Firstly the PCN mechanism is applicable >> to >>> a variety of different traffic classes. Secondly standards track >>> DSCPs are in increasingly short supply. Thirdly PCN should be > seen >>> as being essentially a marking behaviour similar to ECN but >> intended >>> for inelastic traffic. The choice of which DSCP is most suitable >>> for >>> a given PCN-domain is dependent on the nature of the traffic >>> entering >>> that domain and the link rates of all the links making up that >>> domain. In PCN-domains with uniformly high link rates, the >>> appropriate DSCPs would currently be those for the Real Time >> Traffic >>> Class [RFC5127]. To be clear the PCN Working Group recommends >> using >>> Spencer (clarity): is this 2119 language (apparently not, since this >>> section is not normative), or are you saying "suggests"? My >> suggestion >>> is that we not use 2119 language, even lowercased, except for >>> normative text - this seems to cause confusion from time to time. > But >>> please check with your shepherding AD to see if he agrees. >>> >>> admission control for the following service classes: >>> >>> o Telephony (EF) >>> >>> o Real-time interactive (CS4) >>> >>> o Broadcast Video (CS3) >>> >>> o Multimedia Conferencing (AF4) >>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From bob@homefarmparham.co.uk Tue Aug 25 11:42: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 15A083A6B75 for ; Tue, 25 Aug 2009 11:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_OBFU_COULD=0.917] 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 T+shZmZ0KmZE for ; Tue, 25 Aug 2009 11:42:34 -0700 (PDT) Received: from smtp-wifi.orange.fr (smtp-wifi-out.orange.fr [80.12.242.163]) by core3.amsl.com (Postfix) with ESMTP id 546AC28C148 for ; Tue, 25 Aug 2009 11:42:32 -0700 (PDT) Received: from BTG127939.homefarmparham.co.uk (unknown [81.253.82.60]) by mwinf5909 (SMTP Server) with ESMTP id CDB2EBEF4; Tue, 25 Aug 2009 20:42:29 +0200 (CEST) X-ME-UUID: 20090825184229842.CDB2EBEF4@mwinf5909 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Aug 2009 19:42:26 +0100 To: , From: Bob Briscoe In-Reply-To: References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090825184229.CDB2EBEF4@mwinf5909> X-Mailman-Approved-At: Tue, 25 Aug 2009 13:36:49 -0700 Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 25 Aug 2009 18:51:41 -0000 Toby, I think this isn't just good for a casual reader, but it is actually still correct and doesn't require defining PC-domain (which is just the Diffserv domain once the described measures - the PDB - have been put in place). Bob At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >This potentially raises an issue for all future PCN documents since the >abstract was based on our agreed standard elevator-pitch introduction to >PCN... Specifically Spencer raises the question of using the defined >term PCN-domain in the abstract. Any thoughts from anyone as to whether >this is confusing? Would it be clearer to just use "domain" (e.g. drop >the "PCN-"). In which case should I alter the whole abstract as follows >(note: I realise this is strictly incorrect as it now doesn't seek to >distinguish the non-PCN and PCN traffic from each other but is this >clearer for a casual reader?): > > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv domain. > The overall rate of the traffic is metered on every link in the > domain, and packets are appropriately marked when certain > configured rates are exceeded. Boundary nodes can measure the level > of marking and thus make decisions about whether to admit or block a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. The > baseline encoding described here provides for only two PCN encoding > states, Not-marked and PCN-marked. > >Toby > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Lars Eggert > > Sent: 25 August 2009 15:12 > > To: pcn@ietf.org > > Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >ofdraft-ietf-pcn-baseline- > > encoding-05 > > > > > > > > Begin forwarded message: > > > > > From: Spencer Dawkins > > > Date: August 25, 2009 14:47:49 GMT+02:00 > > > To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > > pcn-baseline-encoding@tools.ietf.org > > > > > > > Cc: General Area Review Team , > > "ietf@ietf.org > > > " > > > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > > > encoding-05 > > > > > > I have been selected as the General Area Review Team (Gen-ART) > > > reviewer for this draft (for background on Gen-ART, please see > > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > > > > > Please wait for direction from your document shepherd or AD before > > > posting a new version of the draft. > > > > > > Document: draft-ietf-pcn-baseline-encoding-05 > > > Reviewer: Spencer Dawkins > > > IETF LC End Date: 2009-09-03 > > > Review Date: 2009-08-21 > > > IESG Telechat date: (not known) > > > > > > Summary: this specification is almost ready for publication as a > > > Proposed Standard. I have one minor question below (flagged as > > > "Spencer (minor)"), along with some editorial suggestions to be > > > considered when this document is edited (either in the working group > > > or by the RFC Editor). > > > > > > Abstract > > > > > > The objective of Pre-Congestion Notification (PCN) is to protect > > the > > > quality of service (QoS) of inelastic flows within a Diffserv > > > domain. > > > > > > Spencer (clarity): I'm not sure what the relationship between a > > > Diffserv domain and a PCN-domain is - this couuld be clearer, > > > especially in an Abstract. I note that RFC 5559 doesn't use the term > > > PCN-domain in its Abstract ... I can guess, but I'm just guessing. > > > > > > The overall rate of the PCN-traffic is metered on every link in >the > > > PCN-domain, and PCN-packets are appropriately marked when certain > > > configured rates are exceeded. The level of marking allows the > > > boundary nodes to make decisions about whether to admit or block a > > > new flow request, and (in abnormal circumstances) whether to > > > terminate some of the existing flows, thereby protecting the QoS >of > > > previously admitted flows. This document specifies how such marks > > > are to be encoded into the IP header by re-using the Explicit > > > Congestion Notification (ECN) codepoints within this controlled > > > domain. The baseline encoding described here provides for only >two > > > PCN encoding states, Not-marked and PCN-marked. > > > > > > 4. Encoding two PCN States in IP > > > > > > The following rules apply to all PCN traffic: > > > > > > o PCN-traffic MUST be marked with a PCN-compatible Diffserv > > > Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > > > chosen that are already defined for use with admission > > controlled > > > traffic. Appendix A.1 gives guidance to implementiors on > > > suitable > > > > > > Spencer (clarity): s/implementiors/implementers/? > > > > > > DSCPs. Guidelines for mixing traffic-types within a PCN-domain > > > are given in [I-D.ietf-pcn-marking-behaviour]. > > > > > > o Any packet that is not-PCN but which shares the same Diffserv > > > codepoint as PCN-enabled traffic MUST have the ECN field of its > > > outermost IP header equal to 00. > > > > > > Spencer (minor): this is the only point in the specification (that I > > > can > > > find) that makes reference to the "outermost IP header". I'm not >sure > > > whether to suggest s/outermost// here or to ask that a statement be > > > added earlier in the document to clearly state that PCN encoding >only > > > protects inelastic traffic when it's used for the outermost IP > > header, > > > but the current text seems to call attention to this in a way that > > > makes the reader wonder what is special about THIS requirement that > > > isn't true of the other requirements listed. > > > > > > 4.3. PCN-Compatible Diffserv Codepoints > > > > > > Enabling PCN marking behaviour for a specific DSCP disables any > > > other > > > marking behaviour (e.g. enabling PCN disables the default ECN > > > marking > > > behaviour introduced in [RFC3168]). All traffic metering and > > > marking > > > > > > Spencer (clarity): here, and in Section 6, the text uses "disables" > > to > > > describe the relationship between PCN and ECN. If I understand the > > > point, the domain is substituting one behavior for another. I might > > > suggest "replaces" to describe the relationship in both locations. > > > > > > behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >This > > > ensures compliance with the BCP guidance set out in [RFC4774]. > > > > > > 4.3.1. Co-existence of PCN and not-PCN traffic > > > > > > The scarcity of pool 1 DSCPs coupled with the fact that PCN is > > > envisaged as a marking behaviour that could be applied to a number > > > of > > > different DSCPs makes it essential that we provide a not-PCN >state. > > > As stated above (and expanded in Appendix A.1) the aim is for PCN > > to > > > re-use existing DSCPs. Because PCN re-defines the meaning of the > > > ECN > > > > > > Spencer (clarity): here, the text uses "re-defines", which I like > > > better than "disables", but if you go for "replaces" previously and > > in > > > section 6, you might want to use the same wording here. > > > > > > field for such DSCPs it is important to allow an operator to still > > > use the DSCP for traffic that isn't PCN-enabled. This is achieved > > > by > > > providing a not-PCN state within the encoding scheme. > > > > > > A.1. Choice of Suitable DSCPs > > > > > > The PCN Working Group chose not to define a single DSCP for use > > with > > > PCN for several reasons. Firstly the PCN mechanism is applicable > > to > > > a variety of different traffic classes. Secondly standards track > > > DSCPs are in increasingly short supply. Thirdly PCN should be >seen > > > as being essentially a marking behaviour similar to ECN but > > intended > > > for inelastic traffic. The choice of which DSCP is most suitable > > > for > > > a given PCN-domain is dependent on the nature of the traffic > > > entering > > > that domain and the link rates of all the links making up that > > > domain. In PCN-domains with uniformly high link rates, the > > > appropriate DSCPs would currently be those for the Real Time > > Traffic > > > Class [RFC5127]. To be clear the PCN Working Group recommends > > using > > > > > > Spencer (clarity): is this 2119 language (apparently not, since this > > > section is not normative), or are you saying "suggests"? My > > suggestion > > > is that we not use 2119 language, even lowercased, except for > > > normative text - this seems to cause confusion from time to time. >But > > > please check with your shepherding AD to see if he agrees. > > > > > > admission control for the following service classes: > > > > > > o Telephony (EF) > > > > > > o Real-time interactive (CS4) > > > > > > o Broadcast Video (CS3) > > > > > > o Multimedia Conferencing (AF4) > > > > > > _______________________________________________ > > > Gen-art mailing list > > > Gen-art@ietf.org > > > https://www.ietf.org/mailman/listinfo/gen-art > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Wed Aug 26 00:06:13 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 97BFD3A6BEE for ; Wed, 26 Aug 2009 00:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 roQ5eVkEZMJd for ; Wed, 26 Aug 2009 00:06:12 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 6BAAC3A6A1C for ; Wed, 26 Aug 2009 00:06:10 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 26 Aug 2009 09:06: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); Wed, 26 Aug 2009 09:06:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 09:06:08 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <20090825184229.CDB2EBEF4@mwinf5909> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 thread-index: Acolw8tAYOODYcS8Rxio/So3rwHmLQAVmxQw References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> From: To: , X-OriginalArrivalTime: 26 Aug 2009 07:06:10.0954 (UTC) FILETIME=[B107EEA0:01CA261B] Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 07:06:13 -0000 Toby, Bob if the abstract is to mention PCN functionalities not defined within this document in a rather simplified way, would the purpose of PCN=20 be to enable a Diffserv domain to support measurement based=20 admission control as defined by PCN architecture? Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Bob Briscoe Sent: Tuesday, August 25, 2009 8:42 PM To: toby.moncaster@bt.com; pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review = ofdraft-ietf-pcn-baseline-encoding-05 Toby, I think this isn't just good for a casual reader, but it is actually=20 still correct and doesn't require defining PC-domain (which is just=20 the Diffserv domain once the described measures - the PDB - have been=20 put in place). Bob At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >This potentially raises an issue for all future PCN documents since the >abstract was based on our agreed standard elevator-pitch introduction = to >PCN... Specifically Spencer raises the question of using the defined >term PCN-domain in the abstract. Any thoughts from anyone as to whether >this is confusing? Would it be clearer to just use "domain" (e.g. drop >the "PCN-"). In which case should I alter the whole abstract as follows >(note: I realise this is strictly incorrect as it now doesn't seek to >distinguish the non-PCN and PCN traffic from each other but is this >clearer for a casual reader?): > > The objective of Pre-Congestion Notification (PCN) is to protect = the > quality of service (QoS) of inelastic flows within a Diffserv = domain. > The overall rate of the traffic is metered on every link in the > domain, and packets are appropriately marked when certain > configured rates are exceeded. Boundary nodes can measure the = level > of marking and thus make decisions about whether to admit or block = a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. The > baseline encoding described here provides for only two PCN encoding > states, Not-marked and PCN-marked. > >Toby > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of > > Lars Eggert > > Sent: 25 August 2009 15:12 > > To: pcn@ietf.org > > Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >ofdraft-ietf-pcn-baseline- > > encoding-05 > > > > > > > > Begin forwarded message: > > > > > From: Spencer Dawkins > > > Date: August 25, 2009 14:47:49 GMT+02:00 > > > To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > > pcn-baseline-encoding@tools.ietf.org > > > > > > > Cc: General Area Review Team , > > "ietf@ietf.org > > > " > > > Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > > > encoding-05 > > > > > > I have been selected as the General Area Review Team (Gen-ART) > > > reviewer for this draft (for background on Gen-ART, please see > > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > > > > > Please wait for direction from your document shepherd or AD before > > > posting a new version of the draft. > > > > > > Document: draft-ietf-pcn-baseline-encoding-05 > > > Reviewer: Spencer Dawkins > > > IETF LC End Date: 2009-09-03 > > > Review Date: 2009-08-21 > > > IESG Telechat date: (not known) > > > > > > Summary: this specification is almost ready for publication as a > > > Proposed Standard. I have one minor question below (flagged as > > > "Spencer (minor)"), along with some editorial suggestions to be > > > considered when this document is edited (either in the working = group > > > or by the RFC Editor). > > > > > > Abstract > > > > > > The objective of Pre-Congestion Notification (PCN) is to protect > > the > > > quality of service (QoS) of inelastic flows within a Diffserv > > > domain. > > > > > > Spencer (clarity): I'm not sure what the relationship between a > > > Diffserv domain and a PCN-domain is - this couuld be clearer, > > > especially in an Abstract. I note that RFC 5559 doesn't use the = term > > > PCN-domain in its Abstract ... I can guess, but I'm just guessing. > > > > > > The overall rate of the PCN-traffic is metered on every link in >the > > > PCN-domain, and PCN-packets are appropriately marked when = certain > > > configured rates are exceeded. The level of marking allows the > > > boundary nodes to make decisions about whether to admit or block = a > > > new flow request, and (in abnormal circumstances) whether to > > > terminate some of the existing flows, thereby protecting the QoS >of > > > previously admitted flows. This document specifies how such = marks > > > are to be encoded into the IP header by re-using the Explicit > > > Congestion Notification (ECN) codepoints within this controlled > > > domain. The baseline encoding described here provides for only >two > > > PCN encoding states, Not-marked and PCN-marked. > > > > > > 4. Encoding two PCN States in IP > > > > > > The following rules apply to all PCN traffic: > > > > > > o PCN-traffic MUST be marked with a PCN-compatible Diffserv > > > Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > > > chosen that are already defined for use with admission > > controlled > > > traffic. Appendix A.1 gives guidance to implementiors on > > > suitable > > > > > > Spencer (clarity): s/implementiors/implementers/? > > > > > > DSCPs. Guidelines for mixing traffic-types within a = PCN-domain > > > are given in [I-D.ietf-pcn-marking-behaviour]. > > > > > > o Any packet that is not-PCN but which shares the same Diffserv > > > codepoint as PCN-enabled traffic MUST have the ECN field of = its > > > outermost IP header equal to 00. > > > > > > Spencer (minor): this is the only point in the specification (that = I > > > can > > > find) that makes reference to the "outermost IP header". I'm not >sure > > > whether to suggest s/outermost// here or to ask that a statement = be > > > added earlier in the document to clearly state that PCN encoding >only > > > protects inelastic traffic when it's used for the outermost IP > > header, > > > but the current text seems to call attention to this in a way that > > > makes the reader wonder what is special about THIS requirement = that > > > isn't true of the other requirements listed. > > > > > > 4.3. PCN-Compatible Diffserv Codepoints > > > > > > Enabling PCN marking behaviour for a specific DSCP disables any > > > other > > > marking behaviour (e.g. enabling PCN disables the default ECN > > > marking > > > behaviour introduced in [RFC3168]). All traffic metering and > > > marking > > > > > > Spencer (clarity): here, and in Section 6, the text uses = "disables" > > to > > > describe the relationship between PCN and ECN. If I understand the > > > point, the domain is substituting one behavior for another. I = might > > > suggest "replaces" to describe the relationship in both locations. > > > > > > behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >This > > > ensures compliance with the BCP guidance set out in [RFC4774]. > > > > > > 4.3.1. Co-existence of PCN and not-PCN traffic > > > > > > The scarcity of pool 1 DSCPs coupled with the fact that PCN is > > > envisaged as a marking behaviour that could be applied to a = number > > > of > > > different DSCPs makes it essential that we provide a not-PCN >state. > > > As stated above (and expanded in Appendix A.1) the aim is for = PCN > > to > > > re-use existing DSCPs. Because PCN re-defines the meaning of = the > > > ECN > > > > > > Spencer (clarity): here, the text uses "re-defines", which I like > > > better than "disables", but if you go for "replaces" previously = and > > in > > > section 6, you might want to use the same wording here. > > > > > > field for such DSCPs it is important to allow an operator to = still > > > use the DSCP for traffic that isn't PCN-enabled. This is = achieved > > > by > > > providing a not-PCN state within the encoding scheme. > > > > > > A.1. Choice of Suitable DSCPs > > > > > > The PCN Working Group chose not to define a single DSCP for use > > with > > > PCN for several reasons. Firstly the PCN mechanism is = applicable > > to > > > a variety of different traffic classes. Secondly standards = track > > > DSCPs are in increasingly short supply. Thirdly PCN should be >seen > > > as being essentially a marking behaviour similar to ECN but > > intended > > > for inelastic traffic. The choice of which DSCP is most = suitable > > > for > > > a given PCN-domain is dependent on the nature of the traffic > > > entering > > > that domain and the link rates of all the links making up that > > > domain. In PCN-domains with uniformly high link rates, the > > > appropriate DSCPs would currently be those for the Real Time > > Traffic > > > Class [RFC5127]. To be clear the PCN Working Group recommends > > using > > > > > > Spencer (clarity): is this 2119 language (apparently not, since = this > > > section is not normative), or are you saying "suggests"? My > > suggestion > > > is that we not use 2119 language, even lowercased, except for > > > normative text - this seems to cause confusion from time to time. >But > > > please check with your shepherding AD to see if he agrees. > > > > > > admission control for the following service classes: > > > > > > o Telephony (EF) > > > > > > o Real-time interactive (CS4) > > > > > > o Broadcast Video (CS3) > > > > > > o Multimedia Conferencing (AF4) > > > > > > _______________________________________________ > > > Gen-art mailing list > > > Gen-art@ietf.org > > > https://www.ietf.org/mailman/listinfo/gen-art > >_______________________________________________ >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 menth@informatik.uni-wuerzburg.de Wed Aug 26 00:46:40 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F503A6A57 for ; Wed, 26 Aug 2009 00:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_OBFU_COULD=0.917] 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 TUKkR-F+aCo7 for ; Wed, 26 Aug 2009 00:46:39 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 89FC33A69E9 for ; Wed, 26 Aug 2009 00:46:38 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3D1D61997BA; Wed, 26 Aug 2009 09:46:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2F486199608; Wed, 26 Aug 2009 09:46:41 +0200 (CEST) Received: from [192.168.1.2] (f051180052.adsl.alicedsl.de [78.51.180.52]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B51D7A0F1F; Wed, 26 Aug 2009 09:46:40 +0200 (CEST) Message-ID: <4A94E830.906@informatik.uni-wuerzburg.de> Date: Wed, 26 Aug 2009 09:45:52 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 07:46:40 -0000 Hi all, Rüdiger touches an issue that I also feel is not optimally solved in the current abstract. The objective of PCN is provide marking information to egress node and the objective of admission control and flow termination is to protect QoS. I use the following short explanation for PCN. Maybe this idea could be added to the current abstract. Pre-congestion notification (PCN) is a metering and marking scheme for Differentiated Services (DiffServ) IP networks which provides egress nodes with information about load conditions inside the network \cite{RFC5559}. This information is used for admission control and flow termination to support quality of service (QoS) for admitted inelastic realtime flows that are carried with prioritization within the DiffServ domain. This document specifies how nodes encode the marking information in the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a controlled DiffServ domain. The baseline encoding described here provides for only two PCN encoding states which are not-marked and PCN-marked. Regards, Michael Ruediger.Geib@telekom.de schrieb: > Toby, Bob > > if the abstract is to mention PCN functionalities not defined within > this document in a rather simplified way, would the purpose of PCN > be to enable a Diffserv domain to support measurement based > admission control as defined by PCN architecture? > > Regards, > > Ruediger > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Bob Briscoe > Sent: Tuesday, August 25, 2009 8:42 PM > To: toby.moncaster@bt.com; pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 > > Toby, > > I think this isn't just good for a casual reader, but it is actually > still correct and doesn't require defining PC-domain (which is just > the Diffserv domain once the described measures - the PDB - have been > put in place). > > > Bob > > At 15:53 25/08/2009, toby.moncaster@bt.com wrote: > >> This potentially raises an issue for all future PCN documents since the >> abstract was based on our agreed standard elevator-pitch introduction to >> PCN... Specifically Spencer raises the question of using the defined >> term PCN-domain in the abstract. Any thoughts from anyone as to whether >> this is confusing? Would it be clearer to just use "domain" (e.g. drop >> the "PCN-"). In which case should I alter the whole abstract as follows >> (note: I realise this is strictly incorrect as it now doesn't seek to >> distinguish the non-PCN and PCN traffic from each other but is this >> clearer for a casual reader?): >> >> The objective of Pre-Congestion Notification (PCN) is to protect the >> quality of service (QoS) of inelastic flows within a Diffserv domain. >> The overall rate of the traffic is metered on every link in the >> domain, and packets are appropriately marked when certain >> configured rates are exceeded. Boundary nodes can measure the level >> of marking and thus make decisions about whether to admit or block a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS of >> previously admitted flows. This document specifies how such marks >> are encoded into the IP header by re-using the Explicit Congestion >> Notification (ECN) codepoints within this controlled domain. The >> baseline encoding described here provides for only two PCN encoding >> states, Not-marked and PCN-marked. >> >> Toby >> >> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>> Lars Eggert >>> Sent: 25 August 2009 15:12 >>> To: pcn@ietf.org >>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>> >> ofdraft-ietf-pcn-baseline- >> >>> encoding-05 >>> >>> >>> >>> Begin forwarded message: >>> >>> >>>> From: Spencer Dawkins >>>> Date: August 25, 2009 14:47:49 GMT+02:00 >>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>> >> > >>> pcn-baseline-encoding@tools.ietf.org >>> >>>> Cc: General Area Review Team , >>>> >>> "ietf@ietf.org >>> >>>> " >>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>> encoding-05 >>>> >>>> I have been selected as the General Area Review Team (Gen-ART) >>>> reviewer for this draft (for background on Gen-ART, please see >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>> >>>> Please wait for direction from your document shepherd or AD before >>>> posting a new version of the draft. >>>> >>>> Document: draft-ietf-pcn-baseline-encoding-05 >>>> Reviewer: Spencer Dawkins >>>> IETF LC End Date: 2009-09-03 >>>> Review Date: 2009-08-21 >>>> IESG Telechat date: (not known) >>>> >>>> Summary: this specification is almost ready for publication as a >>>> Proposed Standard. I have one minor question below (flagged as >>>> "Spencer (minor)"), along with some editorial suggestions to be >>>> considered when this document is edited (either in the working group >>>> or by the RFC Editor). >>>> >>>> Abstract >>>> >>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>> >>> the >>> >>>> quality of service (QoS) of inelastic flows within a Diffserv >>>> domain. >>>> >>>> Spencer (clarity): I'm not sure what the relationship between a >>>> Diffserv domain and a PCN-domain is - this couuld be clearer, >>>> especially in an Abstract. I note that RFC 5559 doesn't use the term >>>> PCN-domain in its Abstract ... I can guess, but I'm just guessing. >>>> >>>> The overall rate of the PCN-traffic is metered on every link in >>>> >> the >> >>>> PCN-domain, and PCN-packets are appropriately marked when certain >>>> configured rates are exceeded. The level of marking allows the >>>> boundary nodes to make decisions about whether to admit or block a >>>> new flow request, and (in abnormal circumstances) whether to >>>> terminate some of the existing flows, thereby protecting the QoS >>>> >> of >> >>>> previously admitted flows. This document specifies how such marks >>>> are to be encoded into the IP header by re-using the Explicit >>>> Congestion Notification (ECN) codepoints within this controlled >>>> domain. The baseline encoding described here provides for only >>>> >> two >> >>>> PCN encoding states, Not-marked and PCN-marked. >>>> >>>> 4. Encoding two PCN States in IP >>>> >>>> The following rules apply to all PCN traffic: >>>> >>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be >>>> chosen that are already defined for use with admission >>>> >>> controlled >>> >>>> traffic. Appendix A.1 gives guidance to implementiors on >>>> suitable >>>> >>>> Spencer (clarity): s/implementiors/implementers/? >>>> >>>> DSCPs. Guidelines for mixing traffic-types within a PCN-domain >>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>> >>>> o Any packet that is not-PCN but which shares the same Diffserv >>>> codepoint as PCN-enabled traffic MUST have the ECN field of its >>>> outermost IP header equal to 00. >>>> >>>> Spencer (minor): this is the only point in the specification (that I >>>> can >>>> find) that makes reference to the "outermost IP header". I'm not >>>> >> sure >> >>>> whether to suggest s/outermost// here or to ask that a statement be >>>> added earlier in the document to clearly state that PCN encoding >>>> >> only >> >>>> protects inelastic traffic when it's used for the outermost IP >>>> >>> header, >>> >>>> but the current text seems to call attention to this in a way that >>>> makes the reader wonder what is special about THIS requirement that >>>> isn't true of the other requirements listed. >>>> >>>> 4.3. PCN-Compatible Diffserv Codepoints >>>> >>>> Enabling PCN marking behaviour for a specific DSCP disables any >>>> other >>>> marking behaviour (e.g. enabling PCN disables the default ECN >>>> marking >>>> behaviour introduced in [RFC3168]). All traffic metering and >>>> marking >>>> >>>> Spencer (clarity): here, and in Section 6, the text uses "disables" >>>> >>> to >>> >>>> describe the relationship between PCN and ECN. If I understand the >>>> point, the domain is substituting one behavior for another. I might >>>> suggest "replaces" to describe the relationship in both locations. >>>> >>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >>>> >> This >> >>>> ensures compliance with the BCP guidance set out in [RFC4774]. >>>> >>>> 4.3.1. Co-existence of PCN and not-PCN traffic >>>> >>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >>>> envisaged as a marking behaviour that could be applied to a number >>>> of >>>> different DSCPs makes it essential that we provide a not-PCN >>>> >> state. >> >>>> As stated above (and expanded in Appendix A.1) the aim is for PCN >>>> >>> to >>> >>>> re-use existing DSCPs. Because PCN re-defines the meaning of the >>>> ECN >>>> >>>> Spencer (clarity): here, the text uses "re-defines", which I like >>>> better than "disables", but if you go for "replaces" previously and >>>> >>> in >>> >>>> section 6, you might want to use the same wording here. >>>> >>>> field for such DSCPs it is important to allow an operator to still >>>> use the DSCP for traffic that isn't PCN-enabled. This is achieved >>>> by >>>> providing a not-PCN state within the encoding scheme. >>>> >>>> A.1. Choice of Suitable DSCPs >>>> >>>> The PCN Working Group chose not to define a single DSCP for use >>>> >>> with >>> >>>> PCN for several reasons. Firstly the PCN mechanism is applicable >>>> >>> to >>> >>>> a variety of different traffic classes. Secondly standards track >>>> DSCPs are in increasingly short supply. Thirdly PCN should be >>>> >> seen >> >>>> as being essentially a marking behaviour similar to ECN but >>>> >>> intended >>> >>>> for inelastic traffic. The choice of which DSCP is most suitable >>>> for >>>> a given PCN-domain is dependent on the nature of the traffic >>>> entering >>>> that domain and the link rates of all the links making up that >>>> domain. In PCN-domains with uniformly high link rates, the >>>> appropriate DSCPs would currently be those for the Real Time >>>> >>> Traffic >>> >>>> Class [RFC5127]. To be clear the PCN Working Group recommends >>>> >>> using >>> >>>> Spencer (clarity): is this 2119 language (apparently not, since this >>>> section is not normative), or are you saying "suggests"? My >>>> >>> suggestion >>> >>>> is that we not use 2119 language, even lowercased, except for >>>> normative text - this seems to cause confusion from time to time. >>>> >> But >> >>>> please check with your shepherding AD to see if he agrees. >>>> >>>> admission control for the following service classes: >>>> >>>> o Telephony (EF) >>>> >>>> o Real-time interactive (CS4) >>>> >>>> o Broadcast Video (CS3) >>>> >>>> o Multimedia Conferencing (AF4) >>>> >>>> _______________________________________________ >>>> Gen-art mailing list >>>> Gen-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/gen-art >>>> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- 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 Wed Aug 26 01:55:00 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 D24AB3A6FA6 for ; Wed, 26 Aug 2009 01:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.413 X-Spam-Level: X-Spam-Status: No, score=0.413 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SARE_OBFU_COULD=0.917] 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 EY-ipWlCuRiW for ; Wed, 26 Aug 2009 01:54:59 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 339753A67AE for ; Wed, 26 Aug 2009 01:54:59 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id n7Q8ssl8025098; Wed, 26 Aug 2009 10:54:58 +0200 (MEST) From: "Georgios Karagiannis" To: "'Tom Taylor'" , References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <4A942F95.90309@rogers.com> Date: Wed, 26 Aug 2009 10:54:50 +0200 Message-ID: <000401ca262a$e31a1620$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acols0RgAIMW0XjWSsKCrLP3HtgUTwAdx2cg In-Reply-To: <4A942F95.90309@rogers.com> X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Aug 2009 10:55:02 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ARTReview ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 08:55:00 -0000 Hi all I think that the text provided by Toby on replacing the term PCN domain in the Abstract together with the addition proposed by Tom makes sense. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: dinsdag 25 augustus 2009 20:38 > To: toby.moncaster@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ARTReview > ofdraft-ietf-pcn-baseline-encoding-05 > > How about adding "PCN" in front of "traffic" in: "The overall > rate of the traffic is metered ...", and in front of each > instance of "flow"? > > toby.moncaster@bt.com wrote: > > This potentially raises an issue for all future PCN documents since > > the abstract was based on our agreed standard elevator-pitch > > introduction to PCN... Specifically Spencer raises the question of > > using the defined term PCN-domain in the abstract. Any > thoughts from > > anyone as to whether this is confusing? Would it be clearer to just > > use "domain" (e.g. drop the "PCN-"). In which case should I > alter the > > whole abstract as follows > > (note: I realise this is strictly incorrect as it now > doesn't seek to > > distinguish the non-PCN and PCN traffic from each other but is this > > clearer for a casual reader?): > > > > The objective of Pre-Congestion Notification (PCN) is to > protect the > > quality of service (QoS) of inelastic flows within a > Diffserv domain. > > The overall rate of the traffic is metered on every link in the > > domain, and packets are appropriately marked when certain > > configured rates are exceeded. Boundary nodes can > measure the level > > of marking and thus make decisions about whether to > admit or block a > > new flow request, and (in abnormal circumstances) whether to > > terminate some of the existing flows, thereby protecting > the QoS of > > previously admitted flows. This document specifies how > such marks > > are encoded into the IP header by re-using the Explicit > Congestion > > Notification (ECN) codepoints within this controlled domain. The > > baseline encoding described here provides for only two > PCN encoding > > states, Not-marked and PCN-marked. > > > > Toby > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf Of > >> Lars Eggert > >> Sent: 25 August 2009 15:12 > >> To: pcn@ietf.org > >> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > > ofdraft-ietf-pcn-baseline- > >> encoding-05 > >> > >> > >> > >> Begin forwarded message: > >> > >>> From: Spencer Dawkins > >>> Date: August 25, 2009 14:47:49 GMT+02:00 > >>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > > >> pcn-baseline-encoding@tools.ietf.org > >>> Cc: General Area Review Team , > >> "ietf@ietf.org > >>> " > >>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > >>> encoding-05 > >>> > >>> I have been selected as the General Area Review Team (Gen-ART) > >>> reviewer for this draft (for background on Gen-ART, please see > >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >>> > >>> Please wait for direction from your document shepherd or > AD before > >>> posting a new version of the draft. > >>> > >>> Document: draft-ietf-pcn-baseline-encoding-05 > >>> Reviewer: Spencer Dawkins > >>> IETF LC End Date: 2009-09-03 > >>> Review Date: 2009-08-21 > >>> IESG Telechat date: (not known) > >>> > >>> Summary: this specification is almost ready for publication as a > >>> Proposed Standard. I have one minor question below (flagged as > >>> "Spencer (minor)"), along with some editorial suggestions to be > >>> considered when this document is edited (either in the > working group > >>> or by the RFC Editor). > >>> > >>> Abstract > >>> > >>> The objective of Pre-Congestion Notification (PCN) is to protect > >> the > >>> quality of service (QoS) of inelastic flows within a Diffserv > >>> domain. > >>> > >>> Spencer (clarity): I'm not sure what the relationship between a > >>> Diffserv domain and a PCN-domain is - this couuld be clearer, > >>> especially in an Abstract. I note that RFC 5559 doesn't > use the term > >>> PCN-domain in its Abstract ... I can guess, but I'm just guessing. > >>> > >>> The overall rate of the PCN-traffic is metered on every link in > > the > >>> PCN-domain, and PCN-packets are appropriately marked > when certain > >>> configured rates are exceeded. The level of marking allows the > >>> boundary nodes to make decisions about whether to admit > or block a > >>> new flow request, and (in abnormal circumstances) whether to > >>> terminate some of the existing flows, thereby protecting the QoS > > of > >>> previously admitted flows. This document specifies how > such marks > >>> are to be encoded into the IP header by re-using the Explicit > >>> Congestion Notification (ECN) codepoints within this controlled > >>> domain. The baseline encoding described here provides for only > > two > >>> PCN encoding states, Not-marked and PCN-marked. > >>> > >>> 4. Encoding two PCN States in IP > >>> > >>> The following rules apply to all PCN traffic: > >>> > >>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv > >>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > >>> chosen that are already defined for use with admission > >> controlled > >>> traffic. Appendix A.1 gives guidance to implementiors on > >>> suitable > >>> > >>> Spencer (clarity): s/implementiors/implementers/? > >>> > >>> DSCPs. Guidelines for mixing traffic-types within a > PCN-domain > >>> are given in [I-D.ietf-pcn-marking-behaviour]. > >>> > >>> o Any packet that is not-PCN but which shares the same Diffserv > >>> codepoint as PCN-enabled traffic MUST have the ECN > field of its > >>> outermost IP header equal to 00. > >>> > >>> Spencer (minor): this is the only point in the > specification (that I > >>> can > >>> find) that makes reference to the "outermost IP header". I'm not > > sure > >>> whether to suggest s/outermost// here or to ask that a > statement be > >>> added earlier in the document to clearly state that PCN encoding > > only > >>> protects inelastic traffic when it's used for the outermost IP > >> header, > >>> but the current text seems to call attention to this in a > way that > >>> makes the reader wonder what is special about THIS > requirement that > >>> isn't true of the other requirements listed. > >>> > >>> 4.3. PCN-Compatible Diffserv Codepoints > >>> > >>> Enabling PCN marking behaviour for a specific DSCP disables any > >>> other > >>> marking behaviour (e.g. enabling PCN disables the default ECN > >>> marking > >>> behaviour introduced in [RFC3168]). All traffic metering and > >>> marking > >>> > >>> Spencer (clarity): here, and in Section 6, the text uses > "disables" > >> to > >>> describe the relationship between PCN and ECN. If I > understand the > >>> point, the domain is substituting one behavior for > another. I might > >>> suggest "replaces" to describe the relationship in both locations. > >>> > >>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > > This > >>> ensures compliance with the BCP guidance set out in [RFC4774]. > >>> > >>> 4.3.1. Co-existence of PCN and not-PCN traffic > >>> > >>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is > >>> envisaged as a marking behaviour that could be applied > to a number > >>> of > >>> different DSCPs makes it essential that we provide a not-PCN > > state. > >>> As stated above (and expanded in Appendix A.1) the aim > is for PCN > >> to > >>> re-use existing DSCPs. Because PCN re-defines the > meaning of the > >>> ECN > >>> > >>> Spencer (clarity): here, the text uses "re-defines", which I like > >>> better than "disables", but if you go for "replaces" > previously and > >> in > >>> section 6, you might want to use the same wording here. > >>> > >>> field for such DSCPs it is important to allow an > operator to still > >>> use the DSCP for traffic that isn't PCN-enabled. This > is achieved > >>> by > >>> providing a not-PCN state within the encoding scheme. > >>> > >>> A.1. Choice of Suitable DSCPs > >>> > >>> The PCN Working Group chose not to define a single DSCP for use > >> with > >>> PCN for several reasons. Firstly the PCN mechanism is > applicable > >> to > >>> a variety of different traffic classes. Secondly > standards track > >>> DSCPs are in increasingly short supply. Thirdly PCN should be > > seen > >>> as being essentially a marking behaviour similar to ECN but > >> intended > >>> for inelastic traffic. The choice of which DSCP is > most suitable > >>> for > >>> a given PCN-domain is dependent on the nature of the traffic > >>> entering > >>> that domain and the link rates of all the links making up that > >>> domain. In PCN-domains with uniformly high link rates, the > >>> appropriate DSCPs would currently be those for the Real Time > >> Traffic > >>> Class [RFC5127]. To be clear the PCN Working Group recommends > >> using > >>> Spencer (clarity): is this 2119 language (apparently not, > since this > >>> section is not normative), or are you saying "suggests"? My > >> suggestion > >>> is that we not use 2119 language, even lowercased, except for > >>> normative text - this seems to cause confusion from time to time. > > But > >>> please check with your shepherding AD to see if he agrees. > >>> > >>> admission control for the following service classes: > >>> > >>> o Telephony (EF) > >>> > >>> o Real-time interactive (CS4) > >>> > >>> o Broadcast Video (CS3) > >>> > >>> o Multimedia Conferencing (AF4) > >>> > >>> _______________________________________________ > >>> Gen-art mailing list > >>> Gen-art@ietf.org > >>> https://www.ietf.org/mailman/listinfo/gen-art > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From toby.moncaster@bt.com Wed Aug 26 04:14:15 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5FC3A6B6F for ; Wed, 26 Aug 2009 04:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 sfHxJMoe4N0T for ; Wed, 26 Aug 2009 04:14:13 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D3ADC3A6CEA for ; Wed, 26 Aug 2009 04:14:11 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:13:55 +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: Wed, 26 Aug 2009 12:12:55 +0100 Message-ID: In-Reply-To: <4A94E830.906@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcomIV4kyKiY+iXvQYu1/Asfi7Sj6wAG9oNw References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> From: To: , X-OriginalArrivalTime: 26 Aug 2009 11:13:55.0473 (UTC) FILETIME=[4CF98810:01CA263E] Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 11:14:15 -0000 So would the following sound better? : Pre-Congestion Notification (PCN) is a metering and marking scheme=20 that protects the quality of service (QoS) of inelastic flows within=20 a Diffserv domain. The overall rate of the traffic is metered on = every=20 link in the domain, and packets are appropriately marked when certain configured rates are exceeded. Boundary nodes can measure the level of marking and thus make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked. Just for clarity here was the earlier version I proposed: The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the traffic is metered on every link in the domain, and packets are appropriately marked when certain configured rates are exceeded. Boundary nodes can measure the level of marking and thus make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked. I personally disagree with Tom's suggestion to add PCN to all the = defined=20 terms (e.g. PCN flow, PCN traffic) - that is fine within the body of the = document but in this abstract we should avoid using any terms that = readers won't be already familiar with. > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 26 August 2009 08:46 > To: Ruediger.Geib@telekom.de > Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 >=20 > Hi all, >=20 > R=FCdiger touches an issue that I also feel is not optimally solved in > the > current abstract. The objective of PCN is provide marking information > to > egress node and the objective of admission control and flow = termination > is to protect QoS. I use the following short explanation for PCN. = Maybe > this idea could be added to the current abstract. >=20 > Pre-congestion notification (PCN) is a metering and marking scheme for > Differentiated Services (DiffServ) IP networks which provides egress > nodes with information about load conditions inside the network > \cite{RFC5559}. This information is used for admission control and = flow > termination to support quality of service (QoS) for admitted inelastic > realtime flows that are carried with prioritization within the = DiffServ > domain. > This document specifies how nodes encode the marking information in = the > IP header by re-using the Explicit Congestion Notification (ECN) > codepoints within a controlled DiffServ domain. The baseline encoding > described here provides for only two PCN encoding states which are > not-marked and PCN-marked. >=20 > Regards, >=20 > Michael >=20 > Ruediger.Geib@telekom.de schrieb: > > Toby, Bob > > > > if the abstract is to mention PCN functionalities not defined within > > this document in a rather simplified way, would the purpose of PCN > > be to enable a Diffserv domain to support measurement based > > admission control as defined by PCN architecture? > > > > Regards, > > > > Ruediger > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of > Bob Briscoe > > Sent: Tuesday, August 25, 2009 8:42 PM > > To: toby.moncaster@bt.com; pcn@ietf.org > > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 > > > > Toby, > > > > I think this isn't just good for a casual reader, but it is actually > > still correct and doesn't require defining PC-domain (which is just > > the Diffserv domain once the described measures - the PDB - have = been > > put in place). > > > > > > Bob > > > > At 15:53 25/08/2009, toby.moncaster@bt.com wrote: > > > >> This potentially raises an issue for all future PCN documents since > the > >> abstract was based on our agreed standard elevator-pitch > introduction to > >> PCN... Specifically Spencer raises the question of using the = defined > >> term PCN-domain in the abstract. Any thoughts from anyone as to > whether > >> this is confusing? Would it be clearer to just use "domain" (e.g. > drop > >> the "PCN-"). In which case should I alter the whole abstract as > follows > >> (note: I realise this is strictly incorrect as it now doesn't seek > to > >> distinguish the non-PCN and PCN traffic from each other but is this > >> clearer for a casual reader?): > >> > >> The objective of Pre-Congestion Notification (PCN) is to protect > the > >> quality of service (QoS) of inelastic flows within a Diffserv > domain. > >> The overall rate of the traffic is metered on every link in the > >> domain, and packets are appropriately marked when certain > >> configured rates are exceeded. Boundary nodes can measure the > level > >> of marking and thus make decisions about whether to admit or > block a > >> new flow request, and (in abnormal circumstances) whether to > >> terminate some of the existing flows, thereby protecting the QoS > of > >> previously admitted flows. This document specifies how such > marks > >> are encoded into the IP header by re-using the Explicit > Congestion > >> Notification (ECN) codepoints within this controlled domain. = The > >> baseline encoding described here provides for only two PCN > encoding > >> states, Not-marked and PCN-marked. > >> > >> Toby > >> > >> > >>> -----Original Message----- > >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > >>> Lars Eggert > >>> Sent: 25 August 2009 15:12 > >>> To: pcn@ietf.org > >>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > >>> > >> ofdraft-ietf-pcn-baseline- > >> > >>> encoding-05 > >>> > >>> > >>> > >>> Begin forwarded message: > >>> > >>> > >>>> From: Spencer Dawkins > >>>> Date: August 25, 2009 14:47:49 GMT+02:00 > >>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > >>>> > >> >> > >>> pcn-baseline-encoding@tools.ietf.org > >>> > >>>> Cc: General Area Review Team , > >>>> > >>> "ietf@ietf.org > >>> > >>>> " > >>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > >>>> encoding-05 > >>>> > >>>> I have been selected as the General Area Review Team (Gen-ART) > >>>> reviewer for this draft (for background on Gen-ART, please see > >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >>>> > >>>> Please wait for direction from your document shepherd or AD = before > >>>> posting a new version of the draft. > >>>> > >>>> Document: draft-ietf-pcn-baseline-encoding-05 > >>>> Reviewer: Spencer Dawkins > >>>> IETF LC End Date: 2009-09-03 > >>>> Review Date: 2009-08-21 > >>>> IESG Telechat date: (not known) > >>>> > >>>> Summary: this specification is almost ready for publication as a > >>>> Proposed Standard. I have one minor question below (flagged as > >>>> "Spencer (minor)"), along with some editorial suggestions to be > >>>> considered when this document is edited (either in the working > group > >>>> or by the RFC Editor). > >>>> > >>>> Abstract > >>>> > >>>> The objective of Pre-Congestion Notification (PCN) is to = protect > >>>> > >>> the > >>> > >>>> quality of service (QoS) of inelastic flows within a Diffserv > >>>> domain. > >>>> > >>>> Spencer (clarity): I'm not sure what the relationship between a > >>>> Diffserv domain and a PCN-domain is - this couuld be clearer, > >>>> especially in an Abstract. I note that RFC 5559 doesn't use the > term > >>>> PCN-domain in its Abstract ... I can guess, but I'm just = guessing. > >>>> > >>>> The overall rate of the PCN-traffic is metered on every link in > >>>> > >> the > >> > >>>> PCN-domain, and PCN-packets are appropriately marked when > certain > >>>> configured rates are exceeded. The level of marking allows the > >>>> boundary nodes to make decisions about whether to admit or = block > a > >>>> new flow request, and (in abnormal circumstances) whether to > >>>> terminate some of the existing flows, thereby protecting the = QoS > >>>> > >> of > >> > >>>> previously admitted flows. This document specifies how such > marks > >>>> are to be encoded into the IP header by re-using the Explicit > >>>> Congestion Notification (ECN) codepoints within this controlled > >>>> domain. The baseline encoding described here provides for only > >>>> > >> two > >> > >>>> PCN encoding states, Not-marked and PCN-marked. > >>>> > >>>> 4. Encoding two PCN States in IP > >>>> > >>>> The following rules apply to all PCN traffic: > >>>> > >>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv > >>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > >>>> chosen that are already defined for use with admission > >>>> > >>> controlled > >>> > >>>> traffic. Appendix A.1 gives guidance to implementiors on > >>>> suitable > >>>> > >>>> Spencer (clarity): s/implementiors/implementers/? > >>>> > >>>> DSCPs. Guidelines for mixing traffic-types within a PCN- > domain > >>>> are given in [I-D.ietf-pcn-marking-behaviour]. > >>>> > >>>> o Any packet that is not-PCN but which shares the same = Diffserv > >>>> codepoint as PCN-enabled traffic MUST have the ECN field of > its > >>>> outermost IP header equal to 00. > >>>> > >>>> Spencer (minor): this is the only point in the specification = (that > I > >>>> can > >>>> find) that makes reference to the "outermost IP header". I'm not > >>>> > >> sure > >> > >>>> whether to suggest s/outermost// here or to ask that a statement > be > >>>> added earlier in the document to clearly state that PCN encoding > >>>> > >> only > >> > >>>> protects inelastic traffic when it's used for the outermost IP > >>>> > >>> header, > >>> > >>>> but the current text seems to call attention to this in a way = that > >>>> makes the reader wonder what is special about THIS requirement > that > >>>> isn't true of the other requirements listed. > >>>> > >>>> 4.3. PCN-Compatible Diffserv Codepoints > >>>> > >>>> Enabling PCN marking behaviour for a specific DSCP disables any > >>>> other > >>>> marking behaviour (e.g. enabling PCN disables the default ECN > >>>> marking > >>>> behaviour introduced in [RFC3168]). All traffic metering and > >>>> marking > >>>> > >>>> Spencer (clarity): here, and in Section 6, the text uses > "disables" > >>>> > >>> to > >>> > >>>> describe the relationship between PCN and ECN. If I understand = the > >>>> point, the domain is substituting one behavior for another. I > might > >>>> suggest "replaces" to describe the relationship in both = locations. > >>>> > >>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > >>>> > >> This > >> > >>>> ensures compliance with the BCP guidance set out in [RFC4774]. > >>>> > >>>> 4.3.1. Co-existence of PCN and not-PCN traffic > >>>> > >>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is > >>>> envisaged as a marking behaviour that could be applied to a > number > >>>> of > >>>> different DSCPs makes it essential that we provide a not-PCN > >>>> > >> state. > >> > >>>> As stated above (and expanded in Appendix A.1) the aim is for > PCN > >>>> > >>> to > >>> > >>>> re-use existing DSCPs. Because PCN re-defines the meaning of > the > >>>> ECN > >>>> > >>>> Spencer (clarity): here, the text uses "re-defines", which I like > >>>> better than "disables", but if you go for "replaces" previously > and > >>>> > >>> in > >>> > >>>> section 6, you might want to use the same wording here. > >>>> > >>>> field for such DSCPs it is important to allow an operator to > still > >>>> use the DSCP for traffic that isn't PCN-enabled. This is > achieved > >>>> by > >>>> providing a not-PCN state within the encoding scheme. > >>>> > >>>> A.1. Choice of Suitable DSCPs > >>>> > >>>> The PCN Working Group chose not to define a single DSCP for use > >>>> > >>> with > >>> > >>>> PCN for several reasons. Firstly the PCN mechanism is > applicable > >>>> > >>> to > >>> > >>>> a variety of different traffic classes. Secondly standards > track > >>>> DSCPs are in increasingly short supply. Thirdly PCN should be > >>>> > >> seen > >> > >>>> as being essentially a marking behaviour similar to ECN but > >>>> > >>> intended > >>> > >>>> for inelastic traffic. The choice of which DSCP is most > suitable > >>>> for > >>>> a given PCN-domain is dependent on the nature of the traffic > >>>> entering > >>>> that domain and the link rates of all the links making up that > >>>> domain. In PCN-domains with uniformly high link rates, the > >>>> appropriate DSCPs would currently be those for the Real Time > >>>> > >>> Traffic > >>> > >>>> Class [RFC5127]. To be clear the PCN Working Group recommends > >>>> > >>> using > >>> > >>>> Spencer (clarity): is this 2119 language (apparently not, since > this > >>>> section is not normative), or are you saying "suggests"? My > >>>> > >>> suggestion > >>> > >>>> is that we not use 2119 language, even lowercased, except for > >>>> normative text - this seems to cause confusion from time to time. > >>>> > >> But > >> > >>>> please check with your shepherding AD to see if he agrees. > >>>> > >>>> admission control for the following service classes: > >>>> > >>>> o Telephony (EF) > >>>> > >>>> o Real-time interactive (CS4) > >>>> > >>>> o Broadcast Video (CS3) > >>>> > >>>> o Multimedia Conferencing (AF4) > >>>> > >>>> _______________________________________________ > >>>> Gen-art mailing list > >>>> Gen-art@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/gen-art > >>>> > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcn > >> > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > >=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 toby.moncaster@bt.com Wed Aug 26 04:15:40 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98AD3A6DB3 for ; Wed, 26 Aug 2009 04:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 vGIXSxU-bzuq for ; Wed, 26 Aug 2009 04:15:39 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 38DD43A693C for ; Wed, 26 Aug 2009 04:15:39 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:14:57 +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, 26 Aug 2009 12:14:36 +0100 Message-ID: In-Reply-To: <20090825183650.F3EE6B874@mwinf5909> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05 Thread-Index: AcolswkGw5DCz2mGTdaHeeWlF19KcgAiycgA References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825183650.F3EE6B874@mwinf5909> From: To: X-OriginalArrivalTime: 26 Aug 2009 11:14:57.0038 (UTC) FILETIME=[71AB9AE0:01CA263E] Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 11:15:40 -0000 Will add them to the list of changes I already have! I won't release a=20 version -06 until the end of the IETF LC in case we get any further=20 review comments... Toby > -----Original Message----- > From: Bob Briscoe [mailto:bob@homefarmparham.co.uk] > Sent: 25 August 2009 19:37 > To: Moncaster,T,Toby,DER3 R > Cc: Lars Eggert; pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn- > baseline-encoding-05 >=20 > Toby, >=20 > These all seem sensble requests and straightforward to fix. Are you > OK with dealing with these? >=20 >=20 >=20 > Bob >=20 > At 15:11 25/08/2009, Lars Eggert wrote: >=20 >=20 > >Begin forwarded message: > > > >>From: Spencer Dawkins > >>Date: August 25, 2009 14:47:49 GMT+02:00 > >>To: > >>"draft-ietf-pcn-baseline-encoding@tools.ietf.org" > >> > >>Cc: General Area Review Team > >>, "ietf@ietf.org " > >>Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > encoding-05 > >> > >>I have been selected as the General Area Review Team (Gen-ART) > >>reviewer for > >>this draft (for background on Gen-ART, please see > >>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >> > >>Please wait for direction from your document shepherd or AD before > >>posting a > >>new version of the draft. > >> > >>Document: draft-ietf-pcn-baseline-encoding-05 > >>Reviewer: Spencer Dawkins > >>IETF LC End Date: 2009-09-03 > >>Review Date: 2009-08-21 > >>IESG Telechat date: (not known) > >> > >>Summary: this specification is almost ready for publication as a > >>Proposed > >>Standard. I have one minor question below (flagged as "Spencer > >>(minor)"), > >>along with some editorial suggestions to be considered when this > >>document is > >>edited (either in the working group or by the RFC Editor). > >> > >>Abstract > >> > >> The objective of Pre-Congestion Notification (PCN) is to protect > the > >> quality of service (QoS) of inelastic flows within a Diffserv > >>domain. > >> > >>Spencer (clarity): I'm not sure what the relationship between a > >>Diffserv > >>domain and a PCN-domain is - this couuld be clearer, especially in an > >>Abstract. I note that RFC 5559 doesn't use the term PCN-domain in its > >>Abstract ... I can guess, but I'm just guessing. > >> > >> The overall rate of the PCN-traffic is metered on every link in > the > >> PCN-domain, and PCN-packets are appropriately marked when certain > >> configured rates are exceeded. The level of marking allows the > >> boundary nodes to make decisions about whether to admit or block a > >> new flow request, and (in abnormal circumstances) whether to > >> terminate some of the existing flows, thereby protecting the QoS > of > >> previously admitted flows. This document specifies how such marks > >> are to be encoded into the IP header by re-using the Explicit > >> Congestion Notification (ECN) codepoints within this controlled > >> domain. The baseline encoding described here provides for only > two > >> PCN encoding states, Not-marked and PCN-marked. > >> > >>4. Encoding two PCN States in IP > >> > >> The following rules apply to all PCN traffic: > >> > >> o PCN-traffic MUST be marked with a PCN-compatible Diffserv > >> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > >> chosen that are already defined for use with admission > controlled > >> traffic. Appendix A.1 gives guidance to implementiors on > >>suitable > >> > >>Spencer (clarity): s/implementiors/implementers/? > >> > >> DSCPs. Guidelines for mixing traffic-types within a PCN-domain > >> are given in [I-D.ietf-pcn-marking-behaviour]. > >> > >> o Any packet that is not-PCN but which shares the same Diffserv > >> codepoint as PCN-enabled traffic MUST have the ECN field of its > >> outermost IP header equal to 00. > >> > >>Spencer (minor): this is the only point in the specification (that I > >>can > >>find) that makes reference to the "outermost IP header". I'm not sure > >>whether to suggest s/outermost// here or to ask that a statement be > >>added > >>earlier in the document to clearly state that PCN encoding only > >>protects > >>inelastic traffic when it's used for the outermost IP header, but the > >>current text seems to call attention to this in a way that makes the > >>reader > >>wonder what is special about THIS requirement that isn't true of the > >>other > >>requirements listed. > >> > >>4.3. PCN-Compatible Diffserv Codepoints > >> > >> Enabling PCN marking behaviour for a specific DSCP disables any > >>other > >> marking behaviour (e.g. enabling PCN disables the default ECN > >>marking > >> behaviour introduced in [RFC3168]). All traffic metering and > >>marking > >> > >>Spencer (clarity): here, and in Section 6, the text uses "disables" > to > >>describe the relationship between PCN and ECN. If I understand the > >>point, > >>the domain is substituting one behavior for another. I might suggest > >>"replaces" to describe the relationship in both locations. > >> > >> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > This > >> ensures compliance with the BCP guidance set out in [RFC4774]. > >> > >>4.3.1. Co-existence of PCN and not-PCN traffic > >> > >> The scarcity of pool 1 DSCPs coupled with the fact that PCN is > >> envisaged as a marking behaviour that could be applied to a number > >>of > >> different DSCPs makes it essential that we provide a not-PCN > state. > >> As stated above (and expanded in Appendix A.1) the aim is for PCN > to > >> re-use existing DSCPs. Because PCN re-defines the meaning of the > >>ECN > >> > >>Spencer (clarity): here, the text uses "re-defines", which I like > >>better > >>than "disables", but if you go for "replaces" previously and in > >>section 6, > >>you might want to use the same wording here. > >> > >> field for such DSCPs it is important to allow an operator to still > >> use the DSCP for traffic that isn't PCN-enabled. This is achieved > >>by > >> providing a not-PCN state within the encoding scheme. > >> > >>A.1. Choice of Suitable DSCPs > >> > >> The PCN Working Group chose not to define a single DSCP for use > with > >> PCN for several reasons. Firstly the PCN mechanism is applicable > to > >> a variety of different traffic classes. Secondly standards track > >> DSCPs are in increasingly short supply. Thirdly PCN should be > seen > >> as being essentially a marking behaviour similar to ECN but > intended > >> for inelastic traffic. The choice of which DSCP is most suitable > >>for > >> a given PCN-domain is dependent on the nature of the traffic > >>entering > >> that domain and the link rates of all the links making up that > >> domain. In PCN-domains with uniformly high link rates, the > >> appropriate DSCPs would currently be those for the Real Time > Traffic > >> Class [RFC5127]. To be clear the PCN Working Group recommends > using > >> > >>Spencer (clarity): is this 2119 language (apparently not, since this > >>section > >>is not normative), or are you saying "suggests"? My suggestion is > >>that we > >>not use 2119 language, even lowercased, except for normative text - > >>this > >>seems to cause confusion from time to time. But please check with > your > >>shepherding AD to see if he agrees. > >> > >> admission control for the following service classes: > >> > >> o Telephony (EF) > >> > >> o Real-time interactive (CS4) > >> > >> o Broadcast Video (CS3) > >> > >> o Multimedia Conferencing (AF4) > >> > >>_______________________________________________ > >>Gen-art mailing list > >>Gen-art@ietf.org > >>https://www.ietf.org/mailman/listinfo/gen-art > > > > > > > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Wed Aug 26 05:08:32 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 C01AA28C0FA for ; Wed, 26 Aug 2009 05:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 xEvMgXmJGTkJ for ; Wed, 26 Aug 2009 05:08:30 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 8996128C0D0 for ; Wed, 26 Aug 2009 05:07:44 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 26 Aug 2009 14:05:55 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 14:05:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 14:05:53 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 thread-index: AcomIV4kyKiY+iXvQYu1/Asfi7Sj6wAG9oNwAADaKnA= References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> From: To: X-OriginalArrivalTime: 26 Aug 2009 12:05:55.0289 (UTC) FILETIME=[9087AC90:01CA2645] Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 12:08:32 -0000 Toby, you simply ommited some "PCN" in your new version. I think the=20 problem addressed by Spencer may be that you try to sum up=20 RFC5559 rather then refer to it.=20 Below there's an abstract proposal, structured top-down: - What's PCN: a copy of the abstract of RFC5559. - What's the functionality relevant for this document: marking - What's specified by this document: baseline encoding=20 My try: PCN specifies flow admission and termination based on pre-congestion=20 information in order to protect the quality of service of established,=20 inelastic flows within a single Diffserv domain. As a part of this=20 specification, the overall rate of the PCN coloured traffic is metered=20 on every link in the domain, and these packets are appropriately marked=20 when certain configured rates are exceeded. This document specifies how such marks are encoded into the IP header=20 by re-using the Explicit Congestion Notification (ECN) codepoints=20 within this controlled domain. The baseline encoding described here=20 provides for only two PCN encoding states, Not-marked and PCN-marked. Please maintain the notion of "overall rate of PCN traffic" or=20 "PCN coloured traffic" which is being metered in the version of=20 abstract you go on with. Regards, Ruediger -----Original Message----- From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com]=20 Sent: Wednesday, August 26, 2009 1:13 PM To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger Cc: bob@homefarmparham.co.uk; pcn@ietf.org Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART Review = ofdraft-ietf-pcn-baseline-encoding-05 So would the following sound better? : Pre-Congestion Notification (PCN) is a metering and marking scheme=20 that protects the quality of service (QoS) of inelastic flows within=20 a Diffserv domain. The overall rate of the traffic is metered on = every=20 link in the domain, and packets are appropriately marked when certain configured rates are exceeded. Boundary nodes can measure the level of marking and thus make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked. Just for clarity here was the earlier version I proposed: The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the traffic is metered on every link in the domain, and packets are appropriately marked when certain configured rates are exceeded. Boundary nodes can measure the level of marking and thus make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked. I personally disagree with Tom's suggestion to add PCN to all the = defined=20 terms (e.g. PCN flow, PCN traffic) - that is fine within the body of the = document but in this abstract we should avoid using any terms that = readers won't be already familiar with. > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 26 August 2009 08:46 > To: Ruediger.Geib@telekom.de > Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 >=20 > Hi all, >=20 > R=FCdiger touches an issue that I also feel is not optimally solved in > the > current abstract. The objective of PCN is provide marking information > to > egress node and the objective of admission control and flow = termination > is to protect QoS. I use the following short explanation for PCN. = Maybe > this idea could be added to the current abstract. >=20 > Pre-congestion notification (PCN) is a metering and marking scheme for > Differentiated Services (DiffServ) IP networks which provides egress > nodes with information about load conditions inside the network > \cite{RFC5559}. This information is used for admission control and = flow > termination to support quality of service (QoS) for admitted inelastic > realtime flows that are carried with prioritization within the = DiffServ > domain. > This document specifies how nodes encode the marking information in = the > IP header by re-using the Explicit Congestion Notification (ECN) > codepoints within a controlled DiffServ domain. The baseline encoding > described here provides for only two PCN encoding states which are > not-marked and PCN-marked. >=20 > Regards, >=20 > Michael >=20 > Ruediger.Geib@telekom.de schrieb: > > Toby, Bob > > > > if the abstract is to mention PCN functionalities not defined within > > this document in a rather simplified way, would the purpose of PCN > > be to enable a Diffserv domain to support measurement based > > admission control as defined by PCN architecture? > > > > Regards, > > > > Ruediger > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of > Bob Briscoe > > Sent: Tuesday, August 25, 2009 8:42 PM > > To: toby.moncaster@bt.com; pcn@ietf.org > > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 > > > > Toby, > > > > I think this isn't just good for a casual reader, but it is actually > > still correct and doesn't require defining PC-domain (which is just > > the Diffserv domain once the described measures - the PDB - have = been > > put in place). > > > > > > Bob > > > > At 15:53 25/08/2009, toby.moncaster@bt.com wrote: > > > >> This potentially raises an issue for all future PCN documents since > the > >> abstract was based on our agreed standard elevator-pitch > introduction to > >> PCN... Specifically Spencer raises the question of using the = defined > >> term PCN-domain in the abstract. Any thoughts from anyone as to > whether > >> this is confusing? Would it be clearer to just use "domain" (e.g. > drop > >> the "PCN-"). In which case should I alter the whole abstract as > follows > >> (note: I realise this is strictly incorrect as it now doesn't seek > to > >> distinguish the non-PCN and PCN traffic from each other but is this > >> clearer for a casual reader?): > >> > >> The objective of Pre-Congestion Notification (PCN) is to protect > the > >> quality of service (QoS) of inelastic flows within a Diffserv > domain. > >> The overall rate of the traffic is metered on every link in the > >> domain, and packets are appropriately marked when certain > >> configured rates are exceeded. Boundary nodes can measure the > level > >> of marking and thus make decisions about whether to admit or > block a > >> new flow request, and (in abnormal circumstances) whether to > >> terminate some of the existing flows, thereby protecting the QoS > of > >> previously admitted flows. This document specifies how such > marks > >> are encoded into the IP header by re-using the Explicit > Congestion > >> Notification (ECN) codepoints within this controlled domain. = The > >> baseline encoding described here provides for only two PCN > encoding > >> states, Not-marked and PCN-marked. > >> > >> Toby > >> > >> > >>> -----Original Message----- > >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > >>> Lars Eggert > >>> Sent: 25 August 2009 15:12 > >>> To: pcn@ietf.org > >>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > >>> > >> ofdraft-ietf-pcn-baseline- > >> > >>> encoding-05 > >>> > >>> > >>> > >>> Begin forwarded message: > >>> > >>> > >>>> From: Spencer Dawkins > >>>> Date: August 25, 2009 14:47:49 GMT+02:00 > >>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > >>>> > >> >> > >>> pcn-baseline-encoding@tools.ietf.org > >>> > >>>> Cc: General Area Review Team , > >>>> > >>> "ietf@ietf.org > >>> > >>>> " > >>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > >>>> encoding-05 > >>>> > >>>> I have been selected as the General Area Review Team (Gen-ART) > >>>> reviewer for this draft (for background on Gen-ART, please see > >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >>>> > >>>> Please wait for direction from your document shepherd or AD = before > >>>> posting a new version of the draft. > >>>> > >>>> Document: draft-ietf-pcn-baseline-encoding-05 > >>>> Reviewer: Spencer Dawkins > >>>> IETF LC End Date: 2009-09-03 > >>>> Review Date: 2009-08-21 > >>>> IESG Telechat date: (not known) > >>>> > >>>> Summary: this specification is almost ready for publication as a > >>>> Proposed Standard. I have one minor question below (flagged as > >>>> "Spencer (minor)"), along with some editorial suggestions to be > >>>> considered when this document is edited (either in the working > group > >>>> or by the RFC Editor). > >>>> > >>>> Abstract > >>>> > >>>> The objective of Pre-Congestion Notification (PCN) is to = protect > >>>> > >>> the > >>> > >>>> quality of service (QoS) of inelastic flows within a Diffserv > >>>> domain. > >>>> > >>>> Spencer (clarity): I'm not sure what the relationship between a > >>>> Diffserv domain and a PCN-domain is - this couuld be clearer, > >>>> especially in an Abstract. I note that RFC 5559 doesn't use the > term > >>>> PCN-domain in its Abstract ... I can guess, but I'm just = guessing. > >>>> > >>>> The overall rate of the PCN-traffic is metered on every link in > >>>> > >> the > >> > >>>> PCN-domain, and PCN-packets are appropriately marked when > certain > >>>> configured rates are exceeded. The level of marking allows the > >>>> boundary nodes to make decisions about whether to admit or = block > a > >>>> new flow request, and (in abnormal circumstances) whether to > >>>> terminate some of the existing flows, thereby protecting the = QoS > >>>> > >> of > >> > >>>> previously admitted flows. This document specifies how such > marks > >>>> are to be encoded into the IP header by re-using the Explicit > >>>> Congestion Notification (ECN) codepoints within this controlled > >>>> domain. The baseline encoding described here provides for only > >>>> > >> two > >> > >>>> PCN encoding states, Not-marked and PCN-marked. > >>>> > >>>> 4. Encoding two PCN States in IP > >>>> > >>>> The following rules apply to all PCN traffic: > >>>> > >>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv > >>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be > >>>> chosen that are already defined for use with admission > >>>> > >>> controlled > >>> > >>>> traffic. Appendix A.1 gives guidance to implementiors on > >>>> suitable > >>>> > >>>> Spencer (clarity): s/implementiors/implementers/? > >>>> > >>>> DSCPs. Guidelines for mixing traffic-types within a PCN- > domain > >>>> are given in [I-D.ietf-pcn-marking-behaviour]. > >>>> > >>>> o Any packet that is not-PCN but which shares the same = Diffserv > >>>> codepoint as PCN-enabled traffic MUST have the ECN field of > its > >>>> outermost IP header equal to 00. > >>>> > >>>> Spencer (minor): this is the only point in the specification = (that > I > >>>> can > >>>> find) that makes reference to the "outermost IP header". I'm not > >>>> > >> sure > >> > >>>> whether to suggest s/outermost// here or to ask that a statement > be > >>>> added earlier in the document to clearly state that PCN encoding > >>>> > >> only > >> > >>>> protects inelastic traffic when it's used for the outermost IP > >>>> > >>> header, > >>> > >>>> but the current text seems to call attention to this in a way = that > >>>> makes the reader wonder what is special about THIS requirement > that > >>>> isn't true of the other requirements listed. > >>>> > >>>> 4.3. PCN-Compatible Diffserv Codepoints > >>>> > >>>> Enabling PCN marking behaviour for a specific DSCP disables any > >>>> other > >>>> marking behaviour (e.g. enabling PCN disables the default ECN > >>>> marking > >>>> behaviour introduced in [RFC3168]). All traffic metering and > >>>> marking > >>>> > >>>> Spencer (clarity): here, and in Section 6, the text uses > "disables" > >>>> > >>> to > >>> > >>>> describe the relationship between PCN and ECN. If I understand = the > >>>> point, the domain is substituting one behavior for another. I > might > >>>> suggest "replaces" to describe the relationship in both = locations. > >>>> > >>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > >>>> > >> This > >> > >>>> ensures compliance with the BCP guidance set out in [RFC4774]. > >>>> > >>>> 4.3.1. Co-existence of PCN and not-PCN traffic > >>>> > >>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is > >>>> envisaged as a marking behaviour that could be applied to a > number > >>>> of > >>>> different DSCPs makes it essential that we provide a not-PCN > >>>> > >> state. > >> > >>>> As stated above (and expanded in Appendix A.1) the aim is for > PCN > >>>> > >>> to > >>> > >>>> re-use existing DSCPs. Because PCN re-defines the meaning of > the > >>>> ECN > >>>> > >>>> Spencer (clarity): here, the text uses "re-defines", which I like > >>>> better than "disables", but if you go for "replaces" previously > and > >>>> > >>> in > >>> > >>>> section 6, you might want to use the same wording here. > >>>> > >>>> field for such DSCPs it is important to allow an operator to > still > >>>> use the DSCP for traffic that isn't PCN-enabled. This is > achieved > >>>> by > >>>> providing a not-PCN state within the encoding scheme. > >>>> > >>>> A.1. Choice of Suitable DSCPs > >>>> > >>>> The PCN Working Group chose not to define a single DSCP for use > >>>> > >>> with > >>> > >>>> PCN for several reasons. Firstly the PCN mechanism is > applicable > >>>> > >>> to > >>> > >>>> a variety of different traffic classes. Secondly standards > track > >>>> DSCPs are in increasingly short supply. Thirdly PCN should be > >>>> > >> seen > >> > >>>> as being essentially a marking behaviour similar to ECN but > >>>> > >>> intended > >>> > >>>> for inelastic traffic. The choice of which DSCP is most > suitable > >>>> for > >>>> a given PCN-domain is dependent on the nature of the traffic > >>>> entering > >>>> that domain and the link rates of all the links making up that > >>>> domain. In PCN-domains with uniformly high link rates, the > >>>> appropriate DSCPs would currently be those for the Real Time > >>>> > >>> Traffic > >>> > >>>> Class [RFC5127]. To be clear the PCN Working Group recommends > >>>> > >>> using > >>> > >>>> Spencer (clarity): is this 2119 language (apparently not, since > this > >>>> section is not normative), or are you saying "suggests"? My > >>>> > >>> suggestion > >>> > >>>> is that we not use 2119 language, even lowercased, except for > >>>> normative text - this seems to cause confusion from time to time. > >>>> > >> But > >> > >>>> please check with your shepherding AD to see if he agrees. > >>>> > >>>> admission control for the following service classes: > >>>> > >>>> o Telephony (EF) > >>>> > >>>> o Real-time interactive (CS4) > >>>> > >>>> o Broadcast Video (CS3) > >>>> > >>>> o Multimedia Conferencing (AF4) > >>>> > >>>> _______________________________________________ > >>>> Gen-art mailing list > >>>> Gen-art@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/gen-art > >>>> > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcn > >> > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > >=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 toby.moncaster@bt.com Wed Aug 26 06:41:10 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809673A6A42 for ; Wed, 26 Aug 2009 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 ICT2VgLVRW8l for ; Wed, 26 Aug 2009 06:41:08 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id DC4AD3A67B1 for ; Wed, 26 Aug 2009 06:41:07 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 14:39:36 +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: Wed, 26 Aug 2009 14:39:22 +0100 Message-ID: In-Reply-To: <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcomIV4kyKiY+iXvQYu1/Asfi7Sj6wAG9oNwAADaKnAABA3FYA== References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> From: To: X-OriginalArrivalTime: 26 Aug 2009 13:39:36.0726 (UTC) FILETIME=[A72AE360:01CA2652] Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 13:41:10 -0000 OK, as there seems to be more of a consensus that the abstract needs to = maintain the idea of PCN traffic being distinct I will try to do a = hybrid of your and my abstracts... Incidentally I quite like your = approach to how to formulate the abstract... Pre-Congestion Notification (PCN) is a metering and marking scheme that protects the quality of service (QoS) of inelastic flows=20 within a Diffserv domain. It does so by measuring pre-congestion=20 information at the boundaries of the domain and using this=20 information to determine whether to admit new flows or (in abnormal circumstances) terminate some existing flows, thereby protecting=20 the QoS of previously admitted flows. This pre-congestion=20 information is provided by marking packets when the overall rate=20 of PCN traffic on a link exceeds certain configured rates. This=20 document specifies how such marks are encoded into the IP header=20 by re-using the Explicit Congestion Notification (ECN) codepoints=20 within this controlled domain. The baseline encoding described=20 here provides for only two PCN encoding states, Not-marked and=20 PCN-marked. The only slight concern I have is that the second sentence is getting = rather long and unwieldy... Toby > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: 26 August 2009 13:06 > To: Moncaster,T,Toby,DER3 R > Cc: bob@homefarmparham.co.uk; pcn@ietf.org; menth@informatik.uni- > wuerzburg.de > Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 >=20 > Toby, >=20 > you simply ommited some "PCN" in your new version. I think the > problem addressed by Spencer may be that you try to sum up > RFC5559 rather then refer to it. >=20 > Below there's an abstract proposal, structured top-down: > - What's PCN: a copy of the abstract of RFC5559. > - What's the functionality relevant for this document: marking > - What's specified by this document: baseline encoding >=20 > My try: >=20 > PCN specifies 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. As a part of this > specification, the overall rate of the PCN coloured traffic is metered > on every link in the domain, and these packets are appropriately = marked > when certain configured rates are exceeded. > This document specifies how such marks are encoded into the IP header > by re-using the Explicit Congestion Notification (ECN) codepoints > within this controlled domain. The baseline encoding described here > provides for only two PCN encoding states, Not-marked and PCN-marked. >=20 >=20 >=20 > Please maintain the notion of "overall rate of PCN traffic" or > "PCN coloured traffic" which is being metered in the version of > abstract you go on with. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > Sent: Wednesday, August 26, 2009 1:13 PM > To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger > Cc: bob@homefarmparham.co.uk; pcn@ietf.org > Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 >=20 > So would the following sound better? : >=20 > Pre-Congestion Notification (PCN) is a metering and marking scheme > that protects the quality of service (QoS) of inelastic flows = within > a Diffserv domain. The overall rate of the traffic is metered on > every > link in the domain, and packets are appropriately marked when > certain > configured rates are exceeded. Boundary nodes can measure the = level > of marking and thus make decisions about whether to admit or block = a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. The > baseline encoding described here provides for only two PCN encoding > states, Not-marked and PCN-marked. >=20 > Just for clarity here was the earlier version I proposed: >=20 > The objective of Pre-Congestion Notification (PCN) is to protect = the > quality of service (QoS) of inelastic flows within a Diffserv > domain. > The overall rate of the traffic is metered on every link in the > domain, and packets are appropriately marked when certain > configured rates are exceeded. Boundary nodes can measure the = level > of marking and thus make decisions about whether to admit or block = a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. The > baseline encoding described here provides for only two PCN encoding > states, Not-marked and PCN-marked. >=20 > I personally disagree with Tom's suggestion to add PCN to all the > defined > terms (e.g. PCN flow, PCN traffic) - that is fine within the body of > the > document but in this abstract we should avoid using any terms that > readers > won't be already familiar with. >=20 >=20 >=20 > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: 26 August 2009 08:46 > > To: Ruediger.Geib@telekom.de > > Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org > > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > > baseline-encoding-05 > > > > Hi all, > > > > R=FCdiger touches an issue that I also feel is not optimally solved = in > > the > > current abstract. The objective of PCN is provide marking = information > > to > > egress node and the objective of admission control and flow > termination > > is to protect QoS. I use the following short explanation for PCN. > Maybe > > this idea could be added to the current abstract. > > > > Pre-congestion notification (PCN) is a metering and marking scheme > for > > Differentiated Services (DiffServ) IP networks which provides egress > > nodes with information about load conditions inside the network > > \cite{RFC5559}. This information is used for admission control and > flow > > termination to support quality of service (QoS) for admitted > inelastic > > realtime flows that are carried with prioritization within the > DiffServ > > domain. > > This document specifies how nodes encode the marking information in > the > > IP header by re-using the Explicit Congestion Notification (ECN) > > codepoints within a controlled DiffServ domain. The baseline > encoding > > described here provides for only two PCN encoding states which are > > not-marked and PCN-marked. > > > > Regards, > > > > Michael > > > > Ruediger.Geib@telekom.de schrieb: > > > Toby, Bob > > > > > > if the abstract is to mention PCN functionalities not defined > within > > > this document in a rather simplified way, would the purpose of PCN > > > be to enable a Diffserv domain to support measurement based > > > admission control as defined by PCN architecture? > > > > > > Regards, > > > > > > Ruediger > > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > > Bob Briscoe > > > Sent: Tuesday, August 25, 2009 8:42 PM > > > To: toby.moncaster@bt.com; pcn@ietf.org > > > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > > baseline-encoding-05 > > > > > > Toby, > > > > > > I think this isn't just good for a casual reader, but it is > actually > > > still correct and doesn't require defining PC-domain (which is = just > > > the Diffserv domain once the described measures - the PDB - have > been > > > put in place). > > > > > > > > > Bob > > > > > > At 15:53 25/08/2009, toby.moncaster@bt.com wrote: > > > > > >> This potentially raises an issue for all future PCN documents > since > > the > > >> abstract was based on our agreed standard elevator-pitch > > introduction to > > >> PCN... Specifically Spencer raises the question of using the > defined > > >> term PCN-domain in the abstract. Any thoughts from anyone as to > > whether > > >> this is confusing? Would it be clearer to just use "domain" (e.g. > > drop > > >> the "PCN-"). In which case should I alter the whole abstract as > > follows > > >> (note: I realise this is strictly incorrect as it now doesn't = seek > > to > > >> distinguish the non-PCN and PCN traffic from each other but is > this > > >> clearer for a casual reader?): > > >> > > >> The objective of Pre-Congestion Notification (PCN) is to > protect > > the > > >> quality of service (QoS) of inelastic flows within a Diffserv > > domain. > > >> The overall rate of the traffic is metered on every link in = the > > >> domain, and packets are appropriately marked when certain > > >> configured rates are exceeded. Boundary nodes can measure the > > level > > >> of marking and thus make decisions about whether to admit or > > block a > > >> new flow request, and (in abnormal circumstances) whether to > > >> terminate some of the existing flows, thereby protecting the > QoS > > of > > >> previously admitted flows. This document specifies how such > > marks > > >> are encoded into the IP header by re-using the Explicit > > Congestion > > >> Notification (ECN) codepoints within this controlled domain. > The > > >> baseline encoding described here provides for only two PCN > > encoding > > >> states, Not-marked and PCN-marked. > > >> > > >> Toby > > >> > > >> > > >>> -----Original Message----- > > >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf > > Of > > >>> Lars Eggert > > >>> Sent: 25 August 2009 15:12 > > >>> To: pcn@ietf.org > > >>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > > >>> > > >> ofdraft-ietf-pcn-baseline- > > >> > > >>> encoding-05 > > >>> > > >>> > > >>> > > >>> Begin forwarded message: > > >>> > > >>> > > >>>> From: Spencer Dawkins > > >>>> Date: August 25, 2009 14:47:49 GMT+02:00 > > >>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > > >>>> > > >> > >> > > >>> pcn-baseline-encoding@tools.ietf.org > > >>> > > >>>> Cc: General Area Review Team , > > >>>> > > >>> "ietf@ietf.org > > >>> > > >>>> " > > >>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > > >>>> encoding-05 > > >>>> > > >>>> I have been selected as the General Area Review Team (Gen-ART) > > >>>> reviewer for this draft (for background on Gen-ART, please see > > >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > >>>> > > >>>> Please wait for direction from your document shepherd or AD > before > > >>>> posting a new version of the draft. > > >>>> > > >>>> Document: draft-ietf-pcn-baseline-encoding-05 > > >>>> Reviewer: Spencer Dawkins > > >>>> IETF LC End Date: 2009-09-03 > > >>>> Review Date: 2009-08-21 > > >>>> IESG Telechat date: (not known) > > >>>> > > >>>> Summary: this specification is almost ready for publication as = a > > >>>> Proposed Standard. I have one minor question below (flagged as > > >>>> "Spencer (minor)"), along with some editorial suggestions to be > > >>>> considered when this document is edited (either in the working > > group > > >>>> or by the RFC Editor). > > >>>> > > >>>> Abstract > > >>>> > > >>>> The objective of Pre-Congestion Notification (PCN) is to > protect > > >>>> > > >>> the > > >>> > > >>>> quality of service (QoS) of inelastic flows within a Diffserv > > >>>> domain. > > >>>> > > >>>> Spencer (clarity): I'm not sure what the relationship between a > > >>>> Diffserv domain and a PCN-domain is - this couuld be clearer, > > >>>> especially in an Abstract. I note that RFC 5559 doesn't use the > > term > > >>>> PCN-domain in its Abstract ... I can guess, but I'm just > guessing. > > >>>> > > >>>> The overall rate of the PCN-traffic is metered on every link > in > > >>>> > > >> the > > >> > > >>>> PCN-domain, and PCN-packets are appropriately marked when > > certain > > >>>> configured rates are exceeded. The level of marking allows > the > > >>>> boundary nodes to make decisions about whether to admit or > block > > a > > >>>> new flow request, and (in abnormal circumstances) whether to > > >>>> terminate some of the existing flows, thereby protecting the > QoS > > >>>> > > >> of > > >> > > >>>> previously admitted flows. This document specifies how such > > marks > > >>>> are to be encoded into the IP header by re-using the Explicit > > >>>> Congestion Notification (ECN) codepoints within this > controlled > > >>>> domain. The baseline encoding described here provides for > only > > >>>> > > >> two > > >> > > >>>> PCN encoding states, Not-marked and PCN-marked. > > >>>> > > >>>> 4. Encoding two PCN States in IP > > >>>> > > >>>> The following rules apply to all PCN traffic: > > >>>> > > >>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv > > >>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD > be > > >>>> chosen that are already defined for use with admission > > >>>> > > >>> controlled > > >>> > > >>>> traffic. Appendix A.1 gives guidance to implementiors on > > >>>> suitable > > >>>> > > >>>> Spencer (clarity): s/implementiors/implementers/? > > >>>> > > >>>> DSCPs. Guidelines for mixing traffic-types within a PCN- > > domain > > >>>> are given in [I-D.ietf-pcn-marking-behaviour]. > > >>>> > > >>>> o Any packet that is not-PCN but which shares the same > Diffserv > > >>>> codepoint as PCN-enabled traffic MUST have the ECN field = of > > its > > >>>> outermost IP header equal to 00. > > >>>> > > >>>> Spencer (minor): this is the only point in the specification > (that > > I > > >>>> can > > >>>> find) that makes reference to the "outermost IP header". I'm = not > > >>>> > > >> sure > > >> > > >>>> whether to suggest s/outermost// here or to ask that a = statement > > be > > >>>> added earlier in the document to clearly state that PCN = encoding > > >>>> > > >> only > > >> > > >>>> protects inelastic traffic when it's used for the outermost IP > > >>>> > > >>> header, > > >>> > > >>>> but the current text seems to call attention to this in a way > that > > >>>> makes the reader wonder what is special about THIS requirement > > that > > >>>> isn't true of the other requirements listed. > > >>>> > > >>>> 4.3. PCN-Compatible Diffserv Codepoints > > >>>> > > >>>> Enabling PCN marking behaviour for a specific DSCP disables > any > > >>>> other > > >>>> marking behaviour (e.g. enabling PCN disables the default ECN > > >>>> marking > > >>>> behaviour introduced in [RFC3168]). All traffic metering and > > >>>> marking > > >>>> > > >>>> Spencer (clarity): here, and in Section 6, the text uses > > "disables" > > >>>> > > >>> to > > >>> > > >>>> describe the relationship between PCN and ECN. If I understand > the > > >>>> point, the domain is substituting one behavior for another. I > > might > > >>>> suggest "replaces" to describe the relationship in both > locations. > > >>>> > > >>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > > >>>> > > >> This > > >> > > >>>> ensures compliance with the BCP guidance set out in = [RFC4774]. > > >>>> > > >>>> 4.3.1. Co-existence of PCN and not-PCN traffic > > >>>> > > >>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN = is > > >>>> envisaged as a marking behaviour that could be applied to a > > number > > >>>> of > > >>>> different DSCPs makes it essential that we provide a not-PCN > > >>>> > > >> state. > > >> > > >>>> As stated above (and expanded in Appendix A.1) the aim is for > > PCN > > >>>> > > >>> to > > >>> > > >>>> re-use existing DSCPs. Because PCN re-defines the meaning of > > the > > >>>> ECN > > >>>> > > >>>> Spencer (clarity): here, the text uses "re-defines", which I > like > > >>>> better than "disables", but if you go for "replaces" previously > > and > > >>>> > > >>> in > > >>> > > >>>> section 6, you might want to use the same wording here. > > >>>> > > >>>> field for such DSCPs it is important to allow an operator to > > still > > >>>> use the DSCP for traffic that isn't PCN-enabled. This is > > achieved > > >>>> by > > >>>> providing a not-PCN state within the encoding scheme. > > >>>> > > >>>> A.1. Choice of Suitable DSCPs > > >>>> > > >>>> The PCN Working Group chose not to define a single DSCP for > use > > >>>> > > >>> with > > >>> > > >>>> PCN for several reasons. Firstly the PCN mechanism is > > applicable > > >>>> > > >>> to > > >>> > > >>>> a variety of different traffic classes. Secondly standards > > track > > >>>> DSCPs are in increasingly short supply. Thirdly PCN should = be > > >>>> > > >> seen > > >> > > >>>> as being essentially a marking behaviour similar to ECN but > > >>>> > > >>> intended > > >>> > > >>>> for inelastic traffic. The choice of which DSCP is most > > suitable > > >>>> for > > >>>> a given PCN-domain is dependent on the nature of the traffic > > >>>> entering > > >>>> that domain and the link rates of all the links making up = that > > >>>> domain. In PCN-domains with uniformly high link rates, the > > >>>> appropriate DSCPs would currently be those for the Real Time > > >>>> > > >>> Traffic > > >>> > > >>>> Class [RFC5127]. To be clear the PCN Working Group = recommends > > >>>> > > >>> using > > >>> > > >>>> Spencer (clarity): is this 2119 language (apparently not, since > > this > > >>>> section is not normative), or are you saying "suggests"? My > > >>>> > > >>> suggestion > > >>> > > >>>> is that we not use 2119 language, even lowercased, except for > > >>>> normative text - this seems to cause confusion from time to > time. > > >>>> > > >> But > > >> > > >>>> please check with your shepherding AD to see if he agrees. > > >>>> > > >>>> admission control for the following service classes: > > >>>> > > >>>> o Telephony (EF) > > >>>> > > >>>> o Real-time interactive (CS4) > > >>>> > > >>>> o Broadcast Video (CS3) > > >>>> > > >>>> o Multimedia Conferencing (AF4) > > >>>> > > >>>> _______________________________________________ > > >>>> Gen-art mailing list > > >>>> Gen-art@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/gen-art > > >>>> > > >> _______________________________________________ > > >> PCN mailing list > > >> PCN@ietf.org > > >> https://www.ietf.org/mailman/listinfo/pcn > > >> > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > > -- > > 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 menth@informatik.uni-wuerzburg.de Wed Aug 26 08:46:29 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 07B063A6B65 for ; Wed, 26 Aug 2009 08:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, SARE_OBFU_COULD=0.917] 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 pEqOZLSJBfa9 for ; Wed, 26 Aug 2009 08:46:27 -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 34DD63A69F7 for ; Wed, 26 Aug 2009 08:46:26 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id CD281199711; Wed, 26 Aug 2009 17:13:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C04EA1997E3; Wed, 26 Aug 2009 17:13:30 +0200 (CEST) Received: from [192.168.1.2] (f051180052.adsl.alicedsl.de [78.51.180.52]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 430ACA0DFC; Wed, 26 Aug 2009 17:13:30 +0200 (CEST) Message-ID: <4A9550E1.10801@informatik.uni-wuerzburg.de> Date: Wed, 26 Aug 2009 17:12:33 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 15:46:29 -0000 Hi Ruediger, Toby, Ruediger.Geib@telekom.de schrieb: > Toby, > > you simply ommited some "PCN" in your new version. I think the > problem addressed by Spencer may be that you try to sum up > RFC5559 rather then refer to it. > > Below there's an abstract proposal, structured top-down: > - What's PCN: a copy of the abstract of RFC5559. > - What's the functionality relevant for this document: marking > - What's specified by this document: baseline encoding > > My try: > > PCN specifies 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. What is PCN? Or is admission control and flow termination also part of PCN? My take on this is that PCN is only the marking scheme and the way the information is carried to egress nodes. AC and FT is just built on top of PCN. And to support QoS is the objective of AC and FT, not primarily or only indirectly the objective of the marking scheme. Regards, Michael > As a part of this > specification, the overall rate of the PCN coloured traffic is metered > on every link in the domain, and these packets are appropriately marked > when certain configured rates are exceeded. > This document specifies how such marks are encoded into the IP header > by re-using the Explicit Congestion Notification (ECN) codepoints > within this controlled domain. The baseline encoding described here > provides for only two PCN encoding states, Not-marked and PCN-marked. > > > > Please maintain the notion of "overall rate of PCN traffic" or > "PCN coloured traffic" which is being metered in the version of > abstract you go on with. > > Regards, > > Ruediger > > > > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > Sent: Wednesday, August 26, 2009 1:13 PM > To: menth@informatik.uni-wuerzburg.de; Geib, Rüdiger > Cc: bob@homefarmparham.co.uk; pcn@ietf.org > Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 > > So would the following sound better? : > > Pre-Congestion Notification (PCN) is a metering and marking scheme > that protects the quality of service (QoS) of inelastic flows within > a Diffserv domain. The overall rate of the traffic is metered on every > link in the domain, and packets are appropriately marked when certain > configured rates are exceeded. Boundary nodes can measure the level > of marking and thus make decisions about whether to admit or block a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. The > baseline encoding described here provides for only two PCN encoding > states, Not-marked and PCN-marked. > > Just for clarity here was the earlier version I proposed: > > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv domain. > The overall rate of the traffic is metered on every link in the > domain, and packets are appropriately marked when certain > configured rates are exceeded. Boundary nodes can measure the level > of marking and thus make decisions about whether to admit or block a > new flow request, and (in abnormal circumstances) whether to > terminate some of the existing flows, thereby protecting the QoS of > previously admitted flows. This document specifies how such marks > are encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. The > baseline encoding described here provides for only two PCN encoding > states, Not-marked and PCN-marked. > > I personally disagree with Tom's suggestion to add PCN to all the defined > terms (e.g. PCN flow, PCN traffic) - that is fine within the body of the > document but in this abstract we should avoid using any terms that readers > won't be already familiar with. > > > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: 26 August 2009 08:46 >> To: Ruediger.Geib@telekom.de >> Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >> baseline-encoding-05 >> >> Hi all, >> >> Rüdiger touches an issue that I also feel is not optimally solved in >> the >> current abstract. The objective of PCN is provide marking information >> to >> egress node and the objective of admission control and flow termination >> is to protect QoS. I use the following short explanation for PCN. Maybe >> this idea could be added to the current abstract. >> >> Pre-congestion notification (PCN) is a metering and marking scheme for >> Differentiated Services (DiffServ) IP networks which provides egress >> nodes with information about load conditions inside the network >> \cite{RFC5559}. This information is used for admission control and flow >> termination to support quality of service (QoS) for admitted inelastic >> realtime flows that are carried with prioritization within the DiffServ >> domain. >> This document specifies how nodes encode the marking information in the >> IP header by re-using the Explicit Congestion Notification (ECN) >> codepoints within a controlled DiffServ domain. The baseline encoding >> described here provides for only two PCN encoding states which are >> not-marked and PCN-marked. >> >> Regards, >> >> Michael >> >> Ruediger.Geib@telekom.de schrieb: >> >>> Toby, Bob >>> >>> if the abstract is to mention PCN functionalities not defined within >>> this document in a rather simplified way, would the purpose of PCN >>> be to enable a Diffserv domain to support measurement based >>> admission control as defined by PCN architecture? >>> >>> Regards, >>> >>> Ruediger >>> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>> >> Bob Briscoe >> >>> Sent: Tuesday, August 25, 2009 8:42 PM >>> To: toby.moncaster@bt.com; pcn@ietf.org >>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>> >> baseline-encoding-05 >> >>> Toby, >>> >>> I think this isn't just good for a casual reader, but it is actually >>> still correct and doesn't require defining PC-domain (which is just >>> the Diffserv domain once the described measures - the PDB - have been >>> put in place). >>> >>> >>> Bob >>> >>> At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>> >>> >>>> This potentially raises an issue for all future PCN documents since >>>> >> the >> >>>> abstract was based on our agreed standard elevator-pitch >>>> >> introduction to >> >>>> PCN... Specifically Spencer raises the question of using the defined >>>> term PCN-domain in the abstract. Any thoughts from anyone as to >>>> >> whether >> >>>> this is confusing? Would it be clearer to just use "domain" (e.g. >>>> >> drop >> >>>> the "PCN-"). In which case should I alter the whole abstract as >>>> >> follows >> >>>> (note: I realise this is strictly incorrect as it now doesn't seek >>>> >> to >> >>>> distinguish the non-PCN and PCN traffic from each other but is this >>>> clearer for a casual reader?): >>>> >>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>> >> the >> >>>> quality of service (QoS) of inelastic flows within a Diffserv >>>> >> domain. >> >>>> The overall rate of the traffic is metered on every link in the >>>> domain, and packets are appropriately marked when certain >>>> configured rates are exceeded. Boundary nodes can measure the >>>> >> level >> >>>> of marking and thus make decisions about whether to admit or >>>> >> block a >> >>>> new flow request, and (in abnormal circumstances) whether to >>>> terminate some of the existing flows, thereby protecting the QoS >>>> >> of >> >>>> previously admitted flows. This document specifies how such >>>> >> marks >> >>>> are encoded into the IP header by re-using the Explicit >>>> >> Congestion >> >>>> Notification (ECN) codepoints within this controlled domain. The >>>> baseline encoding described here provides for only two PCN >>>> >> encoding >> >>>> states, Not-marked and PCN-marked. >>>> >>>> Toby >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>>> >> Of >> >>>>> Lars Eggert >>>>> Sent: 25 August 2009 15:12 >>>>> To: pcn@ietf.org >>>>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>>>> >>>>> >>>> ofdraft-ietf-pcn-baseline- >>>> >>>> >>>>> encoding-05 >>>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>> >>>>> >>>>>> From: Spencer Dawkins >>>>>> Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>> >>>>>> >>>> >>> >>>> >>>>> pcn-baseline-encoding@tools.ietf.org >>>>> >>>>> >>>>>> Cc: General Area Review Team , >>>>>> >>>>>> >>>>> "ietf@ietf.org >>>>> >>>>> >>>>>> " >>>>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>>>> encoding-05 >>>>>> >>>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>>> reviewer for this draft (for background on Gen-ART, please see >>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>> >>>>>> Please wait for direction from your document shepherd or AD before >>>>>> posting a new version of the draft. >>>>>> >>>>>> Document: draft-ietf-pcn-baseline-encoding-05 >>>>>> Reviewer: Spencer Dawkins >>>>>> IETF LC End Date: 2009-09-03 >>>>>> Review Date: 2009-08-21 >>>>>> IESG Telechat date: (not known) >>>>>> >>>>>> Summary: this specification is almost ready for publication as a >>>>>> Proposed Standard. I have one minor question below (flagged as >>>>>> "Spencer (minor)"), along with some editorial suggestions to be >>>>>> considered when this document is edited (either in the working >>>>>> >> group >> >>>>>> or by the RFC Editor). >>>>>> >>>>>> Abstract >>>>>> >>>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>>> >>>>>> >>>>> the >>>>> >>>>> >>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>> domain. >>>>>> >>>>>> Spencer (clarity): I'm not sure what the relationship between a >>>>>> Diffserv domain and a PCN-domain is - this couuld be clearer, >>>>>> especially in an Abstract. I note that RFC 5559 doesn't use the >>>>>> >> term >> >>>>>> PCN-domain in its Abstract ... I can guess, but I'm just guessing. >>>>>> >>>>>> The overall rate of the PCN-traffic is metered on every link in >>>>>> >>>>>> >>>> the >>>> >>>> >>>>>> PCN-domain, and PCN-packets are appropriately marked when >>>>>> >> certain >> >>>>>> configured rates are exceeded. The level of marking allows the >>>>>> boundary nodes to make decisions about whether to admit or block >>>>>> >> a >> >>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>> terminate some of the existing flows, thereby protecting the QoS >>>>>> >>>>>> >>>> of >>>> >>>> >>>>>> previously admitted flows. This document specifies how such >>>>>> >> marks >> >>>>>> are to be encoded into the IP header by re-using the Explicit >>>>>> Congestion Notification (ECN) codepoints within this controlled >>>>>> domain. The baseline encoding described here provides for only >>>>>> >>>>>> >>>> two >>>> >>>> >>>>>> PCN encoding states, Not-marked and PCN-marked. >>>>>> >>>>>> 4. Encoding two PCN States in IP >>>>>> >>>>>> The following rules apply to all PCN traffic: >>>>>> >>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be >>>>>> chosen that are already defined for use with admission >>>>>> >>>>>> >>>>> controlled >>>>> >>>>> >>>>>> traffic. Appendix A.1 gives guidance to implementiors on >>>>>> suitable >>>>>> >>>>>> Spencer (clarity): s/implementiors/implementers/? >>>>>> >>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- >>>>>> >> domain >> >>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>>>> >>>>>> o Any packet that is not-PCN but which shares the same Diffserv >>>>>> codepoint as PCN-enabled traffic MUST have the ECN field of >>>>>> >> its >> >>>>>> outermost IP header equal to 00. >>>>>> >>>>>> Spencer (minor): this is the only point in the specification (that >>>>>> >> I >> >>>>>> can >>>>>> find) that makes reference to the "outermost IP header". I'm not >>>>>> >>>>>> >>>> sure >>>> >>>> >>>>>> whether to suggest s/outermost// here or to ask that a statement >>>>>> >> be >> >>>>>> added earlier in the document to clearly state that PCN encoding >>>>>> >>>>>> >>>> only >>>> >>>> >>>>>> protects inelastic traffic when it's used for the outermost IP >>>>>> >>>>>> >>>>> header, >>>>> >>>>> >>>>>> but the current text seems to call attention to this in a way that >>>>>> makes the reader wonder what is special about THIS requirement >>>>>> >> that >> >>>>>> isn't true of the other requirements listed. >>>>>> >>>>>> 4.3. PCN-Compatible Diffserv Codepoints >>>>>> >>>>>> Enabling PCN marking behaviour for a specific DSCP disables any >>>>>> other >>>>>> marking behaviour (e.g. enabling PCN disables the default ECN >>>>>> marking >>>>>> behaviour introduced in [RFC3168]). All traffic metering and >>>>>> marking >>>>>> >>>>>> Spencer (clarity): here, and in Section 6, the text uses >>>>>> >> "disables" >> >>>>> to >>>>> >>>>> >>>>>> describe the relationship between PCN and ECN. If I understand the >>>>>> point, the domain is substituting one behavior for another. I >>>>>> >> might >> >>>>>> suggest "replaces" to describe the relationship in both locations. >>>>>> >>>>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >>>>>> >>>>>> >>>> This >>>> >>>> >>>>>> ensures compliance with the BCP guidance set out in [RFC4774]. >>>>>> >>>>>> 4.3.1. Co-existence of PCN and not-PCN traffic >>>>>> >>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >>>>>> envisaged as a marking behaviour that could be applied to a >>>>>> >> number >> >>>>>> of >>>>>> different DSCPs makes it essential that we provide a not-PCN >>>>>> >>>>>> >>>> state. >>>> >>>> >>>>>> As stated above (and expanded in Appendix A.1) the aim is for >>>>>> >> PCN >> >>>>> to >>>>> >>>>> >>>>>> re-use existing DSCPs. Because PCN re-defines the meaning of >>>>>> >> the >> >>>>>> ECN >>>>>> >>>>>> Spencer (clarity): here, the text uses "re-defines", which I like >>>>>> better than "disables", but if you go for "replaces" previously >>>>>> >> and >> >>>>> in >>>>> >>>>> >>>>>> section 6, you might want to use the same wording here. >>>>>> >>>>>> field for such DSCPs it is important to allow an operator to >>>>>> >> still >> >>>>>> use the DSCP for traffic that isn't PCN-enabled. This is >>>>>> >> achieved >> >>>>>> by >>>>>> providing a not-PCN state within the encoding scheme. >>>>>> >>>>>> A.1. Choice of Suitable DSCPs >>>>>> >>>>>> The PCN Working Group chose not to define a single DSCP for use >>>>>> >>>>>> >>>>> with >>>>> >>>>> >>>>>> PCN for several reasons. Firstly the PCN mechanism is >>>>>> >> applicable >> >>>>> to >>>>> >>>>> >>>>>> a variety of different traffic classes. Secondly standards >>>>>> >> track >> >>>>>> DSCPs are in increasingly short supply. Thirdly PCN should be >>>>>> >>>>>> >>>> seen >>>> >>>> >>>>>> as being essentially a marking behaviour similar to ECN but >>>>>> >>>>>> >>>>> intended >>>>> >>>>> >>>>>> for inelastic traffic. The choice of which DSCP is most >>>>>> >> suitable >> >>>>>> for >>>>>> a given PCN-domain is dependent on the nature of the traffic >>>>>> entering >>>>>> that domain and the link rates of all the links making up that >>>>>> domain. In PCN-domains with uniformly high link rates, the >>>>>> appropriate DSCPs would currently be those for the Real Time >>>>>> >>>>>> >>>>> Traffic >>>>> >>>>> >>>>>> Class [RFC5127]. To be clear the PCN Working Group recommends >>>>>> >>>>>> >>>>> using >>>>> >>>>> >>>>>> Spencer (clarity): is this 2119 language (apparently not, since >>>>>> >> this >> >>>>>> section is not normative), or are you saying "suggests"? My >>>>>> >>>>>> >>>>> suggestion >>>>> >>>>> >>>>>> is that we not use 2119 language, even lowercased, except for >>>>>> normative text - this seems to cause confusion from time to time. >>>>>> >>>>>> >>>> But >>>> >>>> >>>>>> please check with your shepherding AD to see if he agrees. >>>>>> >>>>>> admission control for the following service classes: >>>>>> >>>>>> o Telephony (EF) >>>>>> >>>>>> o Real-time interactive (CS4) >>>>>> >>>>>> o Broadcast Video (CS3) >>>>>> >>>>>> o Multimedia Conferencing (AF4) >>>>>> >>>>>> _______________________________________________ >>>>>> Gen-art mailing list >>>>>> Gen-art@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/gen-art >>>>>> >>>>>> >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>>> >>>> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >>> >>> >> -- >> 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 >> -- 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 bob@homefarmparham.co.uk Wed Aug 26 08:51:14 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 00EEA3A6ABC for ; Wed, 26 Aug 2009 08:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_91=0.6, SARE_OBFU_COULD=0.917] 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 v4ioYY0hdijg for ; Wed, 26 Aug 2009 08:51:12 -0700 (PDT) Received: from smtp-wifi.orange.fr (smtp-wifi-out.orange.fr [80.12.242.163]) by core3.amsl.com (Postfix) with ESMTP id A965E3A6B67 for ; Wed, 26 Aug 2009 08:51:02 -0700 (PDT) Received: from BTG127939.homefarmparham.co.uk (unknown [81.253.89.144]) by mwinf5908 (SMTP Server) with ESMTP id B5D791C000D0; Wed, 26 Aug 2009 17:50:26 +0200 (CEST) X-ME-UUID: 20090826155026744.B5D791C000D0@mwinf5908 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Aug 2009 16:50:15 +0100 To: menth@informatik.uni-wuerzburg.de, Ruediger.Geib@telekom.de From: Bob Briscoe In-Reply-To: <4A9550E1.10801@informatik.uni-wuerzburg.de> References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> <4A9550E1.10801@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <20090826155026.B5D791C000D0@mwinf5908> Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 15:51:14 -0000 Michael, I agree that we should use the term PCN to mean=20 the notification part, not the whole traffic=20 control system built around it. We had this=20 discussion when publishing the architecture. * CORRECT: what Phil did in the Intro to the architecture. "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. " (paraphrasing: the *objective* of notification is to protect QoS) * INCORRECT: The first sentence of Toby's abstract says: "Pre-Congestion Notification (PCN) is a metering and marking scheme that protects the quality of service (QoS) of=20 inelastic flows within a Diffserv domain." (paraphrasing: notification *is* a scheme that protects QoS) Suggestion to fix the first=20 sentence:"Pre-Congestion Notification (PCN) is a=20 scheme for metering and marking packets that=20 can be used to protect the quality of service=20 (QoS) of inelastic flows within a Diffserv domain." Bob At 16:12 26/08/2009, Michael Menth wrote: >Hi Ruediger, Toby, > >Ruediger.Geib@telekom.de schrieb: >>Toby, >> >>you simply ommited some "PCN" in your new=20 >>version. I think the problem addressed by=20 >>Spencer may be that you try to sum up RFC5559 rather then refer to it. >>Below there's an abstract proposal, structured top-down: >>- What's PCN: a copy of the abstract of RFC5559. >>- What's the functionality relevant for this document: marking >>- What's specified by this document: baseline encoding >>My try: >> >>PCN specifies flow admission and termination=20 >>based on pre-congestion information in order to=20 >>protect the quality of service of established,=20 >>inelastic flows within a single Diffserv domain. >What is PCN? Or is admission control and flow=20 >termination also part of PCN? My take on this is=20 >that PCN is only the marking scheme and the way=20 >the information is carried to egress nodes. AC=20 >and FT is just built on top of PCN. And to=20 >support QoS is the objective of AC and FT, not=20 >primarily or only indirectly the objective of the marking scheme. > >Regards, > > Michael > >>As a part of this specification, the overall=20 >>rate of the PCN coloured traffic is metered on=20 >>every link in the domain, and these packets are=20 >>appropriately marked when certain configured rates are exceeded. >>This document specifies how such marks are=20 >>encoded into the IP header by re-using the=20 >>Explicit Congestion Notification (ECN)=20 >>codepoints within this controlled domain. The=20 >>baseline encoding described here provides for=20 >>only two PCN encoding states, Not-marked and PCN-marked. >> >> >> >>Please maintain the notion of "overall rate of=20 >>PCN traffic" or "PCN coloured traffic" which is=20 >>being metered in the version of abstract you go on with. >> >>Regards, >> >>Ruediger >> >> >> >>-----Original Message----- >>From: toby.moncaster@bt.com=20 >>[mailto:toby.moncaster@bt.com] Sent: Wednesday, August 26, 2009 1:13 PM >>To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger >>Cc: bob@homefarmparham.co.uk; pcn@ietf.org >>Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART=20 >>Review ofdraft-ietf-pcn-baseline-encoding-05 >> >>So would the following sound better? : >> >> Pre-Congestion Notification (PCN) is a=20 >> metering and marking scheme that protects=20 >> the quality of service (QoS) of inelastic=20 >> flows within a Diffserv domain. The overall=20 >> rate of the traffic is metered on=20 >> every link in the domain, and packets are appropriately marked when= certain >> configured rates are exceeded. Boundary nodes can measure the level >> of marking and thus make decisions about whether to admit or block a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS of >> previously admitted flows. This document specifies how such marks >> are encoded into the IP header by re-using the Explicit Congestion >> Notification (ECN) codepoints within this controlled domain. The >> baseline encoding described here provides for only two PCN encoding >> states, Not-marked and PCN-marked. >> >>Just for clarity here was the earlier version I proposed: >> >> The objective of Pre-Congestion Notification (PCN) is to protect the >> quality of service (QoS) of inelastic flows within a Diffserv domain. >> The overall rate of the traffic is metered on every link in the >> domain, and packets are appropriately marked when certain >> configured rates are exceeded. Boundary nodes can measure the level >> of marking and thus make decisions about whether to admit or block a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS of >> previously admitted flows. This document specifies how such marks >> are encoded into the IP header by re-using the Explicit Congestion >> Notification (ECN) codepoints within this controlled domain. The >> baseline encoding described here provides for only two PCN encoding >> states, Not-marked and PCN-marked. >> >>I personally disagree with Tom's suggestion to=20 >>add PCN to all the defined terms (e.g. PCN=20 >>flow, PCN traffic) - that is fine within the=20 >>body of the document but in this abstract we=20 >>should avoid using any terms that readers >>won't be already familiar with. >> >> >> >> >>>-----Original Message----- >>>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>Sent: 26 August 2009 08:46 >>>To: Ruediger.Geib@telekom.de >>>Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >>>Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>baseline-encoding-05 >>> >>>Hi all, >>> >>>R=FCdiger touches an issue that I also feel is not optimally solved in >>>the >>>current abstract. The objective of PCN is provide marking information >>>to >>>egress node and the objective of admission control and flow termination >>>is to protect QoS. I use the following short explanation for PCN. Maybe >>>this idea could be added to the current abstract. >>> >>>Pre-congestion notification (PCN) is a metering and marking scheme for >>>Differentiated Services (DiffServ) IP networks which provides egress >>>nodes with information about load conditions inside the network >>>\cite{RFC5559}. This information is used for admission control and flow >>>termination to support quality of service (QoS) for admitted inelastic >>>realtime flows that are carried with prioritization within the DiffServ >>>domain. >>>This document specifies how nodes encode the marking information in the >>>IP header by re-using the Explicit Congestion Notification (ECN) >>>codepoints within a controlled DiffServ domain. The baseline encoding >>>described here provides for only two PCN encoding states which are >>>not-marked and PCN-marked. >>> >>>Regards, >>> >>> Michael >>> >>>Ruediger.Geib@telekom.de schrieb: >>> >>>>Toby, Bob >>>> >>>>if the abstract is to mention PCN functionalities not defined within >>>>this document in a rather simplified way, would the purpose of PCN >>>>be to enable a Diffserv domain to support measurement based >>>>admission control as defined by PCN architecture? >>>> >>>>Regards, >>>> >>>>Ruediger >>>> >>>>-----Original Message----- >>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>>> >>>Bob Briscoe >>> >>>>Sent: Tuesday, August 25, 2009 8:42 PM >>>>To: toby.moncaster@bt.com; pcn@ietf.org >>>>Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>> >>>baseline-encoding-05 >>> >>>>Toby, >>>> >>>>I think this isn't just good for a casual reader, but it is actually >>>>still correct and doesn't require defining PC-domain (which is just >>>>the Diffserv domain once the described measures - the PDB - have been >>>>put in place). >>>> >>>> >>>>Bob >>>> >>>>At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>>> >>>> >>>>>This potentially raises an issue for all future PCN documents since >>>>> >>>the >>> >>>>>abstract was based on our agreed standard elevator-pitch >>>>> >>>introduction to >>> >>>>>PCN... Specifically Spencer raises the question of using the defined >>>>>term PCN-domain in the abstract. Any thoughts from anyone as to >>>>> >>>whether >>> >>>>>this is confusing? Would it be clearer to just use "domain" (e.g. >>>>> >>>drop >>> >>>>>the "PCN-"). In which case should I alter the whole abstract as >>>>> >>>follows >>> >>>>>(note: I realise this is strictly incorrect as it now doesn't seek >>>>> >>>to >>> >>>>>distinguish the non-PCN and PCN traffic from each other but is this >>>>>clearer for a casual reader?): >>>>> >>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>> >>>the >>> >>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>> >>>domain. >>> >>>>> The overall rate of the traffic is metered on every link in the >>>>> domain, and packets are appropriately marked when certain >>>>> configured rates are exceeded. Boundary nodes can measure the >>>>> >>>level >>> >>>>> of marking and thus make decisions about whether to admit or >>>>> >>>block a >>> >>>>> new flow request, and (in abnormal circumstances) whether to >>>>> terminate some of the existing flows, thereby protecting the QoS >>>>> >>>of >>> >>>>> previously admitted flows. This document specifies how such >>>>> >>>marks >>> >>>>> are encoded into the IP header by re-using the Explicit >>>>> >>>Congestion >>> >>>>> Notification (ECN) codepoints within this controlled domain. The >>>>> baseline encoding described here provides for only two PCN >>>>> >>>encoding >>> >>>>> states, Not-marked and PCN-marked. >>>>> >>>>>Toby >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>>>> >>>Of >>> >>>>>>Lars Eggert >>>>>>Sent: 25 August 2009 15:12 >>>>>>To: pcn@ietf.org >>>>>>Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>>>>> >>>>>> >>>>>ofdraft-ietf-pcn-baseline- >>>>> >>>>> >>>>>>encoding-05 >>>>>> >>>>>> >>>>>> >>>>>>Begin forwarded message: >>>>>> >>>>>> >>>>>> >>>>>>>From: Spencer Dawkins >>>>>>>Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>>>To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>>> >>>>>>> >>>>>>>>> >>>>> >>>>>>pcn-baseline-encoding@tools.ietf.org >>>>>> >>>>>> >>>>>>>Cc: General Area Review Team , >>>>>>> >>>>>>> >>>>>>"ietf@ietf.org >>>>>> >>>>>> >>>>>>>" >>>>>>>Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>>>>>encoding-05 >>>>>>> >>>>>>>I have been selected as the General Area Review Team (Gen-ART) >>>>>>>reviewer for this draft (for background on Gen-ART, please see >>>>>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>>> >>>>>>>Please wait for direction from your document shepherd or AD before >>>>>>>posting a new version of the draft. >>>>>>> >>>>>>>Document: draft-ietf-pcn-baseline-encoding-05 >>>>>>>Reviewer: Spencer Dawkins >>>>>>>IETF LC End Date: 2009-09-03 >>>>>>>Review Date: 2009-08-21 >>>>>>>IESG Telechat date: (not known) >>>>>>> >>>>>>>Summary: this specification is almost ready for publication as a >>>>>>>Proposed Standard. I have one minor question below (flagged as >>>>>>>"Spencer (minor)"), along with some editorial suggestions to be >>>>>>>considered when this document is edited (either in the working >>>>>>> >>>group >>> >>>>>>>or by the RFC Editor). >>>>>>> >>>>>>>Abstract >>>>>>> >>>>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>>>> >>>>>>> >>>>>>the >>>>>> >>>>>> >>>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>>>domain. >>>>>>> >>>>>>>Spencer (clarity): I'm not sure what the relationship between a >>>>>>>Diffserv domain and a PCN-domain is - this couuld be clearer, >>>>>>>especially in an Abstract. I note that RFC 5559 doesn't use the >>>>>>> >>>term >>> >>>>>>>PCN-domain in its Abstract ... I can guess, but I'm just guessing. >>>>>>> >>>>>>> The overall rate of the PCN-traffic is metered on every link in >>>>>>> >>>>>>> >>>>>the >>>>> >>>>> >>>>>>> PCN-domain, and PCN-packets are appropriately marked when >>>>>>> >>>certain >>> >>>>>>> configured rates are exceeded. The level of marking allows the >>>>>>> boundary nodes to make decisions about whether to admit or block >>>>>>> >>>a >>> >>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>> terminate some of the existing flows, thereby protecting the QoS >>>>>>> >>>>>>> >>>>>of >>>>> >>>>> >>>>>>> previously admitted flows. This document specifies how such >>>>>>> >>>marks >>> >>>>>>> are to be encoded into the IP header by re-using the Explicit >>>>>>> Congestion Notification (ECN) codepoints within this controlled >>>>>>> domain. The baseline encoding described here provides for only >>>>>>> >>>>>>> >>>>>two >>>>> >>>>> >>>>>>> PCN encoding states, Not-marked and PCN-marked. >>>>>>> >>>>>>>4. Encoding two PCN States in IP >>>>>>> >>>>>>> The following rules apply to all PCN traffic: >>>>>>> >>>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be >>>>>>> chosen that are already defined for use with admission >>>>>>> >>>>>>> >>>>>>controlled >>>>>> >>>>>> >>>>>>> traffic. Appendix A.1 gives guidance to implementiors on >>>>>>>suitable >>>>>>> >>>>>>>Spencer (clarity): s/implementiors/implementers/? >>>>>>> >>>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- >>>>>>> >>>domain >>> >>>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>>>>> >>>>>>> o Any packet that is not-PCN but which shares the same Diffserv >>>>>>> codepoint as PCN-enabled traffic MUST have the ECN field of >>>>>>> >>>its >>> >>>>>>> outermost IP header equal to 00. >>>>>>> >>>>>>>Spencer (minor): this is the only point in the specification (that >>>>>>> >>>I >>> >>>>>>>can >>>>>>>find) that makes reference to the "outermost IP header". I'm not >>>>>>> >>>>>>> >>>>>sure >>>>> >>>>> >>>>>>>whether to suggest s/outermost// here or to ask that a statement >>>>>>> >>>be >>> >>>>>>>added earlier in the document to clearly state that PCN encoding >>>>>>> >>>>>>> >>>>>only >>>>> >>>>> >>>>>>>protects inelastic traffic when it's used for the outermost IP >>>>>>> >>>>>>> >>>>>>header, >>>>>> >>>>>> >>>>>>>but the current text seems to call attention to this in a way that >>>>>>>makes the reader wonder what is special about THIS requirement >>>>>>> >>>that >>> >>>>>>>isn't true of the other requirements listed. >>>>>>> >>>>>>>4.3. PCN-Compatible Diffserv Codepoints >>>>>>> >>>>>>> Enabling PCN marking behaviour for a specific DSCP disables any >>>>>>>other >>>>>>> marking behaviour (e.g. enabling PCN disables the default ECN >>>>>>>marking >>>>>>> behaviour introduced in [RFC3168]). All traffic metering and >>>>>>>marking >>>>>>> >>>>>>>Spencer (clarity): here, and in Section 6, the text uses >>>>>>> >>>"disables" >>> >>>>>>to >>>>>> >>>>>> >>>>>>>describe the relationship between PCN and ECN. If I understand the >>>>>>>point, the domain is substituting one behavior for another. I >>>>>>> >>>might >>> >>>>>>>suggest "replaces" to describe the relationship in both locations. >>>>>>> >>>>>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >>>>>>> >>>>>>> >>>>>This >>>>> >>>>> >>>>>>> ensures compliance with the BCP guidance set out in [RFC4774]. >>>>>>> >>>>>>>4.3.1. Co-existence of PCN and not-PCN traffic >>>>>>> >>>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >>>>>>> envisaged as a marking behaviour that could be applied to a >>>>>>> >>>number >>> >>>>>>>of >>>>>>> different DSCPs makes it essential that we provide a not-PCN >>>>>>> >>>>>>> >>>>>state. >>>>> >>>>> >>>>>>> As stated above (and expanded in Appendix A.1) the aim is for >>>>>>> >>>PCN >>> >>>>>>to >>>>>> >>>>>> >>>>>>> re-use existing DSCPs. Because PCN re-defines the meaning of >>>>>>> >>>the >>> >>>>>>>ECN >>>>>>> >>>>>>>Spencer (clarity): here, the text uses "re-defines", which I like >>>>>>>better than "disables", but if you go for "replaces" previously >>>>>>> >>>and >>> >>>>>>in >>>>>> >>>>>> >>>>>>>section 6, you might want to use the same wording here. >>>>>>> >>>>>>> field for such DSCPs it is important to allow an operator to >>>>>>> >>>still >>> >>>>>>> use the DSCP for traffic that isn't PCN-enabled. This is >>>>>>> >>>achieved >>> >>>>>>>by >>>>>>> providing a not-PCN state within the encoding scheme. >>>>>>> >>>>>>>A.1. Choice of Suitable DSCPs >>>>>>> >>>>>>> The PCN Working Group chose not to define a single DSCP for use >>>>>>> >>>>>>> >>>>>>with >>>>>> >>>>>> >>>>>>> PCN for several reasons. Firstly the PCN mechanism is >>>>>>> >>>applicable >>> >>>>>>to >>>>>> >>>>>> >>>>>>> a variety of different traffic classes. Secondly standards >>>>>>> >>>track >>> >>>>>>> DSCPs are in increasingly short supply. Thirdly PCN should be >>>>>>> >>>>>>> >>>>>seen >>>>> >>>>> >>>>>>> as being essentially a marking behaviour similar to ECN but >>>>>>> >>>>>>> >>>>>>intended >>>>>> >>>>>> >>>>>>> for inelastic traffic. The choice of which DSCP is most >>>>>>> >>>suitable >>> >>>>>>>for >>>>>>> a given PCN-domain is dependent on the nature of the traffic >>>>>>>entering >>>>>>> that domain and the link rates of all the links making up that >>>>>>> domain. In PCN-domains with uniformly high link rates, the >>>>>>> appropriate DSCPs would currently be those for the Real Time >>>>>>> >>>>>>> >>>>>>Traffic >>>>>> >>>>>> >>>>>>> Class [RFC5127]. To be clear the PCN Working Group recommends >>>>>>> >>>>>>> >>>>>>using >>>>>> >>>>>> >>>>>>>Spencer (clarity): is this 2119 language (apparently not, since >>>>>>> >>>this >>> >>>>>>>section is not normative), or are you saying "suggests"? My >>>>>>> >>>>>>> >>>>>>suggestion >>>>>> >>>>>> >>>>>>>is that we not use 2119 language, even lowercased, except for >>>>>>>normative text - this seems to cause confusion from time to time. >>>>>>> >>>>>>> >>>>>But >>>>> >>>>> >>>>>>>please check with your shepherding AD to see if he agrees. >>>>>>> >>>>>>> admission control for the following service classes: >>>>>>> >>>>>>> o Telephony (EF) >>>>>>> >>>>>>> o Real-time interactive (CS4) >>>>>>> >>>>>>> o Broadcast Video (CS3) >>>>>>> >>>>>>> o Multimedia Conferencing (AF4) >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Gen-art mailing list >>>>>>>Gen-art@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/gen-art >>>>>>> >>>>>>> >>>>>_______________________________________________ >>>>>PCN mailing list >>>>>PCN@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/pcn >>>>> >>>>> >>>>_______________________________________________ >>>>PCN mailing list >>>>PCN@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pcn >>>>_______________________________________________ >>>>PCN mailing list >>>>PCN@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pcn >>>> >>>> >>>-- >>>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 >>> > >-- >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 Aug 26 08:54: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 0E84828C15E for ; Wed, 26 Aug 2009 08:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 aSUc0IuKRaTR for ; Wed, 26 Aug 2009 08:54:36 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9A2E93A6A62 for ; Wed, 26 Aug 2009 08:54:35 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 16:28:27 +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: Wed, 26 Aug 2009 16:27:41 +0100 Message-ID: In-Reply-To: <4A9550E1.10801@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcomX8n8zTI9xzWQQ+O/BmRjvudSxQAAILqQ References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> <4A9550E1.10801@informatik.uni-wuerzburg.de> From: To: , X-OriginalArrivalTime: 26 Aug 2009 15:28:27.0003 (UTC) FILETIME=[DB8414B0:01CA2661] Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 15:54:38 -0000 I think my understanding was that, although strictly PCN is just a = metering and marking algorithm, the PCN architecture puts it into a = context where the new capability it provides is measurement-based = admission control and flow termination. My thought is, for the purposes = of understanding the context that the baseline encoding is written in, = this is an important aspect. However this does perhaps need some more thought since at one point we = were talking about the encoding being the base for the whole system and = being able to be applied in other contexts. Having said that, this is = the output of one working group and is intended to be the enabler for = one architecture. If people seek to use it in other contexts they will = probably need to provide a different architecture that specifies how to = use it in those contexts. Ultimately the abstract only needs to set the scene and summarise the = solution in a brief fashion that allows people to quickly parse the = important information. To my mind the important information for this = scheme is: it can encode two states, it is intended for use in PCN, = specifically in the context of the PCN architecture, and it re-uses the = ECN bits in the IP header. I believe the scene is set by explaining that = the motivation behind PCN was to provide a mechanism to protect the QoS = of inelastic flows through the use of MBAC and FT... However we are now starting to go in circles and probably should turn to = either Steve (as document shepherd) or Lars (as shepherding AD) for a = decision on this! Toby > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 26 August 2009 16:13 > To: Ruediger.Geib@telekom.de > Cc: Moncaster,T,Toby,DER3 R; bob@homefarmparham.co.uk; pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 >=20 > Hi Ruediger, Toby, >=20 > Ruediger.Geib@telekom.de schrieb: > > Toby, > > > > you simply ommited some "PCN" in your new version. I think the > > problem addressed by Spencer may be that you try to sum up > > RFC5559 rather then refer to it. > > > > Below there's an abstract proposal, structured top-down: > > - What's PCN: a copy of the abstract of RFC5559. > > - What's the functionality relevant for this document: marking > > - What's specified by this document: baseline encoding > > > > My try: > > > > PCN specifies 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. > What is PCN? Or is admission control and flow termination also part of > PCN? My take on this is that PCN is only the marking scheme and the = way > the information is carried to egress nodes. AC and FT is just built on > top of PCN. And to support QoS is the objective of AC and FT, not > primarily or only indirectly the objective of the marking scheme. >=20 > Regards, >=20 > Michael >=20 > > As a part of this > > specification, the overall rate of the PCN coloured traffic is > metered > > on every link in the domain, and these packets are appropriately > marked > > when certain configured rates are exceeded. > > This document specifies how such marks are encoded into the IP = header > > by re-using the Explicit Congestion Notification (ECN) codepoints > > within this controlled domain. The baseline encoding described here > > provides for only two PCN encoding states, Not-marked and = PCN-marked. > > > > > > > > Please maintain the notion of "overall rate of PCN traffic" or > > "PCN coloured traffic" which is being metered in the version of > > abstract you go on with. > > > > Regards, > > > > Ruediger > > > > > > > > -----Original Message----- > > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > > Sent: Wednesday, August 26, 2009 1:13 PM > > To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger > > Cc: bob@homefarmparham.co.uk; pcn@ietf.org > > Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > baseline-encoding-05 > > > > So would the following sound better? : > > > > Pre-Congestion Notification (PCN) is a metering and marking = scheme > > that protects the quality of service (QoS) of inelastic flows > within > > a Diffserv domain. The overall rate of the traffic is metered on > every > > link in the domain, and packets are appropriately marked when > certain > > configured rates are exceeded. Boundary nodes can measure the > level > > of marking and thus make decisions about whether to admit or = block > a > > new flow request, and (in abnormal circumstances) whether to > > terminate some of the existing flows, thereby protecting the QoS > of > > previously admitted flows. This document specifies how such = marks > > are encoded into the IP header by re-using the Explicit = Congestion > > Notification (ECN) codepoints within this controlled domain. The > > baseline encoding described here provides for only two PCN > encoding > > states, Not-marked and PCN-marked. > > > > Just for clarity here was the earlier version I proposed: > > > > The objective of Pre-Congestion Notification (PCN) is to protect > the > > quality of service (QoS) of inelastic flows within a Diffserv > domain. > > The overall rate of the traffic is metered on every link in the > > domain, and packets are appropriately marked when certain > > configured rates are exceeded. Boundary nodes can measure the > level > > of marking and thus make decisions about whether to admit or = block > a > > new flow request, and (in abnormal circumstances) whether to > > terminate some of the existing flows, thereby protecting the QoS > of > > previously admitted flows. This document specifies how such = marks > > are encoded into the IP header by re-using the Explicit = Congestion > > Notification (ECN) codepoints within this controlled domain. The > > baseline encoding described here provides for only two PCN > encoding > > states, Not-marked and PCN-marked. > > > > I personally disagree with Tom's suggestion to add PCN to all the > defined > > terms (e.g. PCN flow, PCN traffic) - that is fine within the body of > the > > document but in this abstract we should avoid using any terms that > readers > > won't be already familiar with. > > > > > > > > > >> -----Original Message----- > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >> Sent: 26 August 2009 08:46 > >> To: Ruediger.Geib@telekom.de > >> Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org > >> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > >> baseline-encoding-05 > >> > >> Hi all, > >> > >> R=FCdiger touches an issue that I also feel is not optimally solved = in > >> the > >> current abstract. The objective of PCN is provide marking > information > >> to > >> egress node and the objective of admission control and flow > termination > >> is to protect QoS. I use the following short explanation for PCN. > Maybe > >> this idea could be added to the current abstract. > >> > >> Pre-congestion notification (PCN) is a metering and marking scheme > for > >> Differentiated Services (DiffServ) IP networks which provides = egress > >> nodes with information about load conditions inside the network > >> \cite{RFC5559}. This information is used for admission control and > flow > >> termination to support quality of service (QoS) for admitted > inelastic > >> realtime flows that are carried with prioritization within the > DiffServ > >> domain. > >> This document specifies how nodes encode the marking information in > the > >> IP header by re-using the Explicit Congestion Notification (ECN) > >> codepoints within a controlled DiffServ domain. The baseline > encoding > >> described here provides for only two PCN encoding states which are > >> not-marked and PCN-marked. > >> > >> Regards, > >> > >> Michael > >> > >> Ruediger.Geib@telekom.de schrieb: > >> > >>> Toby, Bob > >>> > >>> if the abstract is to mention PCN functionalities not defined > within > >>> this document in a rather simplified way, would the purpose of PCN > >>> be to enable a Diffserv domain to support measurement based > >>> admission control as defined by PCN architecture? > >>> > >>> Regards, > >>> > >>> Ruediger > >>> > >>> -----Original Message----- > >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > >>> > >> Bob Briscoe > >> > >>> Sent: Tuesday, August 25, 2009 8:42 PM > >>> To: toby.moncaster@bt.com; pcn@ietf.org > >>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > >>> > >> baseline-encoding-05 > >> > >>> Toby, > >>> > >>> I think this isn't just good for a casual reader, but it is > actually > >>> still correct and doesn't require defining PC-domain (which is = just > >>> the Diffserv domain once the described measures - the PDB - have > been > >>> put in place). > >>> > >>> > >>> Bob > >>> > >>> At 15:53 25/08/2009, toby.moncaster@bt.com wrote: > >>> > >>> > >>>> This potentially raises an issue for all future PCN documents > since > >>>> > >> the > >> > >>>> abstract was based on our agreed standard elevator-pitch > >>>> > >> introduction to > >> > >>>> PCN... Specifically Spencer raises the question of using the > defined > >>>> term PCN-domain in the abstract. Any thoughts from anyone as to > >>>> > >> whether > >> > >>>> this is confusing? Would it be clearer to just use "domain" (e.g. > >>>> > >> drop > >> > >>>> the "PCN-"). In which case should I alter the whole abstract as > >>>> > >> follows > >> > >>>> (note: I realise this is strictly incorrect as it now doesn't = seek > >>>> > >> to > >> > >>>> distinguish the non-PCN and PCN traffic from each other but is > this > >>>> clearer for a casual reader?): > >>>> > >>>> The objective of Pre-Congestion Notification (PCN) is to > protect > >>>> > >> the > >> > >>>> quality of service (QoS) of inelastic flows within a Diffserv > >>>> > >> domain. > >> > >>>> The overall rate of the traffic is metered on every link in = the > >>>> domain, and packets are appropriately marked when certain > >>>> configured rates are exceeded. Boundary nodes can measure the > >>>> > >> level > >> > >>>> of marking and thus make decisions about whether to admit or > >>>> > >> block a > >> > >>>> new flow request, and (in abnormal circumstances) whether to > >>>> terminate some of the existing flows, thereby protecting the > QoS > >>>> > >> of > >> > >>>> previously admitted flows. This document specifies how such > >>>> > >> marks > >> > >>>> are encoded into the IP header by re-using the Explicit > >>>> > >> Congestion > >> > >>>> Notification (ECN) codepoints within this controlled domain. > The > >>>> baseline encoding described here provides for only two PCN > >>>> > >> encoding > >> > >>>> states, Not-marked and PCN-marked. > >>>> > >>>> Toby > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf > >>>>> > >> Of > >> > >>>>> Lars Eggert > >>>>> Sent: 25 August 2009 15:12 > >>>>> To: pcn@ietf.org > >>>>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > >>>>> > >>>>> > >>>> ofdraft-ietf-pcn-baseline- > >>>> > >>>> > >>>>> encoding-05 > >>>>> > >>>>> > >>>>> > >>>>> Begin forwarded message: > >>>>> > >>>>> > >>>>> > >>>>>> From: Spencer Dawkins > >>>>>> Date: August 25, 2009 14:47:49 GMT+02:00 > >>>>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > >>>>>> > >>>>>> > >>>> >>>> > >>>> > >>>>> pcn-baseline-encoding@tools.ietf.org > >>>>> > >>>>> > >>>>>> Cc: General Area Review Team , > >>>>>> > >>>>>> > >>>>> "ietf@ietf.org > >>>>> > >>>>> > >>>>>> " > >>>>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > >>>>>> encoding-05 > >>>>>> > >>>>>> I have been selected as the General Area Review Team (Gen-ART) > >>>>>> reviewer for this draft (for background on Gen-ART, please see > >>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >>>>>> > >>>>>> Please wait for direction from your document shepherd or AD > before > >>>>>> posting a new version of the draft. > >>>>>> > >>>>>> Document: draft-ietf-pcn-baseline-encoding-05 > >>>>>> Reviewer: Spencer Dawkins > >>>>>> IETF LC End Date: 2009-09-03 > >>>>>> Review Date: 2009-08-21 > >>>>>> IESG Telechat date: (not known) > >>>>>> > >>>>>> Summary: this specification is almost ready for publication as = a > >>>>>> Proposed Standard. I have one minor question below (flagged as > >>>>>> "Spencer (minor)"), along with some editorial suggestions to be > >>>>>> considered when this document is edited (either in the working > >>>>>> > >> group > >> > >>>>>> or by the RFC Editor). > >>>>>> > >>>>>> Abstract > >>>>>> > >>>>>> The objective of Pre-Congestion Notification (PCN) is to > protect > >>>>>> > >>>>>> > >>>>> the > >>>>> > >>>>> > >>>>>> quality of service (QoS) of inelastic flows within a Diffserv > >>>>>> domain. > >>>>>> > >>>>>> Spencer (clarity): I'm not sure what the relationship between a > >>>>>> Diffserv domain and a PCN-domain is - this couuld be clearer, > >>>>>> especially in an Abstract. I note that RFC 5559 doesn't use the > >>>>>> > >> term > >> > >>>>>> PCN-domain in its Abstract ... I can guess, but I'm just > guessing. > >>>>>> > >>>>>> The overall rate of the PCN-traffic is metered on every link > in > >>>>>> > >>>>>> > >>>> the > >>>> > >>>> > >>>>>> PCN-domain, and PCN-packets are appropriately marked when > >>>>>> > >> certain > >> > >>>>>> configured rates are exceeded. The level of marking allows > the > >>>>>> boundary nodes to make decisions about whether to admit or > block > >>>>>> > >> a > >> > >>>>>> new flow request, and (in abnormal circumstances) whether to > >>>>>> terminate some of the existing flows, thereby protecting the > QoS > >>>>>> > >>>>>> > >>>> of > >>>> > >>>> > >>>>>> previously admitted flows. This document specifies how such > >>>>>> > >> marks > >> > >>>>>> are to be encoded into the IP header by re-using the Explicit > >>>>>> Congestion Notification (ECN) codepoints within this > controlled > >>>>>> domain. The baseline encoding described here provides for > only > >>>>>> > >>>>>> > >>>> two > >>>> > >>>> > >>>>>> PCN encoding states, Not-marked and PCN-marked. > >>>>>> > >>>>>> 4. Encoding two PCN States in IP > >>>>>> > >>>>>> The following rules apply to all PCN traffic: > >>>>>> > >>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv > >>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD > be > >>>>>> chosen that are already defined for use with admission > >>>>>> > >>>>>> > >>>>> controlled > >>>>> > >>>>> > >>>>>> traffic. Appendix A.1 gives guidance to implementiors on > >>>>>> suitable > >>>>>> > >>>>>> Spencer (clarity): s/implementiors/implementers/? > >>>>>> > >>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- > >>>>>> > >> domain > >> > >>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. > >>>>>> > >>>>>> o Any packet that is not-PCN but which shares the same > Diffserv > >>>>>> codepoint as PCN-enabled traffic MUST have the ECN field = of > >>>>>> > >> its > >> > >>>>>> outermost IP header equal to 00. > >>>>>> > >>>>>> Spencer (minor): this is the only point in the specification > (that > >>>>>> > >> I > >> > >>>>>> can > >>>>>> find) that makes reference to the "outermost IP header". I'm = not > >>>>>> > >>>>>> > >>>> sure > >>>> > >>>> > >>>>>> whether to suggest s/outermost// here or to ask that a = statement > >>>>>> > >> be > >> > >>>>>> added earlier in the document to clearly state that PCN = encoding > >>>>>> > >>>>>> > >>>> only > >>>> > >>>> > >>>>>> protects inelastic traffic when it's used for the outermost IP > >>>>>> > >>>>>> > >>>>> header, > >>>>> > >>>>> > >>>>>> but the current text seems to call attention to this in a way > that > >>>>>> makes the reader wonder what is special about THIS requirement > >>>>>> > >> that > >> > >>>>>> isn't true of the other requirements listed. > >>>>>> > >>>>>> 4.3. PCN-Compatible Diffserv Codepoints > >>>>>> > >>>>>> Enabling PCN marking behaviour for a specific DSCP disables > any > >>>>>> other > >>>>>> marking behaviour (e.g. enabling PCN disables the default ECN > >>>>>> marking > >>>>>> behaviour introduced in [RFC3168]). All traffic metering and > >>>>>> marking > >>>>>> > >>>>>> Spencer (clarity): here, and in Section 6, the text uses > >>>>>> > >> "disables" > >> > >>>>> to > >>>>> > >>>>> > >>>>>> describe the relationship between PCN and ECN. If I understand > the > >>>>>> point, the domain is substituting one behavior for another. I > >>>>>> > >> might > >> > >>>>>> suggest "replaces" to describe the relationship in both > locations. > >>>>>> > >>>>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. > >>>>>> > >>>>>> > >>>> This > >>>> > >>>> > >>>>>> ensures compliance with the BCP guidance set out in = [RFC4774]. > >>>>>> > >>>>>> 4.3.1. Co-existence of PCN and not-PCN traffic > >>>>>> > >>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN = is > >>>>>> envisaged as a marking behaviour that could be applied to a > >>>>>> > >> number > >> > >>>>>> of > >>>>>> different DSCPs makes it essential that we provide a not-PCN > >>>>>> > >>>>>> > >>>> state. > >>>> > >>>> > >>>>>> As stated above (and expanded in Appendix A.1) the aim is for > >>>>>> > >> PCN > >> > >>>>> to > >>>>> > >>>>> > >>>>>> re-use existing DSCPs. Because PCN re-defines the meaning of > >>>>>> > >> the > >> > >>>>>> ECN > >>>>>> > >>>>>> Spencer (clarity): here, the text uses "re-defines", which I > like > >>>>>> better than "disables", but if you go for "replaces" previously > >>>>>> > >> and > >> > >>>>> in > >>>>> > >>>>> > >>>>>> section 6, you might want to use the same wording here. > >>>>>> > >>>>>> field for such DSCPs it is important to allow an operator to > >>>>>> > >> still > >> > >>>>>> use the DSCP for traffic that isn't PCN-enabled. This is > >>>>>> > >> achieved > >> > >>>>>> by > >>>>>> providing a not-PCN state within the encoding scheme. > >>>>>> > >>>>>> A.1. Choice of Suitable DSCPs > >>>>>> > >>>>>> The PCN Working Group chose not to define a single DSCP for > use > >>>>>> > >>>>>> > >>>>> with > >>>>> > >>>>> > >>>>>> PCN for several reasons. Firstly the PCN mechanism is > >>>>>> > >> applicable > >> > >>>>> to > >>>>> > >>>>> > >>>>>> a variety of different traffic classes. Secondly standards > >>>>>> > >> track > >> > >>>>>> DSCPs are in increasingly short supply. Thirdly PCN should = be > >>>>>> > >>>>>> > >>>> seen > >>>> > >>>> > >>>>>> as being essentially a marking behaviour similar to ECN but > >>>>>> > >>>>>> > >>>>> intended > >>>>> > >>>>> > >>>>>> for inelastic traffic. The choice of which DSCP is most > >>>>>> > >> suitable > >> > >>>>>> for > >>>>>> a given PCN-domain is dependent on the nature of the traffic > >>>>>> entering > >>>>>> that domain and the link rates of all the links making up = that > >>>>>> domain. In PCN-domains with uniformly high link rates, the > >>>>>> appropriate DSCPs would currently be those for the Real Time > >>>>>> > >>>>>> > >>>>> Traffic > >>>>> > >>>>> > >>>>>> Class [RFC5127]. To be clear the PCN Working Group = recommends > >>>>>> > >>>>>> > >>>>> using > >>>>> > >>>>> > >>>>>> Spencer (clarity): is this 2119 language (apparently not, since > >>>>>> > >> this > >> > >>>>>> section is not normative), or are you saying "suggests"? My > >>>>>> > >>>>>> > >>>>> suggestion > >>>>> > >>>>> > >>>>>> is that we not use 2119 language, even lowercased, except for > >>>>>> normative text - this seems to cause confusion from time to > time. > >>>>>> > >>>>>> > >>>> But > >>>> > >>>> > >>>>>> please check with your shepherding AD to see if he agrees. > >>>>>> > >>>>>> admission control for the following service classes: > >>>>>> > >>>>>> o Telephony (EF) > >>>>>> > >>>>>> o Real-time interactive (CS4) > >>>>>> > >>>>>> o Broadcast Video (CS3) > >>>>>> > >>>>>> o Multimedia Conferencing (AF4) > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Gen-art mailing list > >>>>>> Gen-art@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/gen-art > >>>>>> > >>>>>> > >>>> _______________________________________________ > >>>> PCN mailing list > >>>> PCN@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/pcn > >>>> > >>>> > >>> _______________________________________________ > >>> PCN mailing list > >>> PCN@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pcn > >>> _______________________________________________ > >>> PCN mailing list > >>> PCN@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pcn > >>> > >>> > >> -- > >> 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 > >> >=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 menth@informatik.uni-wuerzburg.de Wed Aug 26 09:08:36 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 694A63A70A9 for ; Wed, 26 Aug 2009 09:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, SARE_OBFU_COULD=0.917] 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 QWPpynyIK+Pr for ; Wed, 26 Aug 2009 09:08:34 -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 E599728C2C4 for ; Wed, 26 Aug 2009 09:08:22 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 7AE82A0F12; Wed, 26 Aug 2009 17:08:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6B12AA0EDF; Wed, 26 Aug 2009 17:08:55 +0200 (CEST) Received: from [192.168.1.2] (f051180052.adsl.alicedsl.de [78.51.180.52]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CA3F9A0C67; Wed, 26 Aug 2009 17:08:54 +0200 (CEST) Message-ID: <4A954FCE.7080704@informatik.uni-wuerzburg.de> Date: Wed, 26 Aug 2009 17:07:58 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com><7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 26 Aug 2009 16:08:36 -0000 Hi Toby, the text still does not reflect the point that PCN just provides information to egress nodes. Based on this PCN information, admission control and flow termination is built which support QoS. Regards, Michael toby.moncaster@bt.com schrieb: > OK, as there seems to be more of a consensus that the abstract needs to maintain the idea of PCN traffic being distinct I will try to do a hybrid of your and my abstracts... Incidentally I quite like your approach to how to formulate the abstract... > > Pre-Congestion Notification (PCN) is a metering and marking scheme > that protects the quality of service (QoS) of inelastic flows > within a Diffserv domain. It does so by measuring pre-congestion > information at the boundaries of the domain and using this > information to determine whether to admit new flows or (in abnormal > circumstances) terminate some existing flows, thereby protecting > the QoS of previously admitted flows. This pre-congestion > information is provided by marking packets when the overall rate > of PCN traffic on a link exceeds certain configured rates. This > document specifies how such marks are encoded into the IP header > by re-using the Explicit Congestion Notification (ECN) codepoints > within this controlled domain. The baseline encoding described > here provides for only two PCN encoding states, Not-marked and > PCN-marked. > > The only slight concern I have is that the second sentence is getting rather long and unwieldy... > > Toby > > >> -----Original Message----- >> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] >> Sent: 26 August 2009 13:06 >> To: Moncaster,T,Toby,DER3 R >> Cc: bob@homefarmparham.co.uk; pcn@ietf.org; menth@informatik.uni- >> wuerzburg.de >> Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >> baseline-encoding-05 >> >> Toby, >> >> you simply ommited some "PCN" in your new version. I think the >> problem addressed by Spencer may be that you try to sum up >> RFC5559 rather then refer to it. >> >> Below there's an abstract proposal, structured top-down: >> - What's PCN: a copy of the abstract of RFC5559. >> - What's the functionality relevant for this document: marking >> - What's specified by this document: baseline encoding >> >> My try: >> >> PCN specifies 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. As a part of this >> specification, the overall rate of the PCN coloured traffic is metered >> on every link in the domain, and these packets are appropriately marked >> when certain configured rates are exceeded. >> This document specifies how such marks are encoded into the IP header >> by re-using the Explicit Congestion Notification (ECN) codepoints >> within this controlled domain. The baseline encoding described here >> provides for only two PCN encoding states, Not-marked and PCN-marked. >> >> >> >> Please maintain the notion of "overall rate of PCN traffic" or >> "PCN coloured traffic" which is being metered in the version of >> abstract you go on with. >> >> Regards, >> >> Ruediger >> >> >> >> -----Original Message----- >> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >> Sent: Wednesday, August 26, 2009 1:13 PM >> To: menth@informatik.uni-wuerzburg.de; Geib, Rüdiger >> Cc: bob@homefarmparham.co.uk; pcn@ietf.org >> Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >> baseline-encoding-05 >> >> So would the following sound better? : >> >> Pre-Congestion Notification (PCN) is a metering and marking scheme >> that protects the quality of service (QoS) of inelastic flows within >> a Diffserv domain. The overall rate of the traffic is metered on >> every >> link in the domain, and packets are appropriately marked when >> certain >> configured rates are exceeded. Boundary nodes can measure the level >> of marking and thus make decisions about whether to admit or block a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS of >> previously admitted flows. This document specifies how such marks >> are encoded into the IP header by re-using the Explicit Congestion >> Notification (ECN) codepoints within this controlled domain. The >> baseline encoding described here provides for only two PCN encoding >> states, Not-marked and PCN-marked. >> >> Just for clarity here was the earlier version I proposed: >> >> The objective of Pre-Congestion Notification (PCN) is to protect the >> quality of service (QoS) of inelastic flows within a Diffserv >> domain. >> The overall rate of the traffic is metered on every link in the >> domain, and packets are appropriately marked when certain >> configured rates are exceeded. Boundary nodes can measure the level >> of marking and thus make decisions about whether to admit or block a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS of >> previously admitted flows. This document specifies how such marks >> are encoded into the IP header by re-using the Explicit Congestion >> Notification (ECN) codepoints within this controlled domain. The >> baseline encoding described here provides for only two PCN encoding >> states, Not-marked and PCN-marked. >> >> I personally disagree with Tom's suggestion to add PCN to all the >> defined >> terms (e.g. PCN flow, PCN traffic) - that is fine within the body of >> the >> document but in this abstract we should avoid using any terms that >> readers >> won't be already familiar with. >> >> >> >> >>> -----Original Message----- >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>> Sent: 26 August 2009 08:46 >>> To: Ruediger.Geib@telekom.de >>> Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>> baseline-encoding-05 >>> >>> Hi all, >>> >>> Rüdiger touches an issue that I also feel is not optimally solved in >>> the >>> current abstract. The objective of PCN is provide marking information >>> to >>> egress node and the objective of admission control and flow >>> >> termination >> >>> is to protect QoS. I use the following short explanation for PCN. >>> >> Maybe >> >>> this idea could be added to the current abstract. >>> >>> Pre-congestion notification (PCN) is a metering and marking scheme >>> >> for >> >>> Differentiated Services (DiffServ) IP networks which provides egress >>> nodes with information about load conditions inside the network >>> \cite{RFC5559}. This information is used for admission control and >>> >> flow >> >>> termination to support quality of service (QoS) for admitted >>> >> inelastic >> >>> realtime flows that are carried with prioritization within the >>> >> DiffServ >> >>> domain. >>> This document specifies how nodes encode the marking information in >>> >> the >> >>> IP header by re-using the Explicit Congestion Notification (ECN) >>> codepoints within a controlled DiffServ domain. The baseline >>> >> encoding >> >>> described here provides for only two PCN encoding states which are >>> not-marked and PCN-marked. >>> >>> Regards, >>> >>> Michael >>> >>> Ruediger.Geib@telekom.de schrieb: >>> >>>> Toby, Bob >>>> >>>> if the abstract is to mention PCN functionalities not defined >>>> >> within >> >>>> this document in a rather simplified way, would the purpose of PCN >>>> be to enable a Diffserv domain to support measurement based >>>> admission control as defined by PCN architecture? >>>> >>>> Regards, >>>> >>>> Ruediger >>>> >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>> >> Of >> >>> Bob Briscoe >>> >>>> Sent: Tuesday, August 25, 2009 8:42 PM >>>> To: toby.moncaster@bt.com; pcn@ietf.org >>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>> >>> baseline-encoding-05 >>> >>>> Toby, >>>> >>>> I think this isn't just good for a casual reader, but it is >>>> >> actually >> >>>> still correct and doesn't require defining PC-domain (which is just >>>> the Diffserv domain once the described measures - the PDB - have >>>> >> been >> >>>> put in place). >>>> >>>> >>>> Bob >>>> >>>> At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>>> >>>> >>>>> This potentially raises an issue for all future PCN documents >>>>> >> since >> >>> the >>> >>>>> abstract was based on our agreed standard elevator-pitch >>>>> >>> introduction to >>> >>>>> PCN... Specifically Spencer raises the question of using the >>>>> >> defined >> >>>>> term PCN-domain in the abstract. Any thoughts from anyone as to >>>>> >>> whether >>> >>>>> this is confusing? Would it be clearer to just use "domain" (e.g. >>>>> >>> drop >>> >>>>> the "PCN-"). In which case should I alter the whole abstract as >>>>> >>> follows >>> >>>>> (note: I realise this is strictly incorrect as it now doesn't seek >>>>> >>> to >>> >>>>> distinguish the non-PCN and PCN traffic from each other but is >>>>> >> this >> >>>>> clearer for a casual reader?): >>>>> >>>>> The objective of Pre-Congestion Notification (PCN) is to >>>>> >> protect >> >>> the >>> >>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>> >>> domain. >>> >>>>> The overall rate of the traffic is metered on every link in the >>>>> domain, and packets are appropriately marked when certain >>>>> configured rates are exceeded. Boundary nodes can measure the >>>>> >>> level >>> >>>>> of marking and thus make decisions about whether to admit or >>>>> >>> block a >>> >>>>> new flow request, and (in abnormal circumstances) whether to >>>>> terminate some of the existing flows, thereby protecting the >>>>> >> QoS >> >>> of >>> >>>>> previously admitted flows. This document specifies how such >>>>> >>> marks >>> >>>>> are encoded into the IP header by re-using the Explicit >>>>> >>> Congestion >>> >>>>> Notification (ECN) codepoints within this controlled domain. >>>>> >> The >> >>>>> baseline encoding described here provides for only two PCN >>>>> >>> encoding >>> >>>>> states, Not-marked and PCN-marked. >>>>> >>>>> Toby >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>> >> Behalf >> >>> Of >>> >>>>>> Lars Eggert >>>>>> Sent: 25 August 2009 15:12 >>>>>> To: pcn@ietf.org >>>>>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>>>>> >>>>>> >>>>> ofdraft-ietf-pcn-baseline- >>>>> >>>>> >>>>>> encoding-05 >>>>>> >>>>>> >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> >>>>>> >>>>>>> From: Spencer Dawkins >>>>>>> Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>>> >>>>>>> >>>>> >>>> >>>>> >>>>>> pcn-baseline-encoding@tools.ietf.org >>>>>> >>>>>> >>>>>>> Cc: General Area Review Team , >>>>>>> >>>>>>> >>>>>> "ietf@ietf.org >>>>>> >>>>>> >>>>>>> " >>>>>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>>>>> encoding-05 >>>>>>> >>>>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>>>> reviewer for this draft (for background on Gen-ART, please see >>>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>>> >>>>>>> Please wait for direction from your document shepherd or AD >>>>>>> >> before >> >>>>>>> posting a new version of the draft. >>>>>>> >>>>>>> Document: draft-ietf-pcn-baseline-encoding-05 >>>>>>> Reviewer: Spencer Dawkins >>>>>>> IETF LC End Date: 2009-09-03 >>>>>>> Review Date: 2009-08-21 >>>>>>> IESG Telechat date: (not known) >>>>>>> >>>>>>> Summary: this specification is almost ready for publication as a >>>>>>> Proposed Standard. I have one minor question below (flagged as >>>>>>> "Spencer (minor)"), along with some editorial suggestions to be >>>>>>> considered when this document is edited (either in the working >>>>>>> >>> group >>> >>>>>>> or by the RFC Editor). >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> The objective of Pre-Congestion Notification (PCN) is to >>>>>>> >> protect >> >>>>>> the >>>>>> >>>>>> >>>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>>> domain. >>>>>>> >>>>>>> Spencer (clarity): I'm not sure what the relationship between a >>>>>>> Diffserv domain and a PCN-domain is - this couuld be clearer, >>>>>>> especially in an Abstract. I note that RFC 5559 doesn't use the >>>>>>> >>> term >>> >>>>>>> PCN-domain in its Abstract ... I can guess, but I'm just >>>>>>> >> guessing. >> >>>>>>> The overall rate of the PCN-traffic is metered on every link >>>>>>> >> in >> >>>>> the >>>>> >>>>> >>>>>>> PCN-domain, and PCN-packets are appropriately marked when >>>>>>> >>> certain >>> >>>>>>> configured rates are exceeded. The level of marking allows >>>>>>> >> the >> >>>>>>> boundary nodes to make decisions about whether to admit or >>>>>>> >> block >> >>> a >>> >>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>> terminate some of the existing flows, thereby protecting the >>>>>>> >> QoS >> >>>>> of >>>>> >>>>> >>>>>>> previously admitted flows. This document specifies how such >>>>>>> >>> marks >>> >>>>>>> are to be encoded into the IP header by re-using the Explicit >>>>>>> Congestion Notification (ECN) codepoints within this >>>>>>> >> controlled >> >>>>>>> domain. The baseline encoding described here provides for >>>>>>> >> only >> >>>>> two >>>>> >>>>> >>>>>>> PCN encoding states, Not-marked and PCN-marked. >>>>>>> >>>>>>> 4. Encoding two PCN States in IP >>>>>>> >>>>>>> The following rules apply to all PCN traffic: >>>>>>> >>>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD >>>>>>> >> be >> >>>>>>> chosen that are already defined for use with admission >>>>>>> >>>>>>> >>>>>> controlled >>>>>> >>>>>> >>>>>>> traffic. Appendix A.1 gives guidance to implementiors on >>>>>>> suitable >>>>>>> >>>>>>> Spencer (clarity): s/implementiors/implementers/? >>>>>>> >>>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- >>>>>>> >>> domain >>> >>>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>>>>> >>>>>>> o Any packet that is not-PCN but which shares the same >>>>>>> >> Diffserv >> >>>>>>> codepoint as PCN-enabled traffic MUST have the ECN field of >>>>>>> >>> its >>> >>>>>>> outermost IP header equal to 00. >>>>>>> >>>>>>> Spencer (minor): this is the only point in the specification >>>>>>> >> (that >> >>> I >>> >>>>>>> can >>>>>>> find) that makes reference to the "outermost IP header". I'm not >>>>>>> >>>>>>> >>>>> sure >>>>> >>>>> >>>>>>> whether to suggest s/outermost// here or to ask that a statement >>>>>>> >>> be >>> >>>>>>> added earlier in the document to clearly state that PCN encoding >>>>>>> >>>>>>> >>>>> only >>>>> >>>>> >>>>>>> protects inelastic traffic when it's used for the outermost IP >>>>>>> >>>>>>> >>>>>> header, >>>>>> >>>>>> >>>>>>> but the current text seems to call attention to this in a way >>>>>>> >> that >> >>>>>>> makes the reader wonder what is special about THIS requirement >>>>>>> >>> that >>> >>>>>>> isn't true of the other requirements listed. >>>>>>> >>>>>>> 4.3. PCN-Compatible Diffserv Codepoints >>>>>>> >>>>>>> Enabling PCN marking behaviour for a specific DSCP disables >>>>>>> >> any >> >>>>>>> other >>>>>>> marking behaviour (e.g. enabling PCN disables the default ECN >>>>>>> marking >>>>>>> behaviour introduced in [RFC3168]). All traffic metering and >>>>>>> marking >>>>>>> >>>>>>> Spencer (clarity): here, and in Section 6, the text uses >>>>>>> >>> "disables" >>> >>>>>> to >>>>>> >>>>>> >>>>>>> describe the relationship between PCN and ECN. If I understand >>>>>>> >> the >> >>>>>>> point, the domain is substituting one behavior for another. I >>>>>>> >>> might >>> >>>>>>> suggest "replaces" to describe the relationship in both >>>>>>> >> locations. >> >>>>>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >>>>>>> >>>>>>> >>>>> This >>>>> >>>>> >>>>>>> ensures compliance with the BCP guidance set out in [RFC4774]. >>>>>>> >>>>>>> 4.3.1. Co-existence of PCN and not-PCN traffic >>>>>>> >>>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >>>>>>> envisaged as a marking behaviour that could be applied to a >>>>>>> >>> number >>> >>>>>>> of >>>>>>> different DSCPs makes it essential that we provide a not-PCN >>>>>>> >>>>>>> >>>>> state. >>>>> >>>>> >>>>>>> As stated above (and expanded in Appendix A.1) the aim is for >>>>>>> >>> PCN >>> >>>>>> to >>>>>> >>>>>> >>>>>>> re-use existing DSCPs. Because PCN re-defines the meaning of >>>>>>> >>> the >>> >>>>>>> ECN >>>>>>> >>>>>>> Spencer (clarity): here, the text uses "re-defines", which I >>>>>>> >> like >> >>>>>>> better than "disables", but if you go for "replaces" previously >>>>>>> >>> and >>> >>>>>> in >>>>>> >>>>>> >>>>>>> section 6, you might want to use the same wording here. >>>>>>> >>>>>>> field for such DSCPs it is important to allow an operator to >>>>>>> >>> still >>> >>>>>>> use the DSCP for traffic that isn't PCN-enabled. This is >>>>>>> >>> achieved >>> >>>>>>> by >>>>>>> providing a not-PCN state within the encoding scheme. >>>>>>> >>>>>>> A.1. Choice of Suitable DSCPs >>>>>>> >>>>>>> The PCN Working Group chose not to define a single DSCP for >>>>>>> >> use >> >>>>>> with >>>>>> >>>>>> >>>>>>> PCN for several reasons. Firstly the PCN mechanism is >>>>>>> >>> applicable >>> >>>>>> to >>>>>> >>>>>> >>>>>>> a variety of different traffic classes. Secondly standards >>>>>>> >>> track >>> >>>>>>> DSCPs are in increasingly short supply. Thirdly PCN should be >>>>>>> >>>>>>> >>>>> seen >>>>> >>>>> >>>>>>> as being essentially a marking behaviour similar to ECN but >>>>>>> >>>>>>> >>>>>> intended >>>>>> >>>>>> >>>>>>> for inelastic traffic. The choice of which DSCP is most >>>>>>> >>> suitable >>> >>>>>>> for >>>>>>> a given PCN-domain is dependent on the nature of the traffic >>>>>>> entering >>>>>>> that domain and the link rates of all the links making up that >>>>>>> domain. In PCN-domains with uniformly high link rates, the >>>>>>> appropriate DSCPs would currently be those for the Real Time >>>>>>> >>>>>>> >>>>>> Traffic >>>>>> >>>>>> >>>>>>> Class [RFC5127]. To be clear the PCN Working Group recommends >>>>>>> >>>>>>> >>>>>> using >>>>>> >>>>>> >>>>>>> Spencer (clarity): is this 2119 language (apparently not, since >>>>>>> >>> this >>> >>>>>>> section is not normative), or are you saying "suggests"? My >>>>>>> >>>>>>> >>>>>> suggestion >>>>>> >>>>>> >>>>>>> is that we not use 2119 language, even lowercased, except for >>>>>>> normative text - this seems to cause confusion from time to >>>>>>> >> time. >> >>>>> But >>>>> >>>>> >>>>>>> please check with your shepherding AD to see if he agrees. >>>>>>> >>>>>>> admission control for the following service classes: >>>>>>> >>>>>>> o Telephony (EF) >>>>>>> >>>>>>> o Real-time interactive (CS4) >>>>>>> >>>>>>> o Broadcast Video (CS3) >>>>>>> >>>>>>> o Multimedia Conferencing (AF4) >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Gen-art mailing list >>>>>>> Gen-art@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/gen-art >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> PCN mailing list >>>>> PCN@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>> >>>>> >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>>> >>>> >>> -- >>> 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 >>> -- 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 Ruediger.Geib@telekom.de Wed Aug 26 23:51: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 CBCAE3A6A4D for ; Wed, 26 Aug 2009 23:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 KzvlSQZ3NxCG for ; Wed, 26 Aug 2009 23:51:28 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id E25C33A6813 for ; Wed, 26 Aug 2009 23:51:27 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 27 Aug 2009 08:51:30 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 08:51:30 +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: Thu, 27 Aug 2009 08:51:27 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501F68BDF@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <20090826155026.B5D791C000D0@mwinf5908> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 thread-index: AcomZPekONon+4EeSrqf9SOZ3SpKcgAe7eEA References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> <4A9550E1.10801@informatik.uni-wuerzburg.de> <20090826155026.B5D791C000D0@mwinf5908> From: To: , , X-OriginalArrivalTime: 27 Aug 2009 06:51:30.0211 (UTC) FILETIME=[CE7AF730:01CA26E2] Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 27 Aug 2009 06:51:30 -0000 Bob, Toby, Michael Bob's proposal below is allright to me. My only intention is, to explain = PCN to the=20 casual reader in the first sentence. That also works well the way Bob = phrased. Michael, does Bobs suggestion address your concerns? Toby, would decomposing the unwieldy long second sentence be an option?=20 An example: It does so by measuring pre-congestion information at the boundaries=20 of the domain. This information is used to determine whether to admit=20 new flows or (in abnormal circumstances) terminate some existing flows.=20 Thereby the QoS of previously admitted flows is protected.=20 I think, at least ending the first statement after "the boundaries of=20 the domain" is acceptable. But I'm not a native speaker, of course. Regards, Ruediger =20 -----Original Message----- From: Bob Briscoe [mailto:bob@homefarmparham.co.uk]=20 Sent: Wednesday, August 26, 2009 5:50 PM To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger Cc: toby.moncaster@bt.com; pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review = ofdraft-ietf-pcn-baseline-encoding-05 Michael, I agree that we should use the term PCN to mean=20 the notification part, not the whole traffic=20 control system built around it. We had this=20 discussion when publishing the architecture. * CORRECT: what Phil did in the Intro to the architecture. "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. " (paraphrasing: the *objective* of notification is to protect QoS) * INCORRECT: The first sentence of Toby's abstract says: "Pre-Congestion Notification (PCN) is a metering and marking scheme that protects the quality of service (QoS) of=20 inelastic flows within a Diffserv domain." (paraphrasing: notification *is* a scheme that protects QoS) Suggestion to fix the first=20 sentence:"Pre-Congestion Notification (PCN) is a=20 scheme for metering and marking packets that=20 can be used to protect the quality of service=20 (QoS) of inelastic flows within a Diffserv domain." Bob At 16:12 26/08/2009, Michael Menth wrote: >Hi Ruediger, Toby, > >Ruediger.Geib@telekom.de schrieb: >>Toby, >> >>you simply ommited some "PCN" in your new=20 >>version. I think the problem addressed by=20 >>Spencer may be that you try to sum up RFC5559 rather then refer to it. >>Below there's an abstract proposal, structured top-down: >>- What's PCN: a copy of the abstract of RFC5559. >>- What's the functionality relevant for this document: marking >>- What's specified by this document: baseline encoding >>My try: >> >>PCN specifies flow admission and termination=20 >>based on pre-congestion information in order to=20 >>protect the quality of service of established,=20 >>inelastic flows within a single Diffserv domain. >What is PCN? Or is admission control and flow=20 >termination also part of PCN? My take on this is=20 >that PCN is only the marking scheme and the way=20 >the information is carried to egress nodes. AC=20 >and FT is just built on top of PCN. And to=20 >support QoS is the objective of AC and FT, not=20 >primarily or only indirectly the objective of the marking scheme. > >Regards, > > Michael > >>As a part of this specification, the overall=20 >>rate of the PCN coloured traffic is metered on=20 >>every link in the domain, and these packets are=20 >>appropriately marked when certain configured rates are exceeded. >>This document specifies how such marks are=20 >>encoded into the IP header by re-using the=20 >>Explicit Congestion Notification (ECN)=20 >>codepoints within this controlled domain. The=20 >>baseline encoding described here provides for=20 >>only two PCN encoding states, Not-marked and PCN-marked. >> >> >> >>Please maintain the notion of "overall rate of=20 >>PCN traffic" or "PCN coloured traffic" which is=20 >>being metered in the version of abstract you go on with. >> >>Regards, >> >>Ruediger >> >> >> >>-----Original Message----- >>From: toby.moncaster@bt.com=20 >>[mailto:toby.moncaster@bt.com] Sent: Wednesday, August 26, 2009 1:13 = PM >>To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger >>Cc: bob@homefarmparham.co.uk; pcn@ietf.org >>Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART=20 >>Review ofdraft-ietf-pcn-baseline-encoding-05 >> >>So would the following sound better? : >> >> Pre-Congestion Notification (PCN) is a=20 >> metering and marking scheme that protects=20 >> the quality of service (QoS) of inelastic=20 >> flows within a Diffserv domain. The overall=20 >> rate of the traffic is metered on=20 >> every link in the domain, and packets are appropriately marked = when certain >> configured rates are exceeded. Boundary nodes can measure the = level >> of marking and thus make decisions about whether to admit or block = a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS = of >> previously admitted flows. This document specifies how such marks >> are encoded into the IP header by re-using the Explicit Congestion >> Notification (ECN) codepoints within this controlled domain. The >> baseline encoding described here provides for only two PCN = encoding >> states, Not-marked and PCN-marked. >> >>Just for clarity here was the earlier version I proposed: >> >> The objective of Pre-Congestion Notification (PCN) is to protect = the >> quality of service (QoS) of inelastic flows within a Diffserv = domain. >> The overall rate of the traffic is metered on every link in the >> domain, and packets are appropriately marked when certain >> configured rates are exceeded. Boundary nodes can measure the = level >> of marking and thus make decisions about whether to admit or block = a >> new flow request, and (in abnormal circumstances) whether to >> terminate some of the existing flows, thereby protecting the QoS = of >> previously admitted flows. This document specifies how such marks >> are encoded into the IP header by re-using the Explicit Congestion >> Notification (ECN) codepoints within this controlled domain. The >> baseline encoding described here provides for only two PCN = encoding >> states, Not-marked and PCN-marked. >> >>I personally disagree with Tom's suggestion to=20 >>add PCN to all the defined terms (e.g. PCN=20 >>flow, PCN traffic) - that is fine within the=20 >>body of the document but in this abstract we=20 >>should avoid using any terms that readers >>won't be already familiar with. >> >> >> >> >>>-----Original Message----- >>>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>Sent: 26 August 2009 08:46 >>>To: Ruediger.Geib@telekom.de >>>Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >>>Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>baseline-encoding-05 >>> >>>Hi all, >>> >>>R=FCdiger touches an issue that I also feel is not optimally solved = in >>>the >>>current abstract. The objective of PCN is provide marking information >>>to >>>egress node and the objective of admission control and flow = termination >>>is to protect QoS. I use the following short explanation for PCN. = Maybe >>>this idea could be added to the current abstract. >>> >>>Pre-congestion notification (PCN) is a metering and marking scheme = for >>>Differentiated Services (DiffServ) IP networks which provides egress >>>nodes with information about load conditions inside the network >>>\cite{RFC5559}. This information is used for admission control and = flow >>>termination to support quality of service (QoS) for admitted = inelastic >>>realtime flows that are carried with prioritization within the = DiffServ >>>domain. >>>This document specifies how nodes encode the marking information in = the >>>IP header by re-using the Explicit Congestion Notification (ECN) >>>codepoints within a controlled DiffServ domain. The baseline = encoding >>>described here provides for only two PCN encoding states which are >>>not-marked and PCN-marked. >>> >>>Regards, >>> >>> Michael >>> >>>Ruediger.Geib@telekom.de schrieb: >>> >>>>Toby, Bob >>>> >>>>if the abstract is to mention PCN functionalities not defined within >>>>this document in a rather simplified way, would the purpose of PCN >>>>be to enable a Diffserv domain to support measurement based >>>>admission control as defined by PCN architecture? >>>> >>>>Regards, >>>> >>>>Ruediger >>>> >>>>-----Original Message----- >>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of >>>> >>>Bob Briscoe >>> >>>>Sent: Tuesday, August 25, 2009 8:42 PM >>>>To: toby.moncaster@bt.com; pcn@ietf.org >>>>Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>> >>>baseline-encoding-05 >>> >>>>Toby, >>>> >>>>I think this isn't just good for a casual reader, but it is actually >>>>still correct and doesn't require defining PC-domain (which is just >>>>the Diffserv domain once the described measures - the PDB - have = been >>>>put in place). >>>> >>>> >>>>Bob >>>> >>>>At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>>> >>>> >>>>>This potentially raises an issue for all future PCN documents since >>>>> >>>the >>> >>>>>abstract was based on our agreed standard elevator-pitch >>>>> >>>introduction to >>> >>>>>PCN... Specifically Spencer raises the question of using the = defined >>>>>term PCN-domain in the abstract. Any thoughts from anyone as to >>>>> >>>whether >>> >>>>>this is confusing? Would it be clearer to just use "domain" (e.g. >>>>> >>>drop >>> >>>>>the "PCN-"). In which case should I alter the whole abstract as >>>>> >>>follows >>> >>>>>(note: I realise this is strictly incorrect as it now doesn't seek >>>>> >>>to >>> >>>>>distinguish the non-PCN and PCN traffic from each other but is this >>>>>clearer for a casual reader?): >>>>> >>>>> The objective of Pre-Congestion Notification (PCN) is to = protect >>>>> >>>the >>> >>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>> >>>domain. >>> >>>>> The overall rate of the traffic is metered on every link in the >>>>> domain, and packets are appropriately marked when certain >>>>> configured rates are exceeded. Boundary nodes can measure the >>>>> >>>level >>> >>>>> of marking and thus make decisions about whether to admit or >>>>> >>>block a >>> >>>>> new flow request, and (in abnormal circumstances) whether to >>>>> terminate some of the existing flows, thereby protecting the = QoS >>>>> >>>of >>> >>>>> previously admitted flows. This document specifies how such >>>>> >>>marks >>> >>>>> are encoded into the IP header by re-using the Explicit >>>>> >>>Congestion >>> >>>>> Notification (ECN) codepoints within this controlled domain. = The >>>>> baseline encoding described here provides for only two PCN >>>>> >>>encoding >>> >>>>> states, Not-marked and PCN-marked. >>>>> >>>>>Toby >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>>>> >>>Of >>> >>>>>>Lars Eggert >>>>>>Sent: 25 August 2009 15:12 >>>>>>To: pcn@ietf.org >>>>>>Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>>>>> >>>>>> >>>>>ofdraft-ietf-pcn-baseline- >>>>> >>>>> >>>>>>encoding-05 >>>>>> >>>>>> >>>>>> >>>>>>Begin forwarded message: >>>>>> >>>>>> >>>>>> >>>>>>>From: Spencer Dawkins >>>>>>>Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>>>To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>>> >>>>>>> >>>>>>>>> >>>>> >>>>>>pcn-baseline-encoding@tools.ietf.org >>>>>> >>>>>> >>>>>>>Cc: General Area Review Team , >>>>>>> >>>>>>> >>>>>>"ietf@ietf.org >>>>>> >>>>>> >>>>>>>" >>>>>>>Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>>>>>encoding-05 >>>>>>> >>>>>>>I have been selected as the General Area Review Team (Gen-ART) >>>>>>>reviewer for this draft (for background on Gen-ART, please see >>>>>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>>> >>>>>>>Please wait for direction from your document shepherd or AD = before >>>>>>>posting a new version of the draft. >>>>>>> >>>>>>>Document: draft-ietf-pcn-baseline-encoding-05 >>>>>>>Reviewer: Spencer Dawkins >>>>>>>IETF LC End Date: 2009-09-03 >>>>>>>Review Date: 2009-08-21 >>>>>>>IESG Telechat date: (not known) >>>>>>> >>>>>>>Summary: this specification is almost ready for publication as a >>>>>>>Proposed Standard. I have one minor question below (flagged as >>>>>>>"Spencer (minor)"), along with some editorial suggestions to be >>>>>>>considered when this document is edited (either in the working >>>>>>> >>>group >>> >>>>>>>or by the RFC Editor). >>>>>>> >>>>>>>Abstract >>>>>>> >>>>>>> The objective of Pre-Congestion Notification (PCN) is to = protect >>>>>>> >>>>>>> >>>>>>the >>>>>> >>>>>> >>>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>>>domain. >>>>>>> >>>>>>>Spencer (clarity): I'm not sure what the relationship between a >>>>>>>Diffserv domain and a PCN-domain is - this couuld be clearer, >>>>>>>especially in an Abstract. I note that RFC 5559 doesn't use the >>>>>>> >>>term >>> >>>>>>>PCN-domain in its Abstract ... I can guess, but I'm just = guessing. >>>>>>> >>>>>>> The overall rate of the PCN-traffic is metered on every link = in >>>>>>> >>>>>>> >>>>>the >>>>> >>>>> >>>>>>> PCN-domain, and PCN-packets are appropriately marked when >>>>>>> >>>certain >>> >>>>>>> configured rates are exceeded. The level of marking allows = the >>>>>>> boundary nodes to make decisions about whether to admit or = block >>>>>>> >>>a >>> >>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>> terminate some of the existing flows, thereby protecting the = QoS >>>>>>> >>>>>>> >>>>>of >>>>> >>>>> >>>>>>> previously admitted flows. This document specifies how such >>>>>>> >>>marks >>> >>>>>>> are to be encoded into the IP header by re-using the Explicit >>>>>>> Congestion Notification (ECN) codepoints within this = controlled >>>>>>> domain. The baseline encoding described here provides for = only >>>>>>> >>>>>>> >>>>>two >>>>> >>>>> >>>>>>> PCN encoding states, Not-marked and PCN-marked. >>>>>>> >>>>>>>4. Encoding two PCN States in IP >>>>>>> >>>>>>> The following rules apply to all PCN traffic: >>>>>>> >>>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD = be >>>>>>> chosen that are already defined for use with admission >>>>>>> >>>>>>> >>>>>>controlled >>>>>> >>>>>> >>>>>>> traffic. Appendix A.1 gives guidance to implementiors on >>>>>>>suitable >>>>>>> >>>>>>>Spencer (clarity): s/implementiors/implementers/? >>>>>>> >>>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- >>>>>>> >>>domain >>> >>>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>>>>> >>>>>>> o Any packet that is not-PCN but which shares the same = Diffserv >>>>>>> codepoint as PCN-enabled traffic MUST have the ECN field of >>>>>>> >>>its >>> >>>>>>> outermost IP header equal to 00. >>>>>>> >>>>>>>Spencer (minor): this is the only point in the specification = (that >>>>>>> >>>I >>> >>>>>>>can >>>>>>>find) that makes reference to the "outermost IP header". I'm not >>>>>>> >>>>>>> >>>>>sure >>>>> >>>>> >>>>>>>whether to suggest s/outermost// here or to ask that a statement >>>>>>> >>>be >>> >>>>>>>added earlier in the document to clearly state that PCN encoding >>>>>>> >>>>>>> >>>>>only >>>>> >>>>> >>>>>>>protects inelastic traffic when it's used for the outermost IP >>>>>>> >>>>>>> >>>>>>header, >>>>>> >>>>>> >>>>>>>but the current text seems to call attention to this in a way = that >>>>>>>makes the reader wonder what is special about THIS requirement >>>>>>> >>>that >>> >>>>>>>isn't true of the other requirements listed. >>>>>>> >>>>>>>4.3. PCN-Compatible Diffserv Codepoints >>>>>>> >>>>>>> Enabling PCN marking behaviour for a specific DSCP disables = any >>>>>>>other >>>>>>> marking behaviour (e.g. enabling PCN disables the default ECN >>>>>>>marking >>>>>>> behaviour introduced in [RFC3168]). All traffic metering and >>>>>>>marking >>>>>>> >>>>>>>Spencer (clarity): here, and in Section 6, the text uses >>>>>>> >>>"disables" >>> >>>>>>to >>>>>> >>>>>> >>>>>>>describe the relationship between PCN and ECN. If I understand = the >>>>>>>point, the domain is substituting one behavior for another. I >>>>>>> >>>might >>> >>>>>>>suggest "replaces" to describe the relationship in both = locations. >>>>>>> >>>>>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >>>>>>> >>>>>>> >>>>>This >>>>> >>>>> >>>>>>> ensures compliance with the BCP guidance set out in [RFC4774]. >>>>>>> >>>>>>>4.3.1. Co-existence of PCN and not-PCN traffic >>>>>>> >>>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >>>>>>> envisaged as a marking behaviour that could be applied to a >>>>>>> >>>number >>> >>>>>>>of >>>>>>> different DSCPs makes it essential that we provide a not-PCN >>>>>>> >>>>>>> >>>>>state. >>>>> >>>>> >>>>>>> As stated above (and expanded in Appendix A.1) the aim is for >>>>>>> >>>PCN >>> >>>>>>to >>>>>> >>>>>> >>>>>>> re-use existing DSCPs. Because PCN re-defines the meaning of >>>>>>> >>>the >>> >>>>>>>ECN >>>>>>> >>>>>>>Spencer (clarity): here, the text uses "re-defines", which I like >>>>>>>better than "disables", but if you go for "replaces" previously >>>>>>> >>>and >>> >>>>>>in >>>>>> >>>>>> >>>>>>>section 6, you might want to use the same wording here. >>>>>>> >>>>>>> field for such DSCPs it is important to allow an operator to >>>>>>> >>>still >>> >>>>>>> use the DSCP for traffic that isn't PCN-enabled. This is >>>>>>> >>>achieved >>> >>>>>>>by >>>>>>> providing a not-PCN state within the encoding scheme. >>>>>>> >>>>>>>A.1. Choice of Suitable DSCPs >>>>>>> >>>>>>> The PCN Working Group chose not to define a single DSCP for = use >>>>>>> >>>>>>> >>>>>>with >>>>>> >>>>>> >>>>>>> PCN for several reasons. Firstly the PCN mechanism is >>>>>>> >>>applicable >>> >>>>>>to >>>>>> >>>>>> >>>>>>> a variety of different traffic classes. Secondly standards >>>>>>> >>>track >>> >>>>>>> DSCPs are in increasingly short supply. Thirdly PCN should be >>>>>>> >>>>>>> >>>>>seen >>>>> >>>>> >>>>>>> as being essentially a marking behaviour similar to ECN but >>>>>>> >>>>>>> >>>>>>intended >>>>>> >>>>>> >>>>>>> for inelastic traffic. The choice of which DSCP is most >>>>>>> >>>suitable >>> >>>>>>>for >>>>>>> a given PCN-domain is dependent on the nature of the traffic >>>>>>>entering >>>>>>> that domain and the link rates of all the links making up that >>>>>>> domain. In PCN-domains with uniformly high link rates, the >>>>>>> appropriate DSCPs would currently be those for the Real Time >>>>>>> >>>>>>> >>>>>>Traffic >>>>>> >>>>>> >>>>>>> Class [RFC5127]. To be clear the PCN Working Group recommends >>>>>>> >>>>>>> >>>>>>using >>>>>> >>>>>> >>>>>>>Spencer (clarity): is this 2119 language (apparently not, since >>>>>>> >>>this >>> >>>>>>>section is not normative), or are you saying "suggests"? My >>>>>>> >>>>>>> >>>>>>suggestion >>>>>> >>>>>> >>>>>>>is that we not use 2119 language, even lowercased, except for >>>>>>>normative text - this seems to cause confusion from time to time. >>>>>>> >>>>>>> >>>>>But >>>>> >>>>> >>>>>>>please check with your shepherding AD to see if he agrees. >>>>>>> >>>>>>> admission control for the following service classes: >>>>>>> >>>>>>> o Telephony (EF) >>>>>>> >>>>>>> o Real-time interactive (CS4) >>>>>>> >>>>>>> o Broadcast Video (CS3) >>>>>>> >>>>>>> o Multimedia Conferencing (AF4) >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Gen-art mailing list >>>>>>>Gen-art@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/gen-art >>>>>>> >>>>>>> >>>>>_______________________________________________ >>>>>PCN mailing list >>>>>PCN@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/pcn >>>>> >>>>> >>>>_______________________________________________ >>>>PCN mailing list >>>>PCN@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pcn >>>>_______________________________________________ >>>>PCN mailing list >>>>PCN@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pcn >>>> >>>> >>>-- >>>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 >>> > >-- >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 menth@informatik.uni-wuerzburg.de Thu Aug 27 00:41: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 2C71B3A6F55 for ; Thu, 27 Aug 2009 00:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, SARE_OBFU_COULD=0.917] 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 oe4b7mAkC+C0 for ; Thu, 27 Aug 2009 00:41:33 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 251AE3A6B1C for ; Thu, 27 Aug 2009 00:41:33 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A922EA0CC6; Thu, 27 Aug 2009 09:41:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9B8D9A0D4B; Thu, 27 Aug 2009 09:41:35 +0200 (CEST) Received: from [192.168.1.2] (f051069091.adsl.alicedsl.de [78.51.69.91]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 05B49199608; Thu, 27 Aug 2009 09:41:34 +0200 (CEST) Message-ID: <4A96389D.7000004@informatik.uni-wuerzburg.de> Date: Thu, 27 Aug 2009 09:41:17 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <20090825184229.CDB2EBEF4@mwinf5909> <151C164FE2E066418D8D44D0801543A501F2F558@S4DE8PSAAQA.mitte.t-com.de> <4A94E830.906@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A501F2FA0B@S4DE8PSAAQA.mitte.t-com.de> <4A9550E1.10801@informatik.uni-wuerzburg.de> <20090826155026.B5D791C000D0@mwinf5908> <151C164FE2E066418D8D44D0801543A501F68BDF@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A501F68BDF@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 27 Aug 2009 07:41:38 -0000 Hi Ruediger, taking Bob's proposal, I am almost happy. I have a slight improvement based on Bob's proposal. Pre-congestion notification (PCN) is a scheme for metering and marking packets within a DiffServ domain and for transporting packet markings to egress nodes. This PCN information can be used by feedback-based admission control and flow termination to protect the qualtiy of service of prioritized, inelastic, realtime flows. Regards, Michael Ruediger.Geib@telekom.de schrieb: > Bob, Toby, Michael > > Bob's proposal below is allright to me. My only intention is, to explain PCN to the > casual reader in the first sentence. That also works well the way Bob phrased. > > Michael, does Bobs suggestion address your concerns? > > Toby, would decomposing the unwieldy long second sentence be an option? > An example: > > It does so by measuring pre-congestion information at the boundaries > of the domain. This information is used to determine whether to admit > new flows or (in abnormal circumstances) terminate some existing flows. > Thereby the QoS of previously admitted flows is protected. > > I think, at least ending the first statement after "the boundaries of > the domain" is acceptable. But I'm not a native speaker, of course. > > Regards, > > Ruediger > > > -----Original Message----- > From: Bob Briscoe [mailto:bob@homefarmparham.co.uk] > Sent: Wednesday, August 26, 2009 5:50 PM > To: menth@informatik.uni-wuerzburg.de; Geib, Rüdiger > Cc: toby.moncaster@bt.com; pcn@ietf.org > Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 > > Michael, > > I agree that we should use the term PCN to mean > the notification part, not the whole traffic > control system built around it. We had this > discussion when publishing the architecture. > > * CORRECT: what Phil did in the Intro to the architecture. > "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. > " > (paraphrasing: the *objective* of notification is to protect QoS) > > * INCORRECT: The first sentence of Toby's abstract says: > "Pre-Congestion Notification (PCN) is a metering and marking scheme that > protects the quality of service (QoS) of > inelastic flows within a Diffserv > domain." > (paraphrasing: notification *is* a scheme that protects QoS) > > Suggestion to fix the first > sentence:"Pre-Congestion Notification (PCN) is a > scheme for metering and marking packets that > can be used to protect the quality of service > (QoS) of inelastic flows within a Diffserv domain." > > > > Bob > > At 16:12 26/08/2009, Michael Menth wrote: > >> Hi Ruediger, Toby, >> >> Ruediger.Geib@telekom.de schrieb: >> >>> Toby, >>> >>> you simply ommited some "PCN" in your new >>> version. I think the problem addressed by >>> Spencer may be that you try to sum up RFC5559 rather then refer to it. >>> Below there's an abstract proposal, structured top-down: >>> - What's PCN: a copy of the abstract of RFC5559. >>> - What's the functionality relevant for this document: marking >>> - What's specified by this document: baseline encoding >>> My try: >>> >>> PCN specifies 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. >>> >> What is PCN? Or is admission control and flow >> termination also part of PCN? My take on this is >> that PCN is only the marking scheme and the way >> the information is carried to egress nodes. AC >> and FT is just built on top of PCN. And to >> support QoS is the objective of AC and FT, not >> primarily or only indirectly the objective of the marking scheme. >> >> Regards, >> >> Michael >> >> >>> As a part of this specification, the overall >>> rate of the PCN coloured traffic is metered on >>> every link in the domain, and these packets are >>> appropriately marked when certain configured rates are exceeded. >>> This document specifies how such marks are >>> encoded into the IP header by re-using the >>> Explicit Congestion Notification (ECN) >>> codepoints within this controlled domain. The >>> baseline encoding described here provides for >>> only two PCN encoding states, Not-marked and PCN-marked. >>> >>> >>> >>> Please maintain the notion of "overall rate of >>> PCN traffic" or "PCN coloured traffic" which is >>> being metered in the version of abstract you go on with. >>> >>> Regards, >>> >>> Ruediger >>> >>> >>> >>> -----Original Message----- >>> From: toby.moncaster@bt.com >>> [mailto:toby.moncaster@bt.com] Sent: Wednesday, August 26, 2009 1:13 PM >>> To: menth@informatik.uni-wuerzburg.de; Geib, Rüdiger >>> Cc: bob@homefarmparham.co.uk; pcn@ietf.org >>> Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART >>> Review ofdraft-ietf-pcn-baseline-encoding-05 >>> >>> So would the following sound better? : >>> >>> Pre-Congestion Notification (PCN) is a >>> metering and marking scheme that protects >>> the quality of service (QoS) of inelastic >>> flows within a Diffserv domain. The overall >>> rate of the traffic is metered on >>> every link in the domain, and packets are appropriately marked when certain >>> configured rates are exceeded. Boundary nodes can measure the level >>> of marking and thus make decisions about whether to admit or block a >>> new flow request, and (in abnormal circumstances) whether to >>> terminate some of the existing flows, thereby protecting the QoS of >>> previously admitted flows. This document specifies how such marks >>> are encoded into the IP header by re-using the Explicit Congestion >>> Notification (ECN) codepoints within this controlled domain. The >>> baseline encoding described here provides for only two PCN encoding >>> states, Not-marked and PCN-marked. >>> >>> Just for clarity here was the earlier version I proposed: >>> >>> The objective of Pre-Congestion Notification (PCN) is to protect the >>> quality of service (QoS) of inelastic flows within a Diffserv domain. >>> The overall rate of the traffic is metered on every link in the >>> domain, and packets are appropriately marked when certain >>> configured rates are exceeded. Boundary nodes can measure the level >>> of marking and thus make decisions about whether to admit or block a >>> new flow request, and (in abnormal circumstances) whether to >>> terminate some of the existing flows, thereby protecting the QoS of >>> previously admitted flows. This document specifies how such marks >>> are encoded into the IP header by re-using the Explicit Congestion >>> Notification (ECN) codepoints within this controlled domain. The >>> baseline encoding described here provides for only two PCN encoding >>> states, Not-marked and PCN-marked. >>> >>> I personally disagree with Tom's suggestion to >>> add PCN to all the defined terms (e.g. PCN >>> flow, PCN traffic) - that is fine within the >>> body of the document but in this abstract we >>> should avoid using any terms that readers >>> won't be already familiar with. >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>> Sent: 26 August 2009 08:46 >>>> To: Ruediger.Geib@telekom.de >>>> Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>> baseline-encoding-05 >>>> >>>> Hi all, >>>> >>>> Rüdiger touches an issue that I also feel is not optimally solved in >>>> the >>>> current abstract. The objective of PCN is provide marking information >>>> to >>>> egress node and the objective of admission control and flow termination >>>> is to protect QoS. I use the following short explanation for PCN. Maybe >>>> this idea could be added to the current abstract. >>>> >>>> Pre-congestion notification (PCN) is a metering and marking scheme for >>>> Differentiated Services (DiffServ) IP networks which provides egress >>>> nodes with information about load conditions inside the network >>>> \cite{RFC5559}. This information is used for admission control and flow >>>> termination to support quality of service (QoS) for admitted inelastic >>>> realtime flows that are carried with prioritization within the DiffServ >>>> domain. >>>> This document specifies how nodes encode the marking information in the >>>> IP header by re-using the Explicit Congestion Notification (ECN) >>>> codepoints within a controlled DiffServ domain. The baseline encoding >>>> described here provides for only two PCN encoding states which are >>>> not-marked and PCN-marked. >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>> Ruediger.Geib@telekom.de schrieb: >>>> >>>> >>>>> Toby, Bob >>>>> >>>>> if the abstract is to mention PCN functionalities not defined within >>>>> this document in a rather simplified way, would the purpose of PCN >>>>> be to enable a Diffserv domain to support measurement based >>>>> admission control as defined by PCN architecture? >>>>> >>>>> Regards, >>>>> >>>>> Ruediger >>>>> >>>>> -----Original Message----- >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>>>> >>>>> >>>> Bob Briscoe >>>> >>>> >>>>> Sent: Tuesday, August 25, 2009 8:42 PM >>>>> To: toby.moncaster@bt.com; pcn@ietf.org >>>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>>> >>>>> >>>> baseline-encoding-05 >>>> >>>> >>>>> Toby, >>>>> >>>>> I think this isn't just good for a casual reader, but it is actually >>>>> still correct and doesn't require defining PC-domain (which is just >>>>> the Diffserv domain once the described measures - the PDB - have been >>>>> put in place). >>>>> >>>>> >>>>> Bob >>>>> >>>>> At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>>>> >>>>> >>>>> >>>>>> This potentially raises an issue for all future PCN documents since >>>>>> >>>>>> >>>> the >>>> >>>> >>>>>> abstract was based on our agreed standard elevator-pitch >>>>>> >>>>>> >>>> introduction to >>>> >>>> >>>>>> PCN... Specifically Spencer raises the question of using the defined >>>>>> term PCN-domain in the abstract. Any thoughts from anyone as to >>>>>> >>>>>> >>>> whether >>>> >>>> >>>>>> this is confusing? Would it be clearer to just use "domain" (e.g. >>>>>> >>>>>> >>>> drop >>>> >>>> >>>>>> the "PCN-"). In which case should I alter the whole abstract as >>>>>> >>>>>> >>>> follows >>>> >>>> >>>>>> (note: I realise this is strictly incorrect as it now doesn't seek >>>>>> >>>>>> >>>> to >>>> >>>> >>>>>> distinguish the non-PCN and PCN traffic from each other but is this >>>>>> clearer for a casual reader?): >>>>>> >>>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>>> >>>>>> >>>> the >>>> >>>> >>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>> >>>>>> >>>> domain. >>>> >>>> >>>>>> The overall rate of the traffic is metered on every link in the >>>>>> domain, and packets are appropriately marked when certain >>>>>> configured rates are exceeded. Boundary nodes can measure the >>>>>> >>>>>> >>>> level >>>> >>>> >>>>>> of marking and thus make decisions about whether to admit or >>>>>> >>>>>> >>>> block a >>>> >>>> >>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>> terminate some of the existing flows, thereby protecting the QoS >>>>>> >>>>>> >>>> of >>>> >>>> >>>>>> previously admitted flows. This document specifies how such >>>>>> >>>>>> >>>> marks >>>> >>>> >>>>>> are encoded into the IP header by re-using the Explicit >>>>>> >>>>>> >>>> Congestion >>>> >>>> >>>>>> Notification (ECN) codepoints within this controlled domain. The >>>>>> baseline encoding described here provides for only two PCN >>>>>> >>>>>> >>>> encoding >>>> >>>> >>>>>> states, Not-marked and PCN-marked. >>>>>> >>>>>> Toby >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>>>>> >>>>>>> >>>> Of >>>> >>>> >>>>>>> Lars Eggert >>>>>>> Sent: 25 August 2009 15:12 >>>>>>> To: pcn@ietf.org >>>>>>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>>>>>> >>>>>>> >>>>>>> >>>>>> ofdraft-ietf-pcn-baseline- >>>>>> >>>>>> >>>>>> >>>>>>> encoding-05 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> From: Spencer Dawkins >>>>>>>> Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>>> pcn-baseline-encoding@tools.ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Cc: General Area Review Team , >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> "ietf@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>>> " >>>>>>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>>>>>> encoding-05 >>>>>>>> >>>>>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>>>>> reviewer for this draft (for background on Gen-ART, please see >>>>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>>>> >>>>>>>> Please wait for direction from your document shepherd or AD before >>>>>>>> posting a new version of the draft. >>>>>>>> >>>>>>>> Document: draft-ietf-pcn-baseline-encoding-05 >>>>>>>> Reviewer: Spencer Dawkins >>>>>>>> IETF LC End Date: 2009-09-03 >>>>>>>> Review Date: 2009-08-21 >>>>>>>> IESG Telechat date: (not known) >>>>>>>> >>>>>>>> Summary: this specification is almost ready for publication as a >>>>>>>> Proposed Standard. I have one minor question below (flagged as >>>>>>>> "Spencer (minor)"), along with some editorial suggestions to be >>>>>>>> considered when this document is edited (either in the working >>>>>>>> >>>>>>>> >>>> group >>>> >>>> >>>>>>>> or by the RFC Editor). >>>>>>>> >>>>>>>> Abstract >>>>>>>> >>>>>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>> >>>>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>>>> domain. >>>>>>>> >>>>>>>> Spencer (clarity): I'm not sure what the relationship between a >>>>>>>> Diffserv domain and a PCN-domain is - this couuld be clearer, >>>>>>>> especially in an Abstract. I note that RFC 5559 doesn't use the >>>>>>>> >>>>>>>> >>>> term >>>> >>>> >>>>>>>> PCN-domain in its Abstract ... I can guess, but I'm just guessing. >>>>>>>> >>>>>>>> The overall rate of the PCN-traffic is metered on every link in >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>>>> PCN-domain, and PCN-packets are appropriately marked when >>>>>>>> >>>>>>>> >>>> certain >>>> >>>> >>>>>>>> configured rates are exceeded. The level of marking allows the >>>>>>>> boundary nodes to make decisions about whether to admit or block >>>>>>>> >>>>>>>> >>>> a >>>> >>>> >>>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>>> terminate some of the existing flows, thereby protecting the QoS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> of >>>>>> >>>>>> >>>>>> >>>>>>>> previously admitted flows. This document specifies how such >>>>>>>> >>>>>>>> >>>> marks >>>> >>>> >>>>>>>> are to be encoded into the IP header by re-using the Explicit >>>>>>>> Congestion Notification (ECN) codepoints within this controlled >>>>>>>> domain. The baseline encoding described here provides for only >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> two >>>>>> >>>>>> >>>>>> >>>>>>>> PCN encoding states, Not-marked and PCN-marked. >>>>>>>> >>>>>>>> 4. Encoding two PCN States in IP >>>>>>>> >>>>>>>> The following rules apply to all PCN traffic: >>>>>>>> >>>>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be >>>>>>>> chosen that are already defined for use with admission >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> controlled >>>>>>> >>>>>>> >>>>>>> >>>>>>>> traffic. Appendix A.1 gives guidance to implementiors on >>>>>>>> suitable >>>>>>>> >>>>>>>> Spencer (clarity): s/implementiors/implementers/? >>>>>>>> >>>>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- >>>>>>>> >>>>>>>> >>>> domain >>>> >>>> >>>>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>>>>>> >>>>>>>> o Any packet that is not-PCN but which shares the same Diffserv >>>>>>>> codepoint as PCN-enabled traffic MUST have the ECN field of >>>>>>>> >>>>>>>> >>>> its >>>> >>>> >>>>>>>> outermost IP header equal to 00. >>>>>>>> >>>>>>>> Spencer (minor): this is the only point in the specification (that >>>>>>>> >>>>>>>> >>>> I >>>> >>>> >>>>>>>> can >>>>>>>> find) that makes reference to the "outermost IP header". I'm not >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> sure >>>>>> >>>>>> >>>>>> >>>>>>>> whether to suggest s/outermost// here or to ask that a statement >>>>>>>> >>>>>>>> >>>> be >>>> >>>> >>>>>>>> added earlier in the document to clearly state that PCN encoding >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> only >>>>>> >>>>>> >>>>>> >>>>>>>> protects inelastic traffic when it's used for the outermost IP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> header, >>>>>>> >>>>>>> >>>>>>> >>>>>>>> but the current text seems to call attention to this in a way that >>>>>>>> makes the reader wonder what is special about THIS requirement >>>>>>>> >>>>>>>> >>>> that >>>> >>>> >>>>>>>> isn't true of the other requirements listed. >>>>>>>> >>>>>>>> 4.3. PCN-Compatible Diffserv Codepoints >>>>>>>> >>>>>>>> Enabling PCN marking behaviour for a specific DSCP disables any >>>>>>>> other >>>>>>>> marking behaviour (e.g. enabling PCN disables the default ECN >>>>>>>> marking >>>>>>>> behaviour introduced in [RFC3168]). All traffic metering and >>>>>>>> marking >>>>>>>> >>>>>>>> Spencer (clarity): here, and in Section 6, the text uses >>>>>>>> >>>>>>>> >>>> "disables" >>>> >>>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>> >>>>>>>> describe the relationship between PCN and ECN. If I understand the >>>>>>>> point, the domain is substituting one behavior for another. I >>>>>>>> >>>>>>>> >>>> might >>>> >>>> >>>>>>>> suggest "replaces" to describe the relationship in both locations. >>>>>>>> >>>>>>>> behaviours are discussed in [I-D.ietf-pcn-marking-behaviour]. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> This >>>>>> >>>>>> >>>>>> >>>>>>>> ensures compliance with the BCP guidance set out in [RFC4774]. >>>>>>>> >>>>>>>> 4.3.1. Co-existence of PCN and not-PCN traffic >>>>>>>> >>>>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN is >>>>>>>> envisaged as a marking behaviour that could be applied to a >>>>>>>> >>>>>>>> >>>> number >>>> >>>> >>>>>>>> of >>>>>>>> different DSCPs makes it essential that we provide a not-PCN >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> state. >>>>>> >>>>>> >>>>>> >>>>>>>> As stated above (and expanded in Appendix A.1) the aim is for >>>>>>>> >>>>>>>> >>>> PCN >>>> >>>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>> >>>>>>>> re-use existing DSCPs. Because PCN re-defines the meaning of >>>>>>>> >>>>>>>> >>>> the >>>> >>>> >>>>>>>> ECN >>>>>>>> >>>>>>>> Spencer (clarity): here, the text uses "re-defines", which I like >>>>>>>> better than "disables", but if you go for "replaces" previously >>>>>>>> >>>>>>>> >>>> and >>>> >>>> >>>>>>> in >>>>>>> >>>>>>> >>>>>>> >>>>>>>> section 6, you might want to use the same wording here. >>>>>>>> >>>>>>>> field for such DSCPs it is important to allow an operator to >>>>>>>> >>>>>>>> >>>> still >>>> >>>> >>>>>>>> use the DSCP for traffic that isn't PCN-enabled. This is >>>>>>>> >>>>>>>> >>>> achieved >>>> >>>> >>>>>>>> by >>>>>>>> providing a not-PCN state within the encoding scheme. >>>>>>>> >>>>>>>> A.1. Choice of Suitable DSCPs >>>>>>>> >>>>>>>> The PCN Working Group chose not to define a single DSCP for use >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> with >>>>>>> >>>>>>> >>>>>>> >>>>>>>> PCN for several reasons. Firstly the PCN mechanism is >>>>>>>> >>>>>>>> >>>> applicable >>>> >>>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>> >>>>>>>> a variety of different traffic classes. Secondly standards >>>>>>>> >>>>>>>> >>>> track >>>> >>>> >>>>>>>> DSCPs are in increasingly short supply. Thirdly PCN should be >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> seen >>>>>> >>>>>> >>>>>> >>>>>>>> as being essentially a marking behaviour similar to ECN but >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> intended >>>>>>> >>>>>>> >>>>>>> >>>>>>>> for inelastic traffic. The choice of which DSCP is most >>>>>>>> >>>>>>>> >>>> suitable >>>> >>>> >>>>>>>> for >>>>>>>> a given PCN-domain is dependent on the nature of the traffic >>>>>>>> entering >>>>>>>> that domain and the link rates of all the links making up that >>>>>>>> domain. In PCN-domains with uniformly high link rates, the >>>>>>>> appropriate DSCPs would currently be those for the Real Time >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Traffic >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Class [RFC5127]. To be clear the PCN Working Group recommends >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> using >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Spencer (clarity): is this 2119 language (apparently not, since >>>>>>>> >>>>>>>> >>>> this >>>> >>>> >>>>>>>> section is not normative), or are you saying "suggests"? My >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> suggestion >>>>>>> >>>>>>> >>>>>>> >>>>>>>> is that we not use 2119 language, even lowercased, except for >>>>>>>> normative text - this seems to cause confusion from time to time. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> But >>>>>> >>>>>> >>>>>> >>>>>>>> please check with your shepherding AD to see if he agrees. >>>>>>>> >>>>>>>> admission control for the following service classes: >>>>>>>> >>>>>>>> o Telephony (EF) >>>>>>>> >>>>>>>> o Real-time interactive (CS4) >>>>>>>> >>>>>>>> o Broadcast Video (CS3) >>>>>>>> >>>>>>>> o Multimedia Conferencing (AF4) >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Gen-art mailing list >>>>>>>> Gen-art@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> PCN mailing list >>>>>> PCN@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> PCN mailing list >>>>> PCN@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>> _______________________________________________ >>>>> PCN mailing list >>>>> PCN@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>> >>>>> >>>>> >>>> -- >>>> 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 >>>> >>>> >> -- >> 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 >> -- 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 Thu Aug 27 03:06: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 1B04B3A68EB for ; Thu, 27 Aug 2009 03:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 V-vcM3ZryFWv for ; Thu, 27 Aug 2009 03:06:38 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 389DD3A6DEB for ; Thu, 27 Aug 2009 03:06:37 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 11:06:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Aug 2009 11:05:51 +0100 Message-ID: In-Reply-To: <20090826161528.6CDD41C000A8@mwinf5908> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 Thread-Index: AcomaG9wICdK8CAuSvKv3VoO2yDiYgAkn1vg References: <20090826161528.6CDD41C000A8@mwinf5908> From: To: , , X-OriginalArrivalTime: 27 Aug 2009 10:06:39.0076 (UTC) FILETIME=[1181FA40:01CA26FE] Cc: pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 27 Aug 2009 10:06:41 -0000 OK, my last 2 suggested versions. PLEASE can we just make a decision = now! Version 1 (13 lines): Pre-Congestion Notification (PCN) is a scheme for packet metering and marking that can be used within a Diffserv domain to protect the quality of service (QoS) of inelastic flows. It does this by=20 measuring pre-congestion information at the boundaries of the=20 domain. This information is used to determine whether to admit=20 new flows or (in abnormal circumstances) terminate some existing=20 flows, thereby protecting the QoS of previously admitted flows.=20 The pre-congestion information is provided by marking packets=20 when the overall rate of PCN traffic on a link exceeds certain=20 configured rates. This document specifies how such marks are=20 encoded into the IP header by re-using the Explicit Congestion=20 Notification (ECN) codepoints within this controlled domain. =20 The baseline encoding described here provides for only two PCN=20 encoding states, Not-marked and PCN-marked. Version 2 (11 lines): Pre-Congestion Notification (PCN) is a scheme for packet metering and=20 marking that can help protect the quality of service (QoS) of=20 inelastic flows within a Diffserv domain. Within the domain nodes=20 measure the rate of PCN traffic on each link and mark packets if that=20 rate exceeds a configured threshold. This pre-congestion information=20 is measured at the boundaries of the domain and is then used to=20 determine whether to admit new flows or (in extremis) terminate some=20 existing flows. This protects the QoS of previously admitted flows.=20 This document specifies how such marks are encoded into the IP header=20 by re-using the Explicit Congestion Notification (ECN) codepoints=20 within this controlled domain. The baseline encoding described here=20 provides for only two PCN encoding states, Not-marked and PCN-marked. Toby > -----Original Message----- > From: Bob Briscoe [mailto:bob@homefarmparham.co.uk] > Sent: 26 August 2009 17:15 > To: Moncaster,T,Toby,DER3 R > Subject: Fwd: Re: [PCN] Fwd: [Gen-art] Gen-ART Review = ofdraft-ietf-pcn- > baseline-encoding-05 >=20 > Toby, >=20 > inline, following up my own post... >=20 > >Date: Wed, 26 Aug 2009 16:50:15 +0100 > >To: menth@informatik.uni-wuerzburg.de, Ruediger.Geib@telekom.de > >From: Bob Briscoe > >Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART > >Review ofdraft-ietf-pcn-baseline-encoding-05 > >Cc: toby.moncaster@bt.com, pcn@ietf.org > > > >Michael, > > > >I agree that we should use the term PCN to mean > >the notification part, not the whole traffic > >control system built around it. We had this > >discussion when publishing the architecture. > > > >* CORRECT: what Phil did in the Intro to the architecture. > >" > >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. > > > >" > >(paraphrasing: the *objective* of notification is to protect QoS) > > > >* INCORRECT: The first sentence of Toby's abstract says: > >"Pre-Congestion Notification (PCN) is a metering and marking scheme > that > > protects the quality of service (QoS) of > > inelastic flows within a Diffserv > > domain." > >(paraphrasing: notification *is* a scheme that protects QoS) > > > >Suggestion to fix the first > >sentence:"Pre-Congestion Notification (PCN) is a > >scheme for metering and marking packets that > >can be used to protect the quality of service > >(QoS) of inelastic flows within a Diffserv domain." >=20 > Just realised that's ambiguous: "scheme that can > be used" or "packets that can be used"? >=20 > 2nd attempt: > "Pre-Congestion Notification (PCN) is a scheme > for packet metering and marking that can be used > to protect the quality of service (QoS) of > inelastic flows within a Diffserv domain." >=20 >=20 >=20 >=20 > >Bob > > > >At 16:12 26/08/2009, Michael Menth wrote: > >>Hi Ruediger, Toby, > >> > >>Ruediger.Geib@telekom.de schrieb: > >>>Toby, > >>> > >>>you simply ommited some "PCN" in your new > >>>version. I think the problem addressed by > >>>Spencer may be that you try to sum up RFC5559 rather then refer to > it. > >>>Below there's an abstract proposal, structured top-down: > >>>- What's PCN: a copy of the abstract of RFC5559. > >>>- What's the functionality relevant for this document: marking > >>>- What's specified by this document: baseline encoding > >>>My try: > >>> > >>>PCN specifies 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. > >>What is PCN? Or is admission control and flow > >>termination also part of PCN? My take on this > >>is that PCN is only the marking scheme and the > >>way the information is carried to egress nodes. > >>AC and FT is just built on top of PCN. And to > >>support QoS is the objective of AC and FT, not > >>primarily or only indirectly the objective of the marking scheme. > >> > >>Regards, > >> > >> Michael > >> > >>>As a part of this specification, the overall > >>>rate of the PCN coloured traffic is metered on > >>>every link in the domain, and these packets > >>>are appropriately marked when certain configured rates are = exceeded. > >>>This document specifies how such marks are > >>>encoded into the IP header by re-using the > >>>Explicit Congestion Notification (ECN) > >>>codepoints within this controlled domain. The > >>>baseline encoding described here provides for > >>>only two PCN encoding states, Not-marked and PCN-marked. > >>> > >>> > >>> > >>>Please maintain the notion of "overall rate of > >>>PCN traffic" or "PCN coloured traffic" which > >>>is being metered in the version of abstract you go on with. > >>> > >>>Regards, > >>> > >>>Ruediger > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: toby.moncaster@bt.com > >>>[mailto:toby.moncaster@bt.com] Sent: Wednesday, August 26, 2009 = 1:13 > PM > >>>To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger > >>>Cc: bob@homefarmparham.co.uk; pcn@ietf.org > >>>Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART > >>>Review ofdraft-ietf-pcn-baseline-encoding-05 > >>> > >>>So would the following sound better? : > >>> > >>> Pre-Congestion Notification (PCN) is a > >>> metering and marking scheme that protects > >>> the quality of service (QoS) of inelastic > >>> flows within a Diffserv domain. The > >>> overall rate of the traffic is metered on > >>> every link in the domain, and packets are appropriately marked > when certain > >>> configured rates are exceeded. Boundary nodes can measure the > level > >>> of marking and thus make decisions about whether to admit or > block a > >>> new flow request, and (in abnormal circumstances) whether to > >>> terminate some of the existing flows, thereby protecting the = QoS > of > >>> previously admitted flows. This document specifies how such > marks > >>> are encoded into the IP header by re-using the Explicit > Congestion > >>> Notification (ECN) codepoints within this controlled domain. > The > >>> baseline encoding described here provides for only two PCN > encoding > >>> states, Not-marked and PCN-marked. > >>> > >>>Just for clarity here was the earlier version I proposed: > >>> > >>> The objective of Pre-Congestion Notification (PCN) is to = protect > the > >>> quality of service (QoS) of inelastic flows within a Diffserv > domain. > >>> The overall rate of the traffic is metered on every link in the > >>> domain, and packets are appropriately marked when certain > >>> configured rates are exceeded. Boundary nodes can measure the > level > >>> of marking and thus make decisions about whether to admit or > block a > >>> new flow request, and (in abnormal circumstances) whether to > >>> terminate some of the existing flows, thereby protecting the = QoS > of > >>> previously admitted flows. This document specifies how such > marks > >>> are encoded into the IP header by re-using the Explicit > Congestion > >>> Notification (ECN) codepoints within this controlled domain. > The > >>> baseline encoding described here provides for only two PCN > encoding > >>> states, Not-marked and PCN-marked. > >>> > >>>I personally disagree with Tom's suggestion to > >>>add PCN to all the defined terms (e.g. PCN > >>>flow, PCN traffic) - that is fine within the > >>>body of the document but in this abstract we > >>>should avoid using any terms that readers > >>>won't be already familiar with. > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >>>>Sent: 26 August 2009 08:46 > >>>>To: Ruediger.Geib@telekom.de > >>>>Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; = pcn@ietf.org > >>>>Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- > >>>>baseline-encoding-05 > >>>> > >>>>Hi all, > >>>> > >>>>R=FCdiger touches an issue that I also feel is not optimally = solved > in > >>>>the > >>>>current abstract. The objective of PCN is provide marking > information > >>>>to > >>>>egress node and the objective of admission control and flow > termination > >>>>is to protect QoS. I use the following short explanation for PCN. > Maybe > >>>>this idea could be added to the current abstract. > >>>> > >>>>Pre-congestion notification (PCN) is a metering and marking scheme > for > >>>>Differentiated Services (DiffServ) IP networks which provides > egress > >>>>nodes with information about load conditions inside the network > >>>>\cite{RFC5559}. This information is used for admission control and > flow > >>>>termination to support quality of service (QoS) for admitted > inelastic > >>>>realtime flows that are carried with prioritization within the > DiffServ > >>>>domain. > >>>>This document specifies how nodes encode the marking information = in > the > >>>>IP header by re-using the Explicit Congestion Notification (ECN) > >>>>codepoints within a controlled DiffServ domain. The baseline > encoding > >>>>described here provides for only two PCN encoding states which are > >>>>not-marked and PCN-marked. > >>>> > >>>>Regards, > >>>> > >>>> Michael > >>>> > >>>>Ruediger.Geib@telekom.de schrieb: > >>>> > >>>>>Toby, Bob > >>>>> > >>>>>if the abstract is to mention PCN functionalities not defined > within > >>>>>this document in a rather simplified way, would the purpose of = PCN > >>>>>be to enable a Diffserv domain to support measurement based > >>>>>admission control as defined by PCN architecture? > >>>>> > >>>>>Regards, > >>>>> > >>>>>Ruediger > >>>>> > >>>>>-----Original Message----- > >>>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf > Of > >>>>> > >>>>Bob Briscoe > >>>> > >>>>>Sent: Tuesday, August 25, 2009 8:42 PM > >>>>>To: toby.moncaster@bt.com; pcn@ietf.org > >>>>>Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review = ofdraft-ietf-pcn- > >>>>> > >>>>baseline-encoding-05 > >>>> > >>>>>Toby, > >>>>> > >>>>>I think this isn't just good for a casual reader, but it is > actually > >>>>>still correct and doesn't require defining PC-domain (which is > just > >>>>>the Diffserv domain once the described measures - the PDB - have > been > >>>>>put in place). > >>>>> > >>>>> > >>>>>Bob > >>>>> > >>>>>At 15:53 25/08/2009, toby.moncaster@bt.com wrote: > >>>>> > >>>>> > >>>>>>This potentially raises an issue for all future PCN documents > since > >>>>>> > >>>>the > >>>> > >>>>>>abstract was based on our agreed standard elevator-pitch > >>>>>> > >>>>introduction to > >>>> > >>>>>>PCN... Specifically Spencer raises the question of using the > defined > >>>>>>term PCN-domain in the abstract. Any thoughts from anyone as to > >>>>>> > >>>>whether > >>>> > >>>>>>this is confusing? Would it be clearer to just use "domain" = (e.g. > >>>>>> > >>>>drop > >>>> > >>>>>>the "PCN-"). In which case should I alter the whole abstract as > >>>>>> > >>>>follows > >>>> > >>>>>>(note: I realise this is strictly incorrect as it now doesn't > seek > >>>>>> > >>>>to > >>>> > >>>>>>distinguish the non-PCN and PCN traffic from each other but is > this > >>>>>>clearer for a casual reader?): > >>>>>> > >>>>>> The objective of Pre-Congestion Notification (PCN) is to > protect > >>>>>> > >>>>the > >>>> > >>>>>> quality of service (QoS) of inelastic flows within a = Diffserv > >>>>>> > >>>>domain. > >>>> > >>>>>> The overall rate of the traffic is metered on every link in > the > >>>>>> domain, and packets are appropriately marked when certain > >>>>>> configured rates are exceeded. Boundary nodes can measure > the > >>>>>> > >>>>level > >>>> > >>>>>> of marking and thus make decisions about whether to admit or > >>>>>> > >>>>block a > >>>> > >>>>>> new flow request, and (in abnormal circumstances) whether to > >>>>>> terminate some of the existing flows, thereby protecting the > QoS > >>>>>> > >>>>of > >>>> > >>>>>> previously admitted flows. This document specifies how such > >>>>>> > >>>>marks > >>>> > >>>>>> are encoded into the IP header by re-using the Explicit > >>>>>> > >>>>Congestion > >>>> > >>>>>> Notification (ECN) codepoints within this controlled domain. > The > >>>>>> baseline encoding described here provides for only two PCN > >>>>>> > >>>>encoding > >>>> > >>>>>> states, Not-marked and PCN-marked. > >>>>>> > >>>>>>Toby > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf > >>>>>>> > >>>>Of > >>>> > >>>>>>>Lars Eggert > >>>>>>>Sent: 25 August 2009 15:12 > >>>>>>>To: pcn@ietf.org > >>>>>>>Subject: [PCN] Fwd: [Gen-art] Gen-ART Review > >>>>>>> > >>>>>>> > >>>>>>ofdraft-ietf-pcn-baseline- > >>>>>> > >>>>>> > >>>>>>>encoding-05 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>Begin forwarded message: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>From: Spencer Dawkins > >>>>>>>>Date: August 25, 2009 14:47:49 GMT+02:00 > >>>>>>>>To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" > >>>>>>>> > >>>>>>>> > >>>>>> >>>>>> > >>>>>> > >>>>>>>pcn-baseline-encoding@tools.ietf.org > >>>>>>> > >>>>>>> > >>>>>>>>Cc: General Area Review Team , > >>>>>>>> > >>>>>>>> > >>>>>>>"ietf@ietf.org > >>>>>>> > >>>>>>> > >>>>>>>>" > >>>>>>>>Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- > >>>>>>>>encoding-05 > >>>>>>>> > >>>>>>>>I have been selected as the General Area Review Team (Gen-ART) > >>>>>>>>reviewer for this draft (for background on Gen-ART, please see > >>>>>>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >>>>>>>> > >>>>>>>>Please wait for direction from your document shepherd or AD > before > >>>>>>>>posting a new version of the draft. > >>>>>>>> > >>>>>>>>Document: draft-ietf-pcn-baseline-encoding-05 > >>>>>>>>Reviewer: Spencer Dawkins > >>>>>>>>IETF LC End Date: 2009-09-03 > >>>>>>>>Review Date: 2009-08-21 > >>>>>>>>IESG Telechat date: (not known) > >>>>>>>> > >>>>>>>>Summary: this specification is almost ready for publication as > a > >>>>>>>>Proposed Standard. I have one minor question below (flagged as > >>>>>>>>"Spencer (minor)"), along with some editorial suggestions to = be > >>>>>>>>considered when this document is edited (either in the working > >>>>>>>> > >>>>group > >>>> > >>>>>>>>or by the RFC Editor). > >>>>>>>> > >>>>>>>>Abstract > >>>>>>>> > >>>>>>>> The objective of Pre-Congestion Notification (PCN) is to > protect > >>>>>>>> > >>>>>>>> > >>>>>>>the > >>>>>>> > >>>>>>> > >>>>>>>> quality of service (QoS) of inelastic flows within a > Diffserv > >>>>>>>>domain. > >>>>>>>> > >>>>>>>>Spencer (clarity): I'm not sure what the relationship between = a > >>>>>>>>Diffserv domain and a PCN-domain is - this couuld be clearer, > >>>>>>>>especially in an Abstract. I note that RFC 5559 doesn't use = the > >>>>>>>> > >>>>term > >>>> > >>>>>>>>PCN-domain in its Abstract ... I can guess, but I'm just > guessing. > >>>>>>>> > >>>>>>>> The overall rate of the PCN-traffic is metered on every = link > in > >>>>>>>> > >>>>>>>> > >>>>>>the > >>>>>> > >>>>>> > >>>>>>>> PCN-domain, and PCN-packets are appropriately marked when > >>>>>>>> > >>>>certain > >>>> > >>>>>>>> configured rates are exceeded. The level of marking allows > the > >>>>>>>> boundary nodes to make decisions about whether to admit or > block > >>>>>>>> > >>>>a > >>>> > >>>>>>>> new flow request, and (in abnormal circumstances) whether = to > >>>>>>>> terminate some of the existing flows, thereby protecting = the > QoS > >>>>>>>> > >>>>>>>> > >>>>>>of > >>>>>> > >>>>>> > >>>>>>>> previously admitted flows. This document specifies how = such > >>>>>>>> > >>>>marks > >>>> > >>>>>>>> are to be encoded into the IP header by re-using the > Explicit > >>>>>>>> Congestion Notification (ECN) codepoints within this > controlled > >>>>>>>> domain. The baseline encoding described here provides for > only > >>>>>>>> > >>>>>>>> > >>>>>>two > >>>>>> > >>>>>> > >>>>>>>> PCN encoding states, Not-marked and PCN-marked. > >>>>>>>> > >>>>>>>>4. Encoding two PCN States in IP > >>>>>>>> > >>>>>>>> The following rules apply to all PCN traffic: > >>>>>>>> > >>>>>>>> o PCN-traffic MUST be marked with a PCN-compatible = Diffserv > >>>>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints = SHOULD > be > >>>>>>>> chosen that are already defined for use with admission > >>>>>>>> > >>>>>>>> > >>>>>>>controlled > >>>>>>> > >>>>>>> > >>>>>>>> traffic. Appendix A.1 gives guidance to implementiors = on > >>>>>>>>suitable > >>>>>>>> > >>>>>>>>Spencer (clarity): s/implementiors/implementers/? > >>>>>>>> > >>>>>>>> DSCPs. Guidelines for mixing traffic-types within a = PCN- > >>>>>>>> > >>>>domain > >>>> > >>>>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. > >>>>>>>> > >>>>>>>> o Any packet that is not-PCN but which shares the same > Diffserv > >>>>>>>> codepoint as PCN-enabled traffic MUST have the ECN field > of > >>>>>>>> > >>>>its > >>>> > >>>>>>>> outermost IP header equal to 00. > >>>>>>>> > >>>>>>>>Spencer (minor): this is the only point in the specification > (that > >>>>>>>> > >>>>I > >>>> > >>>>>>>>can > >>>>>>>>find) that makes reference to the "outermost IP header". I'm > not > >>>>>>>> > >>>>>>>> > >>>>>>sure > >>>>>> > >>>>>> > >>>>>>>>whether to suggest s/outermost// here or to ask that a > statement > >>>>>>>> > >>>>be > >>>> > >>>>>>>>added earlier in the document to clearly state that PCN > encoding > >>>>>>>> > >>>>>>>> > >>>>>>only > >>>>>> > >>>>>> > >>>>>>>>protects inelastic traffic when it's used for the outermost IP > >>>>>>>> > >>>>>>>> > >>>>>>>header, > >>>>>>> > >>>>>>> > >>>>>>>>but the current text seems to call attention to this in a way > that > >>>>>>>>makes the reader wonder what is special about THIS requirement > >>>>>>>> > >>>>that > >>>> > >>>>>>>>isn't true of the other requirements listed. > >>>>>>>> > >>>>>>>>4.3. PCN-Compatible Diffserv Codepoints > >>>>>>>> > >>>>>>>> Enabling PCN marking behaviour for a specific DSCP disables > any > >>>>>>>>other > >>>>>>>> marking behaviour (e.g. enabling PCN disables the default > ECN > >>>>>>>>marking > >>>>>>>> behaviour introduced in [RFC3168]). All traffic metering > and > >>>>>>>>marking > >>>>>>>> > >>>>>>>>Spencer (clarity): here, and in Section 6, the text uses > >>>>>>>> > >>>>"disables" > >>>> > >>>>>>>to > >>>>>>> > >>>>>>> > >>>>>>>>describe the relationship between PCN and ECN. If I understand > the > >>>>>>>>point, the domain is substituting one behavior for another. I > >>>>>>>> > >>>>might > >>>> > >>>>>>>>suggest "replaces" to describe the relationship in both > locations. > >>>>>>>> > >>>>>>>> behaviours are discussed in [I-D.ietf-pcn-marking- > behaviour]. > >>>>>>>> > >>>>>>>> > >>>>>>This > >>>>>> > >>>>>> > >>>>>>>> ensures compliance with the BCP guidance set out in > [RFC4774]. > >>>>>>>> > >>>>>>>>4.3.1. Co-existence of PCN and not-PCN traffic > >>>>>>>> > >>>>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN > is > >>>>>>>> envisaged as a marking behaviour that could be applied to a > >>>>>>>> > >>>>number > >>>> > >>>>>>>>of > >>>>>>>> different DSCPs makes it essential that we provide a = not-PCN > >>>>>>>> > >>>>>>>> > >>>>>>state. > >>>>>> > >>>>>> > >>>>>>>> As stated above (and expanded in Appendix A.1) the aim is > for > >>>>>>>> > >>>>PCN > >>>> > >>>>>>>to > >>>>>>> > >>>>>>> > >>>>>>>> re-use existing DSCPs. Because PCN re-defines the meaning > of > >>>>>>>> > >>>>the > >>>> > >>>>>>>>ECN > >>>>>>>> > >>>>>>>>Spencer (clarity): here, the text uses "re-defines", which I > like > >>>>>>>>better than "disables", but if you go for "replaces" = previously > >>>>>>>> > >>>>and > >>>> > >>>>>>>in > >>>>>>> > >>>>>>> > >>>>>>>>section 6, you might want to use the same wording here. > >>>>>>>> > >>>>>>>> field for such DSCPs it is important to allow an operator = to > >>>>>>>> > >>>>still > >>>> > >>>>>>>> use the DSCP for traffic that isn't PCN-enabled. This is > >>>>>>>> > >>>>achieved > >>>> > >>>>>>>>by > >>>>>>>> providing a not-PCN state within the encoding scheme. > >>>>>>>> > >>>>>>>>A.1. Choice of Suitable DSCPs > >>>>>>>> > >>>>>>>> The PCN Working Group chose not to define a single DSCP for > use > >>>>>>>> > >>>>>>>> > >>>>>>>with > >>>>>>> > >>>>>>> > >>>>>>>> PCN for several reasons. Firstly the PCN mechanism is > >>>>>>>> > >>>>applicable > >>>> > >>>>>>>to > >>>>>>> > >>>>>>> > >>>>>>>> a variety of different traffic classes. Secondly standards > >>>>>>>> > >>>>track > >>>> > >>>>>>>> DSCPs are in increasingly short supply. Thirdly PCN should > be > >>>>>>>> > >>>>>>>> > >>>>>>seen > >>>>>> > >>>>>> > >>>>>>>> as being essentially a marking behaviour similar to ECN but > >>>>>>>> > >>>>>>>> > >>>>>>>intended > >>>>>>> > >>>>>>> > >>>>>>>> for inelastic traffic. The choice of which DSCP is most > >>>>>>>> > >>>>suitable > >>>> > >>>>>>>>for > >>>>>>>> a given PCN-domain is dependent on the nature of the = traffic > >>>>>>>>entering > >>>>>>>> that domain and the link rates of all the links making up > that > >>>>>>>> domain. In PCN-domains with uniformly high link rates, the > >>>>>>>> appropriate DSCPs would currently be those for the Real = Time > >>>>>>>> > >>>>>>>> > >>>>>>>Traffic > >>>>>>> > >>>>>>> > >>>>>>>> Class [RFC5127]. To be clear the PCN Working Group > recommends > >>>>>>>> > >>>>>>>> > >>>>>>>using > >>>>>>> > >>>>>>> > >>>>>>>>Spencer (clarity): is this 2119 language (apparently not, = since > >>>>>>>> > >>>>this > >>>> > >>>>>>>>section is not normative), or are you saying "suggests"? My > >>>>>>>> > >>>>>>>> > >>>>>>>suggestion > >>>>>>> > >>>>>>> > >>>>>>>>is that we not use 2119 language, even lowercased, except for > >>>>>>>>normative text - this seems to cause confusion from time to > time. > >>>>>>>> > >>>>>>>> > >>>>>>But > >>>>>> > >>>>>> > >>>>>>>>please check with your shepherding AD to see if he agrees. > >>>>>>>> > >>>>>>>> admission control for the following service classes: > >>>>>>>> > >>>>>>>> o Telephony (EF) > >>>>>>>> > >>>>>>>> o Real-time interactive (CS4) > >>>>>>>> > >>>>>>>> o Broadcast Video (CS3) > >>>>>>>> > >>>>>>>> o Multimedia Conferencing (AF4) > >>>>>>>> > >>>>>>>>_______________________________________________ > >>>>>>>>Gen-art mailing list > >>>>>>>>Gen-art@ietf.org > >>>>>>>>https://www.ietf.org/mailman/listinfo/gen-art > >>>>>>>> > >>>>>>>> > >>>>>>_______________________________________________ > >>>>>>PCN mailing list > >>>>>>PCN@ietf.org > >>>>>>https://www.ietf.org/mailman/listinfo/pcn > >>>>>> > >>>>>> > >>>>>_______________________________________________ > >>>>>PCN mailing list > >>>>>PCN@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/pcn > >>>>>_______________________________________________ > >>>>>PCN mailing list > >>>>>PCN@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/pcn > >>>>> > >>>>> > >>>>-- > >>>>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 > >>>> > >> > >>-- > >>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 menth@informatik.uni-wuerzburg.de Thu Aug 27 03:13:39 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 675E628C17E for ; Thu, 27 Aug 2009 03:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, SARE_OBFU_COULD=0.917] 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 t8UgO6o4nAen for ; Thu, 27 Aug 2009 03:13:37 -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 5C87A28C263 for ; Thu, 27 Aug 2009 03:12:38 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 7F82B199604; Thu, 27 Aug 2009 12:12:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 719631995EA; Thu, 27 Aug 2009 12:12:44 +0200 (CEST) Received: from [192.168.1.2] (f051069091.adsl.alicedsl.de [78.51.69.91]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A98CA1993CC; Thu, 27 Aug 2009 12:12:43 +0200 (CEST) Message-ID: <4A965BE0.3050708@informatik.uni-wuerzburg.de> Date: Thu, 27 Aug 2009 12:11:44 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <20090826161528.6CDD41C000A8@mwinf5908> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 27 Aug 2009 10:13:39 -0000 Hi Toby, the abstract still misses my point. 1) PCN is the metering and marking scheme 2) QoS is protected by AC and FT (not by marking packets!) PCN protects QoS only indirectly. Your abstracts are formulated in a way that this does not become very clear vor the casual reader. My two sentences to Rüdiger in my last email were based on Bob's proposal and fix that shortcoming. Regards, Michael toby.moncaster@bt.com schrieb: > OK, my last 2 suggested versions. PLEASE can we just make a decision now! > > Version 1 (13 lines): > > Pre-Congestion Notification (PCN) is a scheme for packet metering > and marking that can be used within a Diffserv domain to protect > the quality of service (QoS) of inelastic flows. It does this by > measuring pre-congestion information at the boundaries of the > domain. This information is used to determine whether to admit > new flows or (in abnormal circumstances) terminate some existing > flows, thereby protecting the QoS of previously admitted flows. > The pre-congestion information is provided by marking packets > when the overall rate of PCN traffic on a link exceeds certain > configured rates. This document specifies how such marks are > encoded into the IP header by re-using the Explicit Congestion > Notification (ECN) codepoints within this controlled domain. > The baseline encoding described here provides for only two PCN > encoding states, Not-marked and PCN-marked. > > > Version 2 (11 lines): > > Pre-Congestion Notification (PCN) is a scheme for packet metering and > marking that can help protect the quality of service (QoS) of > inelastic flows within a Diffserv domain. Within the domain nodes > measure the rate of PCN traffic on each link and mark packets if that > rate exceeds a configured threshold. This pre-congestion information > is measured at the boundaries of the domain and is then used to > determine whether to admit new flows or (in extremis) terminate some > existing flows. This protects the QoS of previously admitted flows. > This document specifies how such marks are encoded into the IP header > by re-using the Explicit Congestion Notification (ECN) codepoints > within this controlled domain. The baseline encoding described here > provides for only two PCN encoding states, Not-marked and PCN-marked. > > Toby > > >> -----Original Message----- >> From: Bob Briscoe [mailto:bob@homefarmparham.co.uk] >> Sent: 26 August 2009 17:15 >> To: Moncaster,T,Toby,DER3 R >> Subject: Fwd: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >> baseline-encoding-05 >> >> Toby, >> >> inline, following up my own post... >> >> >>> Date: Wed, 26 Aug 2009 16:50:15 +0100 >>> To: menth@informatik.uni-wuerzburg.de, Ruediger.Geib@telekom.de >>> From: Bob Briscoe >>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART >>> Review ofdraft-ietf-pcn-baseline-encoding-05 >>> Cc: toby.moncaster@bt.com, pcn@ietf.org >>> >>> Michael, >>> >>> I agree that we should use the term PCN to mean >>> the notification part, not the whole traffic >>> control system built around it. We had this >>> discussion when publishing the architecture. >>> >>> * CORRECT: what Phil did in the Intro to the architecture. >>> " >>> 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. >>> >>> " >>> (paraphrasing: the *objective* of notification is to protect QoS) >>> >>> * INCORRECT: The first sentence of Toby's abstract says: >>> "Pre-Congestion Notification (PCN) is a metering and marking scheme >>> >> that >> >>> protects the quality of service (QoS) of >>> inelastic flows within a Diffserv >>> domain." >>> (paraphrasing: notification *is* a scheme that protects QoS) >>> >>> Suggestion to fix the first >>> sentence:"Pre-Congestion Notification (PCN) is a >>> scheme for metering and marking packets that >>> can be used to protect the quality of service >>> (QoS) of inelastic flows within a Diffserv domain." >>> >> Just realised that's ambiguous: "scheme that can >> be used" or "packets that can be used"? >> >> 2nd attempt: >> "Pre-Congestion Notification (PCN) is a scheme >> for packet metering and marking that can be used >> to protect the quality of service (QoS) of >> inelastic flows within a Diffserv domain." >> >> >> >> >> >>> Bob >>> >>> At 16:12 26/08/2009, Michael Menth wrote: >>> >>>> Hi Ruediger, Toby, >>>> >>>> Ruediger.Geib@telekom.de schrieb: >>>> >>>>> Toby, >>>>> >>>>> you simply ommited some "PCN" in your new >>>>> version. I think the problem addressed by >>>>> Spencer may be that you try to sum up RFC5559 rather then refer to >>>>> >> it. >> >>>>> Below there's an abstract proposal, structured top-down: >>>>> - What's PCN: a copy of the abstract of RFC5559. >>>>> - What's the functionality relevant for this document: marking >>>>> - What's specified by this document: baseline encoding >>>>> My try: >>>>> >>>>> PCN specifies 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. >>>>> >>>> What is PCN? Or is admission control and flow >>>> termination also part of PCN? My take on this >>>> is that PCN is only the marking scheme and the >>>> way the information is carried to egress nodes. >>>> AC and FT is just built on top of PCN. And to >>>> support QoS is the objective of AC and FT, not >>>> primarily or only indirectly the objective of the marking scheme. >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>> >>>>> As a part of this specification, the overall >>>>> rate of the PCN coloured traffic is metered on >>>>> every link in the domain, and these packets >>>>> are appropriately marked when certain configured rates are exceeded. >>>>> This document specifies how such marks are >>>>> encoded into the IP header by re-using the >>>>> Explicit Congestion Notification (ECN) >>>>> codepoints within this controlled domain. The >>>>> baseline encoding described here provides for >>>>> only two PCN encoding states, Not-marked and PCN-marked. >>>>> >>>>> >>>>> >>>>> Please maintain the notion of "overall rate of >>>>> PCN traffic" or "PCN coloured traffic" which >>>>> is being metered in the version of abstract you go on with. >>>>> >>>>> Regards, >>>>> >>>>> Ruediger >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: toby.moncaster@bt.com >>>>> [mailto:toby.moncaster@bt.com] Sent: Wednesday, August 26, 2009 1:13 >>>>> >> PM >> >>>>> To: menth@informatik.uni-wuerzburg.de; Geib, Rüdiger >>>>> Cc: bob@homefarmparham.co.uk; pcn@ietf.org >>>>> Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART >>>>> Review ofdraft-ietf-pcn-baseline-encoding-05 >>>>> >>>>> So would the following sound better? : >>>>> >>>>> Pre-Congestion Notification (PCN) is a >>>>> metering and marking scheme that protects >>>>> the quality of service (QoS) of inelastic >>>>> flows within a Diffserv domain. The >>>>> overall rate of the traffic is metered on >>>>> every link in the domain, and packets are appropriately marked >>>>> >> when certain >> >>>>> configured rates are exceeded. Boundary nodes can measure the >>>>> >> level >> >>>>> of marking and thus make decisions about whether to admit or >>>>> >> block a >> >>>>> new flow request, and (in abnormal circumstances) whether to >>>>> terminate some of the existing flows, thereby protecting the QoS >>>>> >> of >> >>>>> previously admitted flows. This document specifies how such >>>>> >> marks >> >>>>> are encoded into the IP header by re-using the Explicit >>>>> >> Congestion >> >>>>> Notification (ECN) codepoints within this controlled domain. >>>>> >> The >> >>>>> baseline encoding described here provides for only two PCN >>>>> >> encoding >> >>>>> states, Not-marked and PCN-marked. >>>>> >>>>> Just for clarity here was the earlier version I proposed: >>>>> >>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>> >> the >> >>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>> >> domain. >> >>>>> The overall rate of the traffic is metered on every link in the >>>>> domain, and packets are appropriately marked when certain >>>>> configured rates are exceeded. Boundary nodes can measure the >>>>> >> level >> >>>>> of marking and thus make decisions about whether to admit or >>>>> >> block a >> >>>>> new flow request, and (in abnormal circumstances) whether to >>>>> terminate some of the existing flows, thereby protecting the QoS >>>>> >> of >> >>>>> previously admitted flows. This document specifies how such >>>>> >> marks >> >>>>> are encoded into the IP header by re-using the Explicit >>>>> >> Congestion >> >>>>> Notification (ECN) codepoints within this controlled domain. >>>>> >> The >> >>>>> baseline encoding described here provides for only two PCN >>>>> >> encoding >> >>>>> states, Not-marked and PCN-marked. >>>>> >>>>> I personally disagree with Tom's suggestion to >>>>> add PCN to all the defined terms (e.g. PCN >>>>> flow, PCN traffic) - that is fine within the >>>>> body of the document but in this abstract we >>>>> should avoid using any terms that readers >>>>> won't be already familiar with. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>>>> Sent: 26 August 2009 08:46 >>>>>> To: Ruediger.Geib@telekom.de >>>>>> Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >>>>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>>>> baseline-encoding-05 >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Rüdiger touches an issue that I also feel is not optimally solved >>>>>> >> in >> >>>>>> the >>>>>> current abstract. The objective of PCN is provide marking >>>>>> >> information >> >>>>>> to >>>>>> egress node and the objective of admission control and flow >>>>>> >> termination >> >>>>>> is to protect QoS. I use the following short explanation for PCN. >>>>>> >> Maybe >> >>>>>> this idea could be added to the current abstract. >>>>>> >>>>>> Pre-congestion notification (PCN) is a metering and marking scheme >>>>>> >> for >> >>>>>> Differentiated Services (DiffServ) IP networks which provides >>>>>> >> egress >> >>>>>> nodes with information about load conditions inside the network >>>>>> \cite{RFC5559}. This information is used for admission control and >>>>>> >> flow >> >>>>>> termination to support quality of service (QoS) for admitted >>>>>> >> inelastic >> >>>>>> realtime flows that are carried with prioritization within the >>>>>> >> DiffServ >> >>>>>> domain. >>>>>> This document specifies how nodes encode the marking information in >>>>>> >> the >> >>>>>> IP header by re-using the Explicit Congestion Notification (ECN) >>>>>> codepoints within a controlled DiffServ domain. The baseline >>>>>> >> encoding >> >>>>>> described here provides for only two PCN encoding states which are >>>>>> not-marked and PCN-marked. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Michael >>>>>> >>>>>> Ruediger.Geib@telekom.de schrieb: >>>>>> >>>>>> >>>>>>> Toby, Bob >>>>>>> >>>>>>> if the abstract is to mention PCN functionalities not defined >>>>>>> >> within >> >>>>>>> this document in a rather simplified way, would the purpose of PCN >>>>>>> be to enable a Diffserv domain to support measurement based >>>>>>> admission control as defined by PCN architecture? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ruediger >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>>>>> >> Of >> >>>>>> Bob Briscoe >>>>>> >>>>>> >>>>>>> Sent: Tuesday, August 25, 2009 8:42 PM >>>>>>> To: toby.moncaster@bt.com; pcn@ietf.org >>>>>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>>>>> >>>>>>> >>>>>> baseline-encoding-05 >>>>>> >>>>>> >>>>>>> Toby, >>>>>>> >>>>>>> I think this isn't just good for a casual reader, but it is >>>>>>> >> actually >> >>>>>>> still correct and doesn't require defining PC-domain (which is >>>>>>> >> just >> >>>>>>> the Diffserv domain once the described measures - the PDB - have >>>>>>> >> been >> >>>>>>> put in place). >>>>>>> >>>>>>> >>>>>>> Bob >>>>>>> >>>>>>> At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> This potentially raises an issue for all future PCN documents >>>>>>>> >> since >> >>>>>> the >>>>>> >>>>>> >>>>>>>> abstract was based on our agreed standard elevator-pitch >>>>>>>> >>>>>>>> >>>>>> introduction to >>>>>> >>>>>> >>>>>>>> PCN... Specifically Spencer raises the question of using the >>>>>>>> >> defined >> >>>>>>>> term PCN-domain in the abstract. Any thoughts from anyone as to >>>>>>>> >>>>>>>> >>>>>> whether >>>>>> >>>>>> >>>>>>>> this is confusing? Would it be clearer to just use "domain" (e.g. >>>>>>>> >>>>>>>> >>>>>> drop >>>>>> >>>>>> >>>>>>>> the "PCN-"). In which case should I alter the whole abstract as >>>>>>>> >>>>>>>> >>>>>> follows >>>>>> >>>>>> >>>>>>>> (note: I realise this is strictly incorrect as it now doesn't >>>>>>>> >> seek >> >>>>>> to >>>>>> >>>>>> >>>>>>>> distinguish the non-PCN and PCN traffic from each other but is >>>>>>>> >> this >> >>>>>>>> clearer for a casual reader?): >>>>>>>> >>>>>>>> The objective of Pre-Congestion Notification (PCN) is to >>>>>>>> >> protect >> >>>>>> the >>>>>> >>>>>> >>>>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>>>> >>>>>>>> >>>>>> domain. >>>>>> >>>>>> >>>>>>>> The overall rate of the traffic is metered on every link in >>>>>>>> >> the >> >>>>>>>> domain, and packets are appropriately marked when certain >>>>>>>> configured rates are exceeded. Boundary nodes can measure >>>>>>>> >> the >> >>>>>> level >>>>>> >>>>>> >>>>>>>> of marking and thus make decisions about whether to admit or >>>>>>>> >>>>>>>> >>>>>> block a >>>>>> >>>>>> >>>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>>> terminate some of the existing flows, thereby protecting the >>>>>>>> >> QoS >> >>>>>> of >>>>>> >>>>>> >>>>>>>> previously admitted flows. This document specifies how such >>>>>>>> >>>>>>>> >>>>>> marks >>>>>> >>>>>> >>>>>>>> are encoded into the IP header by re-using the Explicit >>>>>>>> >>>>>>>> >>>>>> Congestion >>>>>> >>>>>> >>>>>>>> Notification (ECN) codepoints within this controlled domain. >>>>>>>> >> The >> >>>>>>>> baseline encoding described here provides for only two PCN >>>>>>>> >>>>>>>> >>>>>> encoding >>>>>> >>>>>> >>>>>>>> states, Not-marked and PCN-marked. >>>>>>>> >>>>>>>> Toby >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>>>>> >> Behalf >> >>>>>> Of >>>>>> >>>>>> >>>>>>>>> Lars Eggert >>>>>>>>> Sent: 25 August 2009 15:12 >>>>>>>>> To: pcn@ietf.org >>>>>>>>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ofdraft-ietf-pcn-baseline- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> encoding-05 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> From: Spencer Dawkins >>>>>>>>>> Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>>>>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> pcn-baseline-encoding@tools.ietf.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Cc: General Area Review Team , >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> "ietf@ietf.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> " >>>>>>>>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>>>>>>>> encoding-05 >>>>>>>>>> >>>>>>>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>>>>>>> reviewer for this draft (for background on Gen-ART, please see >>>>>>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>>>>>> >>>>>>>>>> Please wait for direction from your document shepherd or AD >>>>>>>>>> >> before >> >>>>>>>>>> posting a new version of the draft. >>>>>>>>>> >>>>>>>>>> Document: draft-ietf-pcn-baseline-encoding-05 >>>>>>>>>> Reviewer: Spencer Dawkins >>>>>>>>>> IETF LC End Date: 2009-09-03 >>>>>>>>>> Review Date: 2009-08-21 >>>>>>>>>> IESG Telechat date: (not known) >>>>>>>>>> >>>>>>>>>> Summary: this specification is almost ready for publication as >>>>>>>>>> >> a >> >>>>>>>>>> Proposed Standard. I have one minor question below (flagged as >>>>>>>>>> "Spencer (minor)"), along with some editorial suggestions to be >>>>>>>>>> considered when this document is edited (either in the working >>>>>>>>>> >>>>>>>>>> >>>>>> group >>>>>> >>>>>> >>>>>>>>>> or by the RFC Editor). >>>>>>>>>> >>>>>>>>>> Abstract >>>>>>>>>> >>>>>>>>>> The objective of Pre-Congestion Notification (PCN) is to >>>>>>>>>> >> protect >> >>>>>>>>>> >>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> quality of service (QoS) of inelastic flows within a >>>>>>>>>> >> Diffserv >> >>>>>>>>>> domain. >>>>>>>>>> >>>>>>>>>> Spencer (clarity): I'm not sure what the relationship between a >>>>>>>>>> Diffserv domain and a PCN-domain is - this couuld be clearer, >>>>>>>>>> especially in an Abstract. I note that RFC 5559 doesn't use the >>>>>>>>>> >>>>>>>>>> >>>>>> term >>>>>> >>>>>> >>>>>>>>>> PCN-domain in its Abstract ... I can guess, but I'm just >>>>>>>>>> >> guessing. >> >>>>>>>>>> The overall rate of the PCN-traffic is metered on every link >>>>>>>>>> >> in >> >>>>>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> PCN-domain, and PCN-packets are appropriately marked when >>>>>>>>>> >>>>>>>>>> >>>>>> certain >>>>>> >>>>>> >>>>>>>>>> configured rates are exceeded. The level of marking allows >>>>>>>>>> >> the >> >>>>>>>>>> boundary nodes to make decisions about whether to admit or >>>>>>>>>> >> block >> >>>>>> a >>>>>> >>>>>> >>>>>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>>>>> terminate some of the existing flows, thereby protecting the >>>>>>>>>> >> QoS >> >>>>>>>>>> >>>>>>>> of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> previously admitted flows. This document specifies how such >>>>>>>>>> >>>>>>>>>> >>>>>> marks >>>>>> >>>>>> >>>>>>>>>> are to be encoded into the IP header by re-using the >>>>>>>>>> >> Explicit >> >>>>>>>>>> Congestion Notification (ECN) codepoints within this >>>>>>>>>> >> controlled >> >>>>>>>>>> domain. The baseline encoding described here provides for >>>>>>>>>> >> only >> >>>>>>>>>> >>>>>>>> two >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> PCN encoding states, Not-marked and PCN-marked. >>>>>>>>>> >>>>>>>>>> 4. Encoding two PCN States in IP >>>>>>>>>> >>>>>>>>>> The following rules apply to all PCN traffic: >>>>>>>>>> >>>>>>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>>>>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD >>>>>>>>>> >> be >> >>>>>>>>>> chosen that are already defined for use with admission >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> controlled >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> traffic. Appendix A.1 gives guidance to implementiors on >>>>>>>>>> suitable >>>>>>>>>> >>>>>>>>>> Spencer (clarity): s/implementiors/implementers/? >>>>>>>>>> >>>>>>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- >>>>>>>>>> >>>>>>>>>> >>>>>> domain >>>>>> >>>>>> >>>>>>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>>>>>>>> >>>>>>>>>> o Any packet that is not-PCN but which shares the same >>>>>>>>>> >> Diffserv >> >>>>>>>>>> codepoint as PCN-enabled traffic MUST have the ECN field >>>>>>>>>> >> of >> >>>>>> its >>>>>> >>>>>> >>>>>>>>>> outermost IP header equal to 00. >>>>>>>>>> >>>>>>>>>> Spencer (minor): this is the only point in the specification >>>>>>>>>> >> (that >> >>>>>> I >>>>>> >>>>>> >>>>>>>>>> can >>>>>>>>>> find) that makes reference to the "outermost IP header". I'm >>>>>>>>>> >> not >> >>>>>>>>>> >>>>>>>> sure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> whether to suggest s/outermost// here or to ask that a >>>>>>>>>> >> statement >> >>>>>> be >>>>>> >>>>>> >>>>>>>>>> added earlier in the document to clearly state that PCN >>>>>>>>>> >> encoding >> >>>>>>>>>> >>>>>>>> only >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> protects inelastic traffic when it's used for the outermost IP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> header, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> but the current text seems to call attention to this in a way >>>>>>>>>> >> that >> >>>>>>>>>> makes the reader wonder what is special about THIS requirement >>>>>>>>>> >>>>>>>>>> >>>>>> that >>>>>> >>>>>> >>>>>>>>>> isn't true of the other requirements listed. >>>>>>>>>> >>>>>>>>>> 4.3. PCN-Compatible Diffserv Codepoints >>>>>>>>>> >>>>>>>>>> Enabling PCN marking behaviour for a specific DSCP disables >>>>>>>>>> >> any >> >>>>>>>>>> other >>>>>>>>>> marking behaviour (e.g. enabling PCN disables the default >>>>>>>>>> >> ECN >> >>>>>>>>>> marking >>>>>>>>>> behaviour introduced in [RFC3168]). All traffic metering >>>>>>>>>> >> and >> >>>>>>>>>> marking >>>>>>>>>> >>>>>>>>>> Spencer (clarity): here, and in Section 6, the text uses >>>>>>>>>> >>>>>>>>>> >>>>>> "disables" >>>>>> >>>>>> >>>>>>>>> to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> describe the relationship between PCN and ECN. If I understand >>>>>>>>>> >> the >> >>>>>>>>>> point, the domain is substituting one behavior for another. I >>>>>>>>>> >>>>>>>>>> >>>>>> might >>>>>> >>>>>> >>>>>>>>>> suggest "replaces" to describe the relationship in both >>>>>>>>>> >> locations. >> >>>>>>>>>> behaviours are discussed in [I-D.ietf-pcn-marking- >>>>>>>>>> >> behaviour]. >> >>>>>>>>>> >>>>>>>> This >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> ensures compliance with the BCP guidance set out in >>>>>>>>>> >> [RFC4774]. >> >>>>>>>>>> 4.3.1. Co-existence of PCN and not-PCN traffic >>>>>>>>>> >>>>>>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN >>>>>>>>>> >> is >> >>>>>>>>>> envisaged as a marking behaviour that could be applied to a >>>>>>>>>> >>>>>>>>>> >>>>>> number >>>>>> >>>>>> >>>>>>>>>> of >>>>>>>>>> different DSCPs makes it essential that we provide a not-PCN >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> state. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> As stated above (and expanded in Appendix A.1) the aim is >>>>>>>>>> >> for >> >>>>>> PCN >>>>>> >>>>>> >>>>>>>>> to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> re-use existing DSCPs. Because PCN re-defines the meaning >>>>>>>>>> >> of >> >>>>>> the >>>>>> >>>>>> >>>>>>>>>> ECN >>>>>>>>>> >>>>>>>>>> Spencer (clarity): here, the text uses "re-defines", which I >>>>>>>>>> >> like >> >>>>>>>>>> better than "disables", but if you go for "replaces" previously >>>>>>>>>> >>>>>>>>>> >>>>>> and >>>>>> >>>>>> >>>>>>>>> in >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> section 6, you might want to use the same wording here. >>>>>>>>>> >>>>>>>>>> field for such DSCPs it is important to allow an operator to >>>>>>>>>> >>>>>>>>>> >>>>>> still >>>>>> >>>>>> >>>>>>>>>> use the DSCP for traffic that isn't PCN-enabled. This is >>>>>>>>>> >>>>>>>>>> >>>>>> achieved >>>>>> >>>>>> >>>>>>>>>> by >>>>>>>>>> providing a not-PCN state within the encoding scheme. >>>>>>>>>> >>>>>>>>>> A.1. Choice of Suitable DSCPs >>>>>>>>>> >>>>>>>>>> The PCN Working Group chose not to define a single DSCP for >>>>>>>>>> >> use >> >>>>>>>>>> >>>>>>>>> with >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> PCN for several reasons. Firstly the PCN mechanism is >>>>>>>>>> >>>>>>>>>> >>>>>> applicable >>>>>> >>>>>> >>>>>>>>> to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> a variety of different traffic classes. Secondly standards >>>>>>>>>> >>>>>>>>>> >>>>>> track >>>>>> >>>>>> >>>>>>>>>> DSCPs are in increasingly short supply. Thirdly PCN should >>>>>>>>>> >> be >> >>>>>>>>>> >>>>>>>> seen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> as being essentially a marking behaviour similar to ECN but >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> intended >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> for inelastic traffic. The choice of which DSCP is most >>>>>>>>>> >>>>>>>>>> >>>>>> suitable >>>>>> >>>>>> >>>>>>>>>> for >>>>>>>>>> a given PCN-domain is dependent on the nature of the traffic >>>>>>>>>> entering >>>>>>>>>> that domain and the link rates of all the links making up >>>>>>>>>> >> that >> >>>>>>>>>> domain. In PCN-domains with uniformly high link rates, the >>>>>>>>>> appropriate DSCPs would currently be those for the Real Time >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Traffic >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Class [RFC5127]. To be clear the PCN Working Group >>>>>>>>>> >> recommends >> >>>>>>>>>> >>>>>>>>> using >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Spencer (clarity): is this 2119 language (apparently not, since >>>>>>>>>> >>>>>>>>>> >>>>>> this >>>>>> >>>>>> >>>>>>>>>> section is not normative), or are you saying "suggests"? My >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> suggestion >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> is that we not use 2119 language, even lowercased, except for >>>>>>>>>> normative text - this seems to cause confusion from time to >>>>>>>>>> >> time. >> >>>>>>>>>> >>>>>>>> But >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> please check with your shepherding AD to see if he agrees. >>>>>>>>>> >>>>>>>>>> admission control for the following service classes: >>>>>>>>>> >>>>>>>>>> o Telephony (EF) >>>>>>>>>> >>>>>>>>>> o Real-time interactive (CS4) >>>>>>>>>> >>>>>>>>>> o Broadcast Video (CS3) >>>>>>>>>> >>>>>>>>>> o Multimedia Conferencing (AF4) >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Gen-art mailing list >>>>>>>>>> Gen-art@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> PCN mailing list >>>>>>>> PCN@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> PCN mailing list >>>>>>> PCN@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>>>> _______________________________________________ >>>>>>> PCN mailing list >>>>>>> PCN@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> >>>> -- >>>> 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 >>>> -- 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 Aug 27 09:28:35 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 161E228C22C for ; Thu, 27 Aug 2009 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, SARE_OBFU_COULD=0.917] 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 NnDiTPvXZGqu for ; Thu, 27 Aug 2009 09:28:32 -0700 (PDT) Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by core3.amsl.com (Postfix) with SMTP id 817CB28C21D for ; Thu, 27 Aug 2009 09:27:49 -0700 (PDT) Received: (qmail 28437 invoked from network); 27 Aug 2009 16:27:53 -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=6gOdNn7fb6uiqv4hw0Wrv6olQ6S4zsRS+heYchrpyFPbJ6SWZvyEk2xDXUcJu0+fRHDDJzO+/vB1GGQAFBe1heMOqvveKZum8KYynEzsKhXM+tatDVCVMOsIYMuf8eYUQeSsXUUWMQxbx4+0OVfNnNryhx0eI5l2yiKK17sUQVc= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 27 Aug 2009 16:27:53 -0000 X-YMail-OSG: olW3GpMVM1n8UBgO0zozNOjMC5o_A8CLDkZE4p_ahum1vPe0R9OKv39k2SnC2kEc.Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96B406.7080002@rogers.com> Date: Thu, 27 Aug 2009 12:27:50 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <20090826161528.6CDD41C000A8@mwinf5908> <4A965BE0.3050708@informatik.uni-wuerzburg.de> In-Reply-To: <4A965BE0.3050708@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: bob@homefarmparham.co.uk, pcn@ietf.org Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05 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, 27 Aug 2009 16:28:35 -0000 I like the text you and Ruediger provided. I'll use it for the edge behaviour drafts. Michael Menth wrote: > Hi Toby, > > the abstract still misses my point. > 1) PCN is the metering and marking scheme > 2) QoS is protected by AC and FT (not by marking packets!) > > PCN protects QoS only indirectly. Your abstracts are formulated in a way > that this does not become very clear vor the casual reader. My two > sentences to Rüdiger in my last email were based on Bob's proposal and > fix that shortcoming. > > Regards, > > Michael > > toby.moncaster@bt.com schrieb: >> OK, my last 2 suggested versions. PLEASE can we just make a decision now! >> >> Version 1 (13 lines): >> >> Pre-Congestion Notification (PCN) is a scheme for packet metering >> and marking that can be used within a Diffserv domain to protect >> the quality of service (QoS) of inelastic flows. It does this by >> measuring pre-congestion information at the boundaries of the domain. >> This information is used to determine whether to admit new flows or >> (in abnormal circumstances) terminate some existing flows, thereby >> protecting the QoS of previously admitted flows. The pre-congestion >> information is provided by marking packets when the overall rate of >> PCN traffic on a link exceeds certain configured rates. This document >> specifies how such marks are encoded into the IP header by re-using >> the Explicit Congestion Notification (ECN) codepoints within this >> controlled domain. The baseline encoding described here provides for >> only two PCN encoding states, Not-marked and PCN-marked. >> >> >> Version 2 (11 lines): >> >> Pre-Congestion Notification (PCN) is a scheme for packet metering and >> marking that can help protect the quality of service (QoS) of >> inelastic flows within a Diffserv domain. Within the domain nodes >> measure the rate of PCN traffic on each link and mark packets if that >> rate exceeds a configured threshold. This pre-congestion information >> is measured at the boundaries of the domain and is then used to >> determine whether to admit new flows or (in extremis) terminate some >> existing flows. This protects the QoS of previously admitted flows. >> This document specifies how such marks are encoded into the IP header >> by re-using the Explicit Congestion Notification (ECN) codepoints >> within this controlled domain. The baseline encoding described here >> provides for only two PCN encoding states, Not-marked and PCN-marked. >> >> Toby >> >> >>> -----Original Message----- >>> From: Bob Briscoe [mailto:bob@homefarmparham.co.uk] >>> Sent: 26 August 2009 17:15 >>> To: Moncaster,T,Toby,DER3 R >>> Subject: Fwd: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>> baseline-encoding-05 >>> >>> Toby, >>> >>> inline, following up my own post... >>> >>> >>>> Date: Wed, 26 Aug 2009 16:50:15 +0100 >>>> To: menth@informatik.uni-wuerzburg.de, Ruediger.Geib@telekom.de >>>> From: Bob Briscoe >>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART >>>> Review ofdraft-ietf-pcn-baseline-encoding-05 >>>> Cc: toby.moncaster@bt.com, pcn@ietf.org >>>> >>>> Michael, >>>> >>>> I agree that we should use the term PCN to mean >>>> the notification part, not the whole traffic >>>> control system built around it. We had this >>>> discussion when publishing the architecture. >>>> >>>> * CORRECT: what Phil did in the Intro to the architecture. >>>> " >>>> 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. >>>> >>>> " >>>> (paraphrasing: the *objective* of notification is to protect QoS) >>>> >>>> * INCORRECT: The first sentence of Toby's abstract says: >>>> "Pre-Congestion Notification (PCN) is a metering and marking scheme >>>> >>> that >>> >>>> protects the quality of service (QoS) of >>>> inelastic flows within a Diffserv >>>> domain." >>>> (paraphrasing: notification *is* a scheme that protects QoS) >>>> >>>> Suggestion to fix the first >>>> sentence:"Pre-Congestion Notification (PCN) is a >>>> scheme for metering and marking packets that >>>> can be used to protect the quality of service >>>> (QoS) of inelastic flows within a Diffserv domain." >>>> >>> Just realised that's ambiguous: "scheme that can >>> be used" or "packets that can be used"? >>> >>> 2nd attempt: >>> "Pre-Congestion Notification (PCN) is a scheme >>> for packet metering and marking that can be used >>> to protect the quality of service (QoS) of >>> inelastic flows within a Diffserv domain." >>> >>> >>> >>> >>> >>>> Bob >>>> >>>> At 16:12 26/08/2009, Michael Menth wrote: >>>> >>>>> Hi Ruediger, Toby, >>>>> >>>>> Ruediger.Geib@telekom.de schrieb: >>>>> >>>>>> Toby, >>>>>> >>>>>> you simply ommited some "PCN" in your new >>>>>> version. I think the problem addressed by >>>>>> Spencer may be that you try to sum up RFC5559 rather then refer to >>>>>> >>> it. >>> >>>>>> Below there's an abstract proposal, structured top-down: >>>>>> - What's PCN: a copy of the abstract of RFC5559. >>>>>> - What's the functionality relevant for this document: marking >>>>>> - What's specified by this document: baseline encoding >>>>>> My try: >>>>>> >>>>>> PCN specifies 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. >>>>>> >>>>> What is PCN? Or is admission control and flow >>>>> termination also part of PCN? My take on this >>>>> is that PCN is only the marking scheme and the >>>>> way the information is carried to egress nodes. >>>>> AC and FT is just built on top of PCN. And to >>>>> support QoS is the objective of AC and FT, not >>>>> primarily or only indirectly the objective of the marking scheme. >>>>> >>>>> Regards, >>>>> >>>>> Michael >>>>> >>>>> >>>>>> As a part of this specification, the overall >>>>>> rate of the PCN coloured traffic is metered on >>>>>> every link in the domain, and these packets >>>>>> are appropriately marked when certain configured rates are exceeded. >>>>>> This document specifies how such marks are >>>>>> encoded into the IP header by re-using the >>>>>> Explicit Congestion Notification (ECN) >>>>>> codepoints within this controlled domain. The >>>>>> baseline encoding described here provides for >>>>>> only two PCN encoding states, Not-marked and PCN-marked. >>>>>> >>>>>> >>>>>> >>>>>> Please maintain the notion of "overall rate of >>>>>> PCN traffic" or "PCN coloured traffic" which >>>>>> is being metered in the version of abstract you go on with. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ruediger >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: toby.moncaster@bt.com >>>>>> [mailto:toby.moncaster@bt.com] Sent: Wednesday, August 26, 2009 1:13 >>>>>> >>> PM >>> >>>>>> To: menth@informatik.uni-wuerzburg.de; Geib, Rüdiger >>>>>> Cc: bob@homefarmparham.co.uk; pcn@ietf.org >>>>>> Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART >>>>>> Review ofdraft-ietf-pcn-baseline-encoding-05 >>>>>> >>>>>> So would the following sound better? : >>>>>> >>>>>> Pre-Congestion Notification (PCN) is a >>>>>> metering and marking scheme that protects >>>>>> the quality of service (QoS) of inelastic >>>>>> flows within a Diffserv domain. The >>>>>> overall rate of the traffic is metered on >>>>>> every link in the domain, and packets are appropriately marked >>>>>> >>> when certain >>> >>>>>> configured rates are exceeded. Boundary nodes can measure the >>>>>> >>> level >>> >>>>>> of marking and thus make decisions about whether to admit or >>>>>> >>> block a >>> >>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>> terminate some of the existing flows, thereby protecting the QoS >>>>>> >>> of >>> >>>>>> previously admitted flows. This document specifies how such >>>>>> >>> marks >>> >>>>>> are encoded into the IP header by re-using the Explicit >>>>>> >>> Congestion >>> >>>>>> Notification (ECN) codepoints within this controlled domain. >>>>>> >>> The >>> >>>>>> baseline encoding described here provides for only two PCN >>>>>> >>> encoding >>> >>>>>> states, Not-marked and PCN-marked. >>>>>> >>>>>> Just for clarity here was the earlier version I proposed: >>>>>> >>>>>> The objective of Pre-Congestion Notification (PCN) is to protect >>>>>> >>> the >>> >>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>> >>> domain. >>> >>>>>> The overall rate of the traffic is metered on every link in the >>>>>> domain, and packets are appropriately marked when certain >>>>>> configured rates are exceeded. Boundary nodes can measure the >>>>>> >>> level >>> >>>>>> of marking and thus make decisions about whether to admit or >>>>>> >>> block a >>> >>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>> terminate some of the existing flows, thereby protecting the QoS >>>>>> >>> of >>> >>>>>> previously admitted flows. This document specifies how such >>>>>> >>> marks >>> >>>>>> are encoded into the IP header by re-using the Explicit >>>>>> >>> Congestion >>> >>>>>> Notification (ECN) codepoints within this controlled domain. >>>>>> >>> The >>> >>>>>> baseline encoding described here provides for only two PCN >>>>>> >>> encoding >>> >>>>>> states, Not-marked and PCN-marked. >>>>>> >>>>>> I personally disagree with Tom's suggestion to >>>>>> add PCN to all the defined terms (e.g. PCN >>>>>> flow, PCN traffic) - that is fine within the >>>>>> body of the document but in this abstract we >>>>>> should avoid using any terms that readers >>>>>> won't be already familiar with. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>>>>> Sent: 26 August 2009 08:46 >>>>>>> To: Ruediger.Geib@telekom.de >>>>>>> Cc: bob@homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn@ietf.org >>>>>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>>>>> baseline-encoding-05 >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Rüdiger touches an issue that I also feel is not optimally solved >>>>>>> >>> in >>> >>>>>>> the >>>>>>> current abstract. The objective of PCN is provide marking >>>>>>> >>> information >>> >>>>>>> to >>>>>>> egress node and the objective of admission control and flow >>>>>>> >>> termination >>> >>>>>>> is to protect QoS. I use the following short explanation for PCN. >>>>>>> >>> Maybe >>> >>>>>>> this idea could be added to the current abstract. >>>>>>> >>>>>>> Pre-congestion notification (PCN) is a metering and marking scheme >>>>>>> >>> for >>> >>>>>>> Differentiated Services (DiffServ) IP networks which provides >>>>>>> >>> egress >>> >>>>>>> nodes with information about load conditions inside the network >>>>>>> \cite{RFC5559}. This information is used for admission control and >>>>>>> >>> flow >>> >>>>>>> termination to support quality of service (QoS) for admitted >>>>>>> >>> inelastic >>> >>>>>>> realtime flows that are carried with prioritization within the >>>>>>> >>> DiffServ >>> >>>>>>> domain. >>>>>>> This document specifies how nodes encode the marking information in >>>>>>> >>> the >>> >>>>>>> IP header by re-using the Explicit Congestion Notification (ECN) >>>>>>> codepoints within a controlled DiffServ domain. The baseline >>>>>>> >>> encoding >>> >>>>>>> described here provides for only two PCN encoding states which are >>>>>>> not-marked and PCN-marked. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> Ruediger.Geib@telekom.de schrieb: >>>>>>> >>>>>>> >>>>>>>> Toby, Bob >>>>>>>> >>>>>>>> if the abstract is to mention PCN functionalities not defined >>>>>>>> >>> within >>> >>>>>>>> this document in a rather simplified way, would the purpose of PCN >>>>>>>> be to enable a Diffserv domain to support measurement based >>>>>>>> admission control as defined by PCN architecture? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ruediger >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>>>>>>> >>> Of >>> >>>>>>> Bob Briscoe >>>>>>> >>>>>>> >>>>>>>> Sent: Tuesday, August 25, 2009 8:42 PM >>>>>>>> To: toby.moncaster@bt.com; pcn@ietf.org >>>>>>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn- >>>>>>>> >>>>>>>> >>>>>>> baseline-encoding-05 >>>>>>> >>>>>>> >>>>>>>> Toby, >>>>>>>> >>>>>>>> I think this isn't just good for a casual reader, but it is >>>>>>>> >>> actually >>> >>>>>>>> still correct and doesn't require defining PC-domain (which is >>>>>>>> >>> just >>> >>>>>>>> the Diffserv domain once the described measures - the PDB - have >>>>>>>> >>> been >>> >>>>>>>> put in place). >>>>>>>> >>>>>>>> >>>>>>>> Bob >>>>>>>> >>>>>>>> At 15:53 25/08/2009, toby.moncaster@bt.com wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> This potentially raises an issue for all future PCN documents >>>>>>>>> >>> since >>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>>> abstract was based on our agreed standard elevator-pitch >>>>>>>>> >>>>>>>>> >>>>>>> introduction to >>>>>>> >>>>>>> >>>>>>>>> PCN... Specifically Spencer raises the question of using the >>>>>>>>> >>> defined >>> >>>>>>>>> term PCN-domain in the abstract. Any thoughts from anyone as to >>>>>>>>> >>>>>>>>> >>>>>>> whether >>>>>>> >>>>>>> >>>>>>>>> this is confusing? Would it be clearer to just use "domain" (e.g. >>>>>>>>> >>>>>>>>> >>>>>>> drop >>>>>>> >>>>>>> >>>>>>>>> the "PCN-"). In which case should I alter the whole abstract as >>>>>>>>> >>>>>>>>> >>>>>>> follows >>>>>>> >>>>>>> >>>>>>>>> (note: I realise this is strictly incorrect as it now doesn't >>>>>>>>> >>> seek >>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>>>> distinguish the non-PCN and PCN traffic from each other but is >>>>>>>>> >>> this >>> >>>>>>>>> clearer for a casual reader?): >>>>>>>>> >>>>>>>>> The objective of Pre-Congestion Notification (PCN) is to >>>>>>>>> >>> protect >>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>>> quality of service (QoS) of inelastic flows within a Diffserv >>>>>>>>> >>>>>>>>> >>>>>>> domain. >>>>>>> >>>>>>> >>>>>>>>> The overall rate of the traffic is metered on every link in >>>>>>>>> >>> the >>> >>>>>>>>> domain, and packets are appropriately marked when certain >>>>>>>>> configured rates are exceeded. Boundary nodes can measure >>>>>>>>> >>> the >>> >>>>>>> level >>>>>>> >>>>>>> >>>>>>>>> of marking and thus make decisions about whether to admit or >>>>>>>>> >>>>>>>>> >>>>>>> block a >>>>>>> >>>>>>> >>>>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>>>> terminate some of the existing flows, thereby protecting the >>>>>>>>> >>> QoS >>> >>>>>>> of >>>>>>> >>>>>>> >>>>>>>>> previously admitted flows. This document specifies how such >>>>>>>>> >>>>>>>>> >>>>>>> marks >>>>>>> >>>>>>> >>>>>>>>> are encoded into the IP header by re-using the Explicit >>>>>>>>> >>>>>>>>> >>>>>>> Congestion >>>>>>> >>>>>>> >>>>>>>>> Notification (ECN) codepoints within this controlled domain. >>>>>>>>> >>> The >>> >>>>>>>>> baseline encoding described here provides for only two PCN >>>>>>>>> >>>>>>>>> >>>>>>> encoding >>>>>>> >>>>>>> >>>>>>>>> states, Not-marked and PCN-marked. >>>>>>>>> >>>>>>>>> Toby >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>>>>>> >>> Behalf >>> >>>>>>> Of >>>>>>> >>>>>>> >>>>>>>>>> Lars Eggert >>>>>>>>>> Sent: 25 August 2009 15:12 >>>>>>>>>> To: pcn@ietf.org >>>>>>>>>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> ofdraft-ietf-pcn-baseline- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> encoding-05 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Begin forwarded message: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> From: Spencer Dawkins >>>>>>>>>>> Date: August 25, 2009 14:47:49 GMT+02:00 >>>>>>>>>>> To: "draft-ietf-pcn-baseline-encoding@tools.ietf.org" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> pcn-baseline-encoding@tools.ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cc: General Area Review Team , >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> "ietf@ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> " >>>>>>>>>>> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- >>>>>>>>>>> encoding-05 >>>>>>>>>>> >>>>>>>>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>>>>>>>> reviewer for this draft (for background on Gen-ART, please see >>>>>>>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>>>>>>> >>>>>>>>>>> Please wait for direction from your document shepherd or AD >>>>>>>>>>> >>> before >>> >>>>>>>>>>> posting a new version of the draft. >>>>>>>>>>> >>>>>>>>>>> Document: draft-ietf-pcn-baseline-encoding-05 >>>>>>>>>>> Reviewer: Spencer Dawkins >>>>>>>>>>> IETF LC End Date: 2009-09-03 >>>>>>>>>>> Review Date: 2009-08-21 >>>>>>>>>>> IESG Telechat date: (not known) >>>>>>>>>>> >>>>>>>>>>> Summary: this specification is almost ready for publication as >>>>>>>>>>> >>> a >>> >>>>>>>>>>> Proposed Standard. I have one minor question below (flagged as >>>>>>>>>>> "Spencer (minor)"), along with some editorial suggestions to be >>>>>>>>>>> considered when this document is edited (either in the working >>>>>>>>>>> >>>>>>>>>>> >>>>>>> group >>>>>>> >>>>>>> >>>>>>>>>>> or by the RFC Editor). >>>>>>>>>>> >>>>>>>>>>> Abstract >>>>>>>>>>> >>>>>>>>>>> The objective of Pre-Congestion Notification (PCN) is to >>>>>>>>>>> >>> protect >>> >>>>>>>>>>> >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> quality of service (QoS) of inelastic flows within a >>>>>>>>>>> >>> Diffserv >>> >>>>>>>>>>> domain. >>>>>>>>>>> >>>>>>>>>>> Spencer (clarity): I'm not sure what the relationship between a >>>>>>>>>>> Diffserv domain and a PCN-domain is - this couuld be clearer, >>>>>>>>>>> especially in an Abstract. I note that RFC 5559 doesn't use the >>>>>>>>>>> >>>>>>>>>>> >>>>>>> term >>>>>>> >>>>>>> >>>>>>>>>>> PCN-domain in its Abstract ... I can guess, but I'm just >>>>>>>>>>> >>> guessing. >>> >>>>>>>>>>> The overall rate of the PCN-traffic is metered on every link >>>>>>>>>>> >>> in >>> >>>>>>>>>>> >>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> PCN-domain, and PCN-packets are appropriately marked when >>>>>>>>>>> >>>>>>>>>>> >>>>>>> certain >>>>>>> >>>>>>> >>>>>>>>>>> configured rates are exceeded. The level of marking allows >>>>>>>>>>> >>> the >>> >>>>>>>>>>> boundary nodes to make decisions about whether to admit or >>>>>>>>>>> >>> block >>> >>>>>>> a >>>>>>> >>>>>>> >>>>>>>>>>> new flow request, and (in abnormal circumstances) whether to >>>>>>>>>>> terminate some of the existing flows, thereby protecting the >>>>>>>>>>> >>> QoS >>> >>>>>>>>>>> >>>>>>>>> of >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> previously admitted flows. This document specifies how such >>>>>>>>>>> >>>>>>>>>>> >>>>>>> marks >>>>>>> >>>>>>> >>>>>>>>>>> are to be encoded into the IP header by re-using the >>>>>>>>>>> >>> Explicit >>> >>>>>>>>>>> Congestion Notification (ECN) codepoints within this >>>>>>>>>>> >>> controlled >>> >>>>>>>>>>> domain. The baseline encoding described here provides for >>>>>>>>>>> >>> only >>> >>>>>>>>>>> >>>>>>>>> two >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> PCN encoding states, Not-marked and PCN-marked. >>>>>>>>>>> >>>>>>>>>>> 4. Encoding two PCN States in IP >>>>>>>>>>> >>>>>>>>>>> The following rules apply to all PCN traffic: >>>>>>>>>>> >>>>>>>>>>> o PCN-traffic MUST be marked with a PCN-compatible Diffserv >>>>>>>>>>> Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD >>>>>>>>>>> >>> be >>> >>>>>>>>>>> chosen that are already defined for use with admission >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> controlled >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> traffic. Appendix A.1 gives guidance to implementiors on >>>>>>>>>>> suitable >>>>>>>>>>> >>>>>>>>>>> Spencer (clarity): s/implementiors/implementers/? >>>>>>>>>>> >>>>>>>>>>> DSCPs. Guidelines for mixing traffic-types within a PCN- >>>>>>>>>>> >>>>>>>>>>> >>>>>>> domain >>>>>>> >>>>>>> >>>>>>>>>>> are given in [I-D.ietf-pcn-marking-behaviour]. >>>>>>>>>>> >>>>>>>>>>> o Any packet that is not-PCN but which shares the same >>>>>>>>>>> >>> Diffserv >>> >>>>>>>>>>> codepoint as PCN-enabled traffic MUST have the ECN field >>>>>>>>>>> >>> of >>> >>>>>>> its >>>>>>> >>>>>>> >>>>>>>>>>> outermost IP header equal to 00. >>>>>>>>>>> >>>>>>>>>>> Spencer (minor): this is the only point in the specification >>>>>>>>>>> >>> (that >>> >>>>>>> I >>>>>>> >>>>>>> >>>>>>>>>>> can >>>>>>>>>>> find) that makes reference to the "outermost IP header". I'm >>>>>>>>>>> >>> not >>> >>>>>>>>>>> >>>>>>>>> sure >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> whether to suggest s/outermost// here or to ask that a >>>>>>>>>>> >>> statement >>> >>>>>>> be >>>>>>> >>>>>>> >>>>>>>>>>> added earlier in the document to clearly state that PCN >>>>>>>>>>> >>> encoding >>> >>>>>>>>>>> >>>>>>>>> only >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> protects inelastic traffic when it's used for the outermost IP >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> header, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> but the current text seems to call attention to this in a way >>>>>>>>>>> >>> that >>> >>>>>>>>>>> makes the reader wonder what is special about THIS requirement >>>>>>>>>>> >>>>>>>>>>> >>>>>>> that >>>>>>> >>>>>>> >>>>>>>>>>> isn't true of the other requirements listed. >>>>>>>>>>> >>>>>>>>>>> 4.3. PCN-Compatible Diffserv Codepoints >>>>>>>>>>> >>>>>>>>>>> Enabling PCN marking behaviour for a specific DSCP disables >>>>>>>>>>> >>> any >>> >>>>>>>>>>> other >>>>>>>>>>> marking behaviour (e.g. enabling PCN disables the default >>>>>>>>>>> >>> ECN >>> >>>>>>>>>>> marking >>>>>>>>>>> behaviour introduced in [RFC3168]). All traffic metering >>>>>>>>>>> >>> and >>> >>>>>>>>>>> marking >>>>>>>>>>> >>>>>>>>>>> Spencer (clarity): here, and in Section 6, the text uses >>>>>>>>>>> >>>>>>>>>>> >>>>>>> "disables" >>>>>>> >>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> describe the relationship between PCN and ECN. If I understand >>>>>>>>>>> >>> the >>> >>>>>>>>>>> point, the domain is substituting one behavior for another. I >>>>>>>>>>> >>>>>>>>>>> >>>>>>> might >>>>>>> >>>>>>> >>>>>>>>>>> suggest "replaces" to describe the relationship in both >>>>>>>>>>> >>> locations. >>> >>>>>>>>>>> behaviours are discussed in [I-D.ietf-pcn-marking- >>>>>>>>>>> >>> behaviour]. >>> >>>>>>>>>>> >>>>>>>>> This >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> ensures compliance with the BCP guidance set out in >>>>>>>>>>> >>> [RFC4774]. >>> >>>>>>>>>>> 4.3.1. Co-existence of PCN and not-PCN traffic >>>>>>>>>>> >>>>>>>>>>> The scarcity of pool 1 DSCPs coupled with the fact that PCN >>>>>>>>>>> >>> is >>> >>>>>>>>>>> envisaged as a marking behaviour that could be applied to a >>>>>>>>>>> >>>>>>>>>>> >>>>>>> number >>>>>>> >>>>>>> >>>>>>>>>>> of >>>>>>>>>>> different DSCPs makes it essential that we provide a not-PCN >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> state. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> As stated above (and expanded in Appendix A.1) the aim is >>>>>>>>>>> >>> for >>> >>>>>>> PCN >>>>>>> >>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> re-use existing DSCPs. Because PCN re-defines the meaning >>>>>>>>>>> >>> of >>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>>>>> ECN >>>>>>>>>>> >>>>>>>>>>> Spencer (clarity): here, the text uses "re-defines", which I >>>>>>>>>>> >>> like >>> >>>>>>>>>>> better than "disables", but if you go for "replaces" previously >>>>>>>>>>> >>>>>>>>>>> >>>>>>> and >>>>>>> >>>>>>> >>>>>>>>>> in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> section 6, you might want to use the same wording here. >>>>>>>>>>> >>>>>>>>>>> field for such DSCPs it is important to allow an operator to >>>>>>>>>>> >>>>>>>>>>> >>>>>>> still >>>>>>> >>>>>>> >>>>>>>>>>> use the DSCP for traffic that isn't PCN-enabled. This is >>>>>>>>>>> >>>>>>>>>>> >>>>>>> achieved >>>>>>> >>>>>>> >>>>>>>>>>> by >>>>>>>>>>> providing a not-PCN state within the encoding scheme. >>>>>>>>>>> >>>>>>>>>>> A.1. Choice of Suitable DSCPs >>>>>>>>>>> >>>>>>>>>>> The PCN Working Group chose not to define a single DSCP for >>>>>>>>>>> >>> use >>> >>>>>>>>>>> >>>>>>>>>> with >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> PCN for several reasons. Firstly the PCN mechanism is >>>>>>>>>>> >>>>>>>>>>> >>>>>>> applicable >>>>>>> >>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> a variety of different traffic classes. Secondly standards >>>>>>>>>>> >>>>>>>>>>> >>>>>>> track >>>>>>> >>>>>>> >>>>>>>>>>> DSCPs are in increasingly short supply. Thirdly PCN should >>>>>>>>>>> >>> be >>> >>>>>>>>>>> >>>>>>>>> seen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> as being essentially a marking behaviour similar to ECN but >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> intended >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> for inelastic traffic. The choice of which DSCP is most >>>>>>>>>>> >>>>>>>>>>> >>>>>>> suitable >>>>>>> >>>>>>> >>>>>>>>>>> for >>>>>>>>>>> a given PCN-domain is dependent on the nature of the traffic >>>>>>>>>>> entering >>>>>>>>>>> that domain and the link rates of all the links making up >>>>>>>>>>> >>> that >>> >>>>>>>>>>> domain. In PCN-domains with uniformly high link rates, the >>>>>>>>>>> appropriate DSCPs would currently be those for the Real Time >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Traffic >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Class [RFC5127]. To be clear the PCN Working Group >>>>>>>>>>> >>> recommends >>> >>>>>>>>>>> >>>>>>>>>> using >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Spencer (clarity): is this 2119 language (apparently not, since >>>>>>>>>>> >>>>>>>>>>> >>>>>>> this >>>>>>> >>>>>>> >>>>>>>>>>> section is not normative), or are you saying "suggests"? My >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> suggestion >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> is that we not use 2119 language, even lowercased, except for >>>>>>>>>>> normative text - this seems to cause confusion from time to >>>>>>>>>>> >>> time. >>> >>>>>>>>>>> >>>>>>>>> But >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> please check with your shepherding AD to see if he agrees. >>>>>>>>>>> >>>>>>>>>>> admission control for the following service classes: >>>>>>>>>>> >>>>>>>>>>> o Telephony (EF) >>>>>>>>>>> >>>>>>>>>>> o Real-time interactive (CS4) >>>>>>>>>>> >>>>>>>>>>> o Broadcast Video (CS3) >>>>>>>>>>> >>>>>>>>>>> o Multimedia Conferencing (AF4) >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Gen-art mailing list >>>>>>>>>>> Gen-art@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> PCN mailing list >>>>>>>>> PCN@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> PCN mailing list >>>>>>>> PCN@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>>>>> _______________________________________________ >>>>>>>> PCN mailing list >>>>>>>> PCN@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/pcn >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>>> >>>>> -- >>>>> 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 Sat Aug 29 13:57: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 9E2063A6BD5 for ; Sat, 29 Aug 2009 13:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.879, 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 2rfq0yYdZojI for ; Sat, 29 Aug 2009 13:57:03 -0700 (PDT) Received: from smtp130.rog.mail.re2.yahoo.com (smtp130.rog.mail.re2.yahoo.com [206.190.53.35]) by core3.amsl.com (Postfix) with SMTP id 8A7513A69C7 for ; Sat, 29 Aug 2009 13:57:03 -0700 (PDT) Received: (qmail 12630 invoked from network); 29 Aug 2009 20:57:08 -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=EPs+4r/hTIvRyMfK2dLr6lZR2GM3Vab/xzcxtayjnC64hGTYxZhKFw/zfNs6GqzKMGKvpnk45hrb2V5eFVCP7/CSMacwHRJSPdfA2q32gX2JONAq6Hzh4DdV4TCUD2bsabIBNK2qGJa7F0NVuzNzhRZABaFxurVqjrOeeR5EK8g= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp130.rog.mail.re2.yahoo.com with SMTP; 29 Aug 2009 20:57:08 -0000 X-YMail-OSG: vzZvA20VM1nOvkxL1SbIx.sjgyjMqxvMSyi3UHkVDd1HvhW2L7epgEzTmqDJgnPtow-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A999621.603@rogers.com> Date: Sat, 29 Aug 2009 16:57:05 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <151C164FE2E066418D8D44D0801543A50198554A@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A50198554A@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] SM Edge Behaviour Draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 20:57:04 -0000 It's time I responded to your comments. It will be a warm-up for revising the draft. Thank you very much for your review. Responses marked with [PTT]. Ruediger.Geib@telekom.de wrote: > Tom, > > thanks for your work. The draft is clearer than the first version. I > still miss details how to measure an IEA. That the "howto" is an > issue isn't even mentioned in the draft. [PTT] We discussed this in Stockholm. The answer to how to classify packets really depends on the specific deployment. It could be a matter of tunnels, LSPs, or 5-tuples matched against routing information. Our conclusion was that the issue really should have been discussed in the architecture document, but the next-best alternative may be the signalling requirements document. Re-thinking that conclusion after a couple of months, I guess we really are talking about edge behaviour, so it is a proper topic for the edge behaviour documents. > > Regards, > > Ruediger > > > Some comments: > > 1.1 terminology and following cahpters > > A new PCN node called "Policy Decision Point" is added to the architecture. > The document does not explain where it is located and by which interfaces > and priotocols it communicates. The draft text however seems to make this > PDP mandatory in some instances. > > My personal take: remove the "Policy Decision Point" and all references to > it from this draft and write an experimental architecture draft explaining > the concept. > [PTT] The terminology was used because I thought it would be familiar. Perhaps I should revert to the "decision node" terminology used in the earlier version of this document. I do see your point about a separate architecture draft, but we already have some support for the concept of a central control node in RFC 5559. I was hoping we could keep it in view in the edge behaviour drafts. > ----------------- > > 3.1 Overview > > 2nd section: ..."measured rate of flow of unmarked..." > replace by "..measured rate of unmarked.." > [PTT] OK. > ----------------- > > 3.2.1 PCN Egress Node Role in flow admission > > new_CLE is the value of old_CLE during the next iteration, but the text > doesn't state that. As you never know what an implementor understands > from this text, the formula may be changed or text added. > [PTT] OK. > "k" should be from 0 < k < 1. The text should state that. > [PTT] OK. > Typo: Replace old-CLE/new-CLE by old_CLE/new_CLE > [PTT] OK. > ------------------ > > 3.4 Possible Extensions to the basic algorithm > > End of first section: "....is low (< 50 flows). " > > If this holds independent of the flow size, leave as is. If it makes a > difference whether these are voice calls or HD video streams, please > explain "50 flows" in sufficient detail. > [PTT] I'll consult with my co-authors. > ------------------- > > 4.7 Environmental Concerns > > Please change the 2nd sentence > > If the mechanism flow termination can't be enabled, signaling the > corresponding state may be used to reduce traffic by other means > like codec adaptation or the drop of low priority video frames. > This is however out of scope of the PCN WG. > [PTT] I'll review. I have the feeling someone else commented on this, and when I get to that comment I'll have a better idea what to do. > ------------------- > > 4.8 and 5. Security Considerations > > Delete one section. [PTT] OK. > > > > > > >