From psamp-bounces@ietf.org Wed Jul 2 00:47:06 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14653A6B59; Wed, 2 Jul 2008 00:47:06 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B593A6B65 for ; Wed, 2 Jul 2008 00:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 JsYWiPM4JfoX for ; Wed, 2 Jul 2008 00:47:05 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0C0763A6B36 for ; Wed, 2 Jul 2008 00:47:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id CDF4E2C000351 for ; Wed, 2 Jul 2008 09:47:14 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhgIb+Yknx9n for ; Wed, 2 Jul 2008 09:47:14 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id AF6AE2C000304 for ; Wed, 2 Jul 2008 09:47:09 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Jul 2008 07:47:06 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 02 Jul 2008 09:46:49 +0200 From: Juergen Quittek To: IETF PSAMP Working Group Message-ID: Thread-Topic: float64 needed for samplingProbability Thread-Index: AcjcF8i57Z3XCZw3lkywvxeD8/XZ7A== Mime-version: 1.0 Subject: [PSAMP] float64 needed for samplingProbability X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Dear all, Dan's AD review identified a set of issues to be solved in PSAMP-INFO. Most of them can be dealt with by the authors, but there is one for which input from others is needed: Dan asked why we use float64 as data type for Information Element samplingProbability (#311, section 8.2.11): > T4. Section 8.2.11 - why is Abstract Data type float64 needed? It looks > to me like float32 would be enough to express a probability value, or am > I missing something? Can anyone give us a good reason for using float64 instead of the smaller float32? Thanks, Juergen -- Juergen Quittek quittek@nw.neclab.eu Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England 2832014 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Thu Jul 10 11:15:05 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5194828C122; Thu, 10 Jul 2008 11:15:05 -0700 (PDT) X-Original-To: psamp@ietf.org Delivered-To: psamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E07BC3A6A3E; Thu, 10 Jul 2008 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080710181501.E07BC3A6A3E@core3.amsl.com> Date: Thu, 10 Jul 2008 11:15:01 -0700 (PDT) Cc: psamp@ietf.org Subject: [PSAMP] I-D ACTION:draft-ietf-psamp-sample-tech-11.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Packet Sampling Working Group of the IETF. Title : Sampling and Filtering Techniques for IP Packet Selection Author(s) : T. Zseby Filename : draft-ietf-psamp-sample-tech-11.txt Pages : 47 Date : 2008-7-10 This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-psamp-sample-tech-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-10110702.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --NextPart-- From psamp-bounces@ietf.org Mon Jul 14 02:15:03 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1555E28C234; Mon, 14 Jul 2008 02:15:03 -0700 (PDT) X-Original-To: psamp@ietf.org Delivered-To: psamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 33A8028C228; Mon, 14 Jul 2008 02:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714091501.33A8028C228@core3.amsl.com> Date: Mon, 14 Jul 2008 02:15:01 -0700 (PDT) Cc: psamp@ietf.org Subject: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Packet Sampling Working Group of the IETF. Title : Information Model for Packet Sampling Exports Author(s) : T. Dietz, et al. Filename : draft-ietf-psamp-info-09.txt Pages : 52 Date : 2008-07-14 This memo defines an information model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IPFIX protocol, this information model is an extension to the IPFIX information model.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-psamp-info-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14020032.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --NextPart-- From psamp-bounces@ietf.org Mon Jul 14 02:28:23 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7359A28C132; Mon, 14 Jul 2008 02:28:23 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0E328C140 for ; Mon, 14 Jul 2008 02:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQX0cjwLTgfE for ; Mon, 14 Jul 2008 02:28:21 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 935A828C250 for ; Mon, 14 Jul 2008 02:27:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A60732C000304; Mon, 14 Jul 2008 11:27:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQqMSfBXoKCu; Mon, 14 Jul 2008 11:27:27 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 74F812C0004E2; Mon, 14 Jul 2008 11:27:17 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 Jul 2008 11:27:16 +0200 Message-ID: <547F018265F92642B577B986577D671C1AD14A@VENUS.office> In-Reply-To: <20080714091501.33A8028C228@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt Thread-Index: AcjlkjRfs48froh/Rzuw1B2hoQ3gJAAAGv7Q References: <20080714091501.33A8028C228@core3.amsl.com> From: "Thomas Dietz" To: , Subject: Re: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0905274111==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============0905274111== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0117_01C8E5A4.921E36B0" This is a multipart message in MIME format. ------=_NextPart_000_0117_01C8E5A4.921E36B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all, Hello Dan, as you may have noticed a new version of the Info Model is out. Dan, I hope we have addressed all your issues. Currently there are 2 open points under discussion * dataLinkFrameSize - usage and meaning of this element is unclear * padding - usage of padding for the ...Section elements We hope to solve these issues at the IETF meeting in Dublin. Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Montag, 14. Juli 2008 11:15 > To: i-d-announce@ietf.org > Cc: psamp@ietf.org > Subject: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Packet Sampling Working Group of the > IETF. > > > Title : Information Model for Packet Sampling Exports > Author(s) : T. Dietz, et al. > Filename : draft-ietf-psamp-info-09.txt > Pages : 52 > Date : 2008-07-14 > > This memo defines an information model for the Packet Sampling > (PSAMP) protocol. It is used by the PSAMP protocol for encoding > sampled packet data and information related to the Sampling process. > As the PSAMP protocol is based on the IPFIX protocol, this > information model is an extension to the IPFIX information > model.Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_0117_01C8E5A4.921E36B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCAuowggLmAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwNzE0MDkyNzE2WjAjBgkqhkiG9w0BCQQxFgQU7CacBC7pqwMn1sawcDrpoZff mcwwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBoBgsqhkiG 9w0BCRACCzFZoFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYBXbdHxusr96pPCCL1gYTEP26SmP0lUKVVVdsTOM6YQASmDo+I0e+Tl /2g7CpmEYSfqDtreEoAXhHpaivEi6HN1d7klswXIQAwo36hY3xJDH6Yo7i8opiexaeAeMhF0TvKH mjnKo5ivC9He7h8sHQaWmkkfx9FORngN912EZxiQCAAAAAAAAA== ------=_NextPart_000_0117_01C8E5A4.921E36B0-- --===============0905274111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0905274111==-- From psamp-bounces@ietf.org Mon Jul 14 03:08:28 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7536B28C147; Mon, 14 Jul 2008 03:08:28 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342BE28C147 for ; Mon, 14 Jul 2008 03:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 lDMq2Ts+qcaB for ; Mon, 14 Jul 2008 03:08:26 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B543D3A6896 for ; Mon, 14 Jul 2008 03:08:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,358,1212379200"; d="scan'208";a="114619447" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jul 2008 06:06:49 -0400 X-IronPort-AV: E=Sophos;i="4.30,358,1212379200"; d="scan'208";a="228214967" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Jul 2008 06:06:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 12:05:43 +0200 Message-ID: In-Reply-To: <547F018265F92642B577B986577D671C1AD14A@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt Thread-Index: AcjlkjRfs48froh/Rzuw1B2hoQ3gJAAAGv7QAAGcEfA= References: <20080714091501.33A8028C228@core3.amsl.com> <547F018265F92642B577B986577D671C1AD14A@VENUS.office> From: "Romascanu, Dan (Dan)" To: "Thomas Dietz" , Subject: Re: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Thanks for the update. I am waiting for further updates before proceeding to IETF LC. Dan > -----Original Message----- > From: Thomas Dietz [mailto:Thomas.Dietz@nw.neclab.eu] > Sent: Monday, July 14, 2008 12:27 PM > To: psamp@ietf.org; Romascanu, Dan (Dan) > Subject: RE: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt > > Hi all, Hello Dan, > > as you may have noticed a new version of the Info Model is out. > > Dan, I hope we have addressed all your issues. Currently > there are 2 open points under discussion > > * dataLinkFrameSize - usage and meaning of this element is unclear > * padding - usage of padding for the ...Section elements > > We hope to solve these issues at the IETF meeting in Dublin. > > Best Regards, > > Thomas > > -- > Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu > NEC Europe Ltd. Phone: +49 6221 4342-128 > NEC Laboratories Europe Fax: +49 6221 4342-155 > Network Research Division > Kurfuersten-Anlage 36 > 69115 Heidelberg, Germany http://www.nw.neclab.eu > > NEC Europe Limited Registered in England 2832014 > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > > > -----Original Message----- > > From: psamp-bounces@ietf.org > [mailto:psamp-bounces@ietf.org] On Behalf > > Of Internet-Drafts@ietf.org > > Sent: Montag, 14. Juli 2008 11:15 > > To: i-d-announce@ietf.org > > Cc: psamp@ietf.org > > Subject: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Packet Sampling Working > Group of the > > IETF. > > > > > > Title : Information Model for Packet Sampling Exports > > Author(s) : T. Dietz, et al. > > Filename : draft-ietf-psamp-info-09.txt > > Pages : 52 > > Date : 2008-07-14 > > > > This memo defines an information model for the Packet Sampling > > (PSAMP) protocol. It is used by the PSAMP protocol for encoding > > sampled packet data and information related to the Sampling process. > > As the PSAMP protocol is based on the IPFIX protocol, this > information > > model is an extension to the IPFIX information > model.Conventions used > > in this document > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-09.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Jul 14 03:40:01 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1356D3A68B4; Mon, 14 Jul 2008 03:40:01 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192343A68B4 for ; Mon, 14 Jul 2008 03:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocW3ZOmh2slP for ; Mon, 14 Jul 2008 03:39:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B3EF13A67A7 for ; Mon, 14 Jul 2008 03:39:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,359,1212364800"; d="scan'208";a="14273790" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2008 10:40:21 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6EAeLrc021651; Mon, 14 Jul 2008 12:40:21 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EAeLMu029528; Mon, 14 Jul 2008 10:40:21 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6EAeLJ13765; Mon, 14 Jul 2008 11:40:21 +0100 (BST) Message-ID: <487B2D14.9080301@cisco.com> Date: Mon, 14 Jul 2008 11:40:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Thomas Dietz References: <20080714091501.33A8028C228@core3.amsl.com> <547F018265F92642B577B986577D671C1AD14A@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C1AD14A@VENUS.office> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=558; t=1216032021; x=1216896021; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20psamp-bounces@ietf.org] =20=20Re=3A=20[PSAMP]=20I-D=20Action=3Adraft-ietf-psamp-info -09.txt |Sender:=20; bh=gOzInJB0td6tTLC+5WbcWhBTshB1L6sA2jqYTtWI3aM=; b=Ugygd9pMwejI84joThlkEOV4GFh3wbIGVgqDQ51/gr4VFRdaw42Vl4x5Az ARmtM8Pyr9LHNywAgkBkIPMTsLMTB5k62BDfss9BXGI6loSrzZSPKc9iMPe6 M8jjKDcvgR; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: psamp@ietf.org Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: I-D Action:draft-ietf-psamp-info-09.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Thomas, > Hi all, Hello Dan, > > as you may have noticed a new version of the Info Model is out. > > Dan, I hope we have addressed all your issues. Currently there are 2 open > points under discussion > > * dataLinkFrameSize - usage and meaning of this element is unclear > * padding - usage of padding for the ...Section elements Who are these under discussion with? P. > > We hope to solve these issues at the IETF meeting in Dublin. > > Best Regards, > > Thomas -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Jul 14 03:42:29 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A44D3A6995; Mon, 14 Jul 2008 03:42:29 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E316E28C140 for ; Mon, 14 Jul 2008 03:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWOMWALnRwJe for ; Mon, 14 Jul 2008 03:42:26 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1FC573A681E for ; Mon, 14 Jul 2008 03:42:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4808D2C000350; Mon, 14 Jul 2008 12:42:51 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDlHR3nI0bKL; Mon, 14 Jul 2008 12:42:51 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 10AFE2C000303; Mon, 14 Jul 2008 12:42:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 Jul 2008 12:42:34 +0200 Message-ID: <547F018265F92642B577B986577D671C1AD16D@VENUS.office> In-Reply-To: <487B2D14.9080301@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sender: psamp-bounces@ietf.org] Re: [PSAMP] I-D Action:draft-ietf-psamp-info-09.txt Thread-Index: AcjlngxRG/cIv+o8SzaGaxvvdO9jngAADGBw References: <20080714091501.33A8028C228@core3.amsl.com> <547F018265F92642B577B986577D671C1AD14A@VENUS.office> <487B2D14.9080301@cisco.com> From: "Thomas Dietz" To: "Paul Aitken" Cc: psamp@ietf.org Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: I-D Action:draft-ietf-psamp-info-09.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1141371788==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============1141371788== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0120_01C8E5AF.1712BA80" This is a multipart message in MIME format. ------=_NextPart_000_0120_01C8E5AF.1712BA80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Paul, You and Juergen are discussion those, aren't you?? Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Montag, 14. Juli 2008 12:40 > To: Thomas Dietz > Cc: psamp@ietf.org; dromasca@avaya.com > Subject: Re: [Sender: psamp-bounces@ietf.org] Re: [PSAMP] I-D > Action:draft-ietf-psamp-info-09.txt > > Thomas, > > > Hi all, Hello Dan, > > > > as you may have noticed a new version of the Info Model is out. > > > > Dan, I hope we have addressed all your issues. Currently there are 2 > open > > points under discussion > > > > * dataLinkFrameSize - usage and meaning of this element is unclear > > * padding - usage of padding for the ...Section elements > > Who are these under discussion with? > > P. > > > > > We hope to solve these issues at the IETF meeting in Dublin. > > > > Best Regards, > > > > Thomas > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. ------=_NextPart_000_0120_01C8E5AF.1712BA80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCAuowggLmAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwNzE0MTA0MjM0WjAjBgkqhkiG9w0BCQQxFgQUiAMBuoyPxqnnCCtdX7hNeOdo 1X4wZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBoBgsqhkiG 9w0BCRACCzFZoFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYBuNSTU6Z0g7TbzYRcVotFtCU7FOWqPp42cmdNzL8UmAvSx5T/DdYVo UcN/J88xzMwrYDShWbeappEYee9BYj7rFDtASk15gIAYsMNS7BsahVIu2fJSBvFVGsNHJxYLanLA kWhMUvUQmk4BDRw3NRafDI67mHF8nELoy4pw95C6ZQAAAAAAAA== ------=_NextPart_000_0120_01C8E5AF.1712BA80-- --===============1141371788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1141371788==-- From psamp-bounces@ietf.org Mon Jul 14 03:44:43 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E8628C258; Mon, 14 Jul 2008 03:44:43 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E71C28C258 for ; Mon, 14 Jul 2008 03:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH5Sbfyk891H for ; Mon, 14 Jul 2008 03:44:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 04BE228C158 for ; Mon, 14 Jul 2008 03:44:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,359,1212364800"; d="scan'208";a="14274439" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2008 10:45:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6EAj5I6020549; Mon, 14 Jul 2008 12:45:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EAj5SX001706; Mon, 14 Jul 2008 10:45:05 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6EAj4J14211; Mon, 14 Jul 2008 11:45:04 +0100 (BST) Message-ID: <487B2E30.1030608@cisco.com> Date: Mon, 14 Jul 2008 11:45:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Thomas Dietz References: <20080714091501.33A8028C228@core3.amsl.com> <547F018265F92642B577B986577D671C1AD14A@VENUS.office> <487B2D14.9080301@cisco.com> <547F018265F92642B577B986577D671C1AD16D@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C1AD16D@VENUS.office> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=146; t=1216032305; x=1216896305; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20psamp-bounces@ietf.org] =20=20Re=3A=20[PSAMP]=20I-D=20Action=3Adraft-ietf-psamp-info -09.txt |Sender:=20; bh=DYASAGWE+jNE0lYrLkY+fs9vyio0n9UOdVvgdSLXEXE=; b=BPAEH7GdOkPkYgIz1HYVMxt6MNrZwHTwDcdCzKLPcFuHL/hYv9CkuLNbit CIXo7kptMfP2mlBg04q+RuLjMvdjsz0XAzceEFkSsPysU3sUOsR9b4VOcIeL R2ikZGypDl; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: psamp@ietf.org Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: I-D Action:draft-ietf-psamp-info-09.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Thomas, > You and Juergen are discussion those, aren't you?? Not that I know. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Jul 14 22:41:43 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8CAB3A6B3E; Mon, 14 Jul 2008 22:41:43 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937523A693C for ; Mon, 14 Jul 2008 22:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS0wXxkQSuUL for ; Mon, 14 Jul 2008 22:41:41 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 04ECF3A6B34 for ; Mon, 14 Jul 2008 22:41:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 97AE32C000350 for ; Tue, 15 Jul 2008 07:42:07 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCzGXc09ICtw for ; Tue, 15 Jul 2008 07:42:07 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 772FA2C000304 for ; Tue, 15 Jul 2008 07:42:02 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Jul 2008 05:42:02 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 15 Jul 2008 07:39:54 +0200 From: Juergen Quittek To: IETF PSAMP Working Group Message-ID: Thread-Topic: PSAMP-INFO: padding of reported packet sections Thread-Index: AcjmPTUzK+r602aSLEK418mFqDJ1yg== Mime-version: 1.0 Subject: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Dear all, When discussing how to solve the issues raised by the AD review of draft-ietf-psamp-info the authors identified new issues with the encoding of sections of a raw packet. I try to summarize the first one in this email. Paul, please correct me if I misunderstood the points you made last week: Currently all Information Elements containing sections (chunks) of sampled packets (ipHeaderPacketSection, ipPayloadPacketSection, dataLinkFrameSection, mplsLabelStackSection, mplsPayloadPacketSection) contain a phrase in their description saying "The data for this field MUST NOT be padded." The obvious reason for this statement is that if you use padding within these sections, then a receiver of the IE might not be able to distinguish packet data from padding octets. However, there are also reasons for allowing padding, particularly if you do not want to use variable length encoding of packet sections. You may want to use fixed length encoding matching the sampling length you apply to the packet or to its payload. Then padding could be applied in case packets are shorter than the sampling length. In this case, the receiver of the section would also need further information such as the packet length, payload length, etc. in order to identify which octets belong to the packet and which are padding, but this information could be provided by further IEs that are already available from IPFIX-INFO. Do people in the WG think we should allow padding of reported packet sections within an IE or shall we rather stick with the current rule that section IEs MUST NOT be padded? Thanks, Juergen -- Juergen Quittek quittek@nw.neclab.eu Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England 2832014 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Jul 15 01:23:01 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794DF3A6B58; Tue, 15 Jul 2008 01:23:01 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4578628C123 for ; Tue, 15 Jul 2008 01:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJFbV+ol6cnn for ; Tue, 15 Jul 2008 01:22:59 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 393033A6B44 for ; Tue, 15 Jul 2008 01:22:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 20AF42C0004E2 for ; Tue, 15 Jul 2008 10:23:26 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGqoF2GPQuiM for ; Tue, 15 Jul 2008 10:23:26 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 019B22C00035D for ; Tue, 15 Jul 2008 10:23:21 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Jul 2008 08:22:58 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 15 Jul 2008 10:22:55 +0200 From: Juergen Quittek To: IETF PSAMP Working Group Message-ID: Thread-Topic: PSAMP-INFO: linkLayerFrame* IEs Thread-Index: AcjmPTUzK+r602aSLEK418mFqDJ1ygAFsXvF In-Reply-To: Mime-version: 1.0 Subject: [PSAMP] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Dear all, Here is another issue for PSAMP-INFO: In the current version of draft-ietf-psamp-info there are two Information Elements related to link layer frames: dataLinkFrameSize and dataLinkFrameSection. I would like to discuss whether it is of advantage to have generic dataLinkFrame* IEs rather than specific ones. A generic one is nice, if you are reporting different types of data link layer frames. But if you don't know which data link layer was present, interpretation of the IE becomes tricky. The most common case is probably an Ethernet frame. Also for 802.11 the concept of a frame is pretty clear. It gets more difficult if you use MPLS. What is then the data link frame? Or for 802.16 (WiMAX, where multiple packets for multiple receivers may be contained in a single frame (burst). Things would get much clearer is we used link layer-specific IEs instead of a dataLinkFrame* IEs, such as ethernetFrameSection, wlanFrameSection, wimaxBurstSection, etc. Any opinions on this issue? Thanks, Juergen -- Juergen Quittek quittek@nw.neclab.eu Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England 2832014 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Jul 15 05:17:03 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535E73A6956; Tue, 15 Jul 2008 05:17:03 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4AD43A6927 for ; Tue, 15 Jul 2008 05:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp5VyKoc+rlw for ; Tue, 15 Jul 2008 05:17:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 941613A69E8 for ; Tue, 15 Jul 2008 05:16:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,366,1212364800"; d="scan'208";a="14401527" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2008 12:16:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6FCGhY6009012; Tue, 15 Jul 2008 14:16:43 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6FCGhTt014712; Tue, 15 Jul 2008 12:16:43 GMT Received: from [10.61.64.46] (ams3-vpn-dhcp46.cisco.com [10.61.64.46]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6FCGbE04962; Tue, 15 Jul 2008 13:16:37 +0100 (BST) Message-ID: <487C9525.7020103@cisco.com> Date: Tue, 15 Jul 2008 13:16:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=830; t=1216124203; x=1216988203; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20psamp-bounces@ietf.org] =20=20[PSAMP]=20PSAMP-INFO=3A=20padding=0A=20of=20reported=2 0packet=20sections |Sender:=20; bh=fFcsOickvdpazkPOlSFC4un4GSScFo7thhJOCI34Saw=; b=hvIbsJfWaiRGNSS+o3WTin7NaNrkf4eZi2V0pXyAlmqoH5CGZyNyr2hFS6 vTnY659P7/hTQuQYMIu04r2qLeh7jEkebp6fZ/YA2nMknBUxayZCsNOWu2KV w380veCH0Q; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Juergen, > Do people in the WG think we should allow padding of reported > packet sections within an IE or shall we rather stick with the > current rule that section IEs MUST NOT be padded? If packet sections must not be padded then either: 1. we mandate that variable length encoding MUST be used, or 2. we accept that templates may be consumed at an alarming rate to cope with the various different sized packet sections. Indeed, templates may be exhausted exponentially when multiple packet section fields are used. Since I don't want (2) and (1) seems unnecessarily strict, I came to the conclusion that we must allow padding. And as you say yourself, the IEs required to identify padding are already available. Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Jul 15 08:51:34 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024D03A6853; Tue, 15 Jul 2008 08:51:34 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D3B3A67EC for ; Tue, 15 Jul 2008 08:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfevL4Tqxvex for ; Tue, 15 Jul 2008 08:51:28 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 09EFA3A68CC for ; Tue, 15 Jul 2008 08:51:27 -0700 (PDT) Received: from [127.0.0.1] (u-173-c224.cs.uni-tuebingen.de [134.2.173.224]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id m6FFpnxY005033; Tue, 15 Jul 2008 17:51:50 +0200 Message-ID: <487CC79E.8070406@informatik.uni-tuebingen.de> Date: Tue, 15 Jul 2008 17:51:58 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Aitken References: <487C9525.7020103@cisco.com> In-Reply-To: <487C9525.7020103@cisco.com> X-Enigmail-Version: 0.95.6 X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.8.0.68; VDF: 7.0.5.118; host: mx05) Cc: IETF PSAMP Working Group , Juergen Quittek Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664715970==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0664715970== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020509090008050004010406" This is a cryptographically signed message in MIME format. --------------ms020509090008050004010406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul, Paul Aitken wrote: >> Do people in the WG think we should allow padding of reported >> packet sections within an IE or shall we rather stick with the >> current rule that section IEs MUST NOT be padded? >=20 > If packet sections must not be padded then either: >=20 > 1. we mandate that variable length encoding MUST be used, or >=20 > 2. we accept that templates may be consumed at an alarming rate > to cope with the various different sized packet sections. >=20 > Indeed, templates may be exhausted exponentially when multiple > packet section fields are used. Template exhaustion is not an implicit consequence of not mandating VLE. If fixed length encoding is used, the Exporter may define a small number of Templates with packet section fields of different lengths and choose the one with the maximum length not exceeding the packet boundary. Of course, it is possible to define many different Templates which only differ in the length of the packet section field. But there are other ways of defining many Templates in a stupid way which lead to Template exhaustion as well. Therefore, I do not think that Template exhaustion is a problem which is specific to the padding issue. > Since I don't want (2) and (1) seems unnecessarily strict, I came to th= e > conclusion that we must allow padding. >=20 > And as you say yourself, the IEs required to identify padding are > already available. My remark is not in favor or against allowing padding. I just do no think that your argumentation forces us to allow padding. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms020509090008050004010406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDcxNTE1NTE1OFowIwYJKoZIhvcNAQkEMRYEFAdTg/kkBLeK jeXbqcHNFNj6Izs/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAuOMfABiKFj47qAFpdjSCvvu2Xv4ddRN6MaxsSquLYlp+a8Kes5NJXqTv3 ZfqJEkUw5ncxTr2yt4owuBT3Lkwd7okbASIR7NLfwC7eKi8nw6SY/oB5bx4XYUWukCbp928m SByl3J9gILJvzpUenZOxGt+I6NwYvDy5Xqq8VFNWc3W8mO/RmmSy2Zg6lDzh4g7JrFJO+dRa 8rEw7kz+JO5JYBDsxD9wYztZSOGbl+TzatXuaFAhx62qwRccDVQQeZbJT1V7bgv+hLBe/B3A rsltb0XM92Us4ieBCS8dbJUMW1WCKcR5cAqNsf+L4Sj+Iv9+LjRR5jQv8IQ1h53jOLy6AAAA AAAA --------------ms020509090008050004010406-- --===============0664715970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0664715970==-- From psamp-bounces@ietf.org Tue Jul 15 09:08:32 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839283A68CC; Tue, 15 Jul 2008 09:08:32 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53F13A68CC for ; Tue, 15 Jul 2008 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExS9Cz0momMG for ; Tue, 15 Jul 2008 09:08:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9E40B3A6881 for ; Tue, 15 Jul 2008 09:08:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,367,1212364800"; d="scan'208";a="14433139" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2008 16:08:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6FG8qWd024432; Tue, 15 Jul 2008 18:08:52 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6FG8q2Y028998; Tue, 15 Jul 2008 16:08:52 GMT Received: from [10.61.64.46] (ams3-vpn-dhcp46.cisco.com [10.61.64.46]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6FG8lE27356; Tue, 15 Jul 2008 17:08:48 +0100 (BST) Message-ID: <487CCB8C.8040202@cisco.com> Date: Tue, 15 Jul 2008 17:08:44 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Gerhard Muenz References: <487C9525.7020103@cisco.com> <487CC79E.8070406@informatik.uni-tuebingen.de> In-Reply-To: <487CC79E.8070406@informatik.uni-tuebingen.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1453; t=1216138132; x=1217002132; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=3A=20padding=20of=20reported =20packet=20sections |Sender:=20; bh=vpqgkkKxyZ3McUMgNco/0oKEm7mAi7X2H9ma8b4c4HE=; b=RdBphhNwUnbyDUNXwKx7wYnGnEO0b2KOW89f0oC/rD5ZG/ALTFbyBJnRYM 8pHi51m50635N9bTe2xUbcvNjWsc5AVqq5wf8oc+KGwYOsXdBRVRe5yp9hEG CMOPFMBtWa; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF PSAMP Working Group , Juergen Quittek Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Gerhard, > Template exhaustion is not an implicit consequence of not mandating VLE. > If fixed length encoding is used, the Exporter may define a small number > of Templates with packet section fields of different lengths and choose > the one with the maximum length not exceeding the packet boundary. Absolutely! But then some data may be lost from the end of the packet, so we'd have a similar issue to when padding is used - ie, the need for additional IEs to be exported indicating how much of the packet data was exported. > Of course, it is possible to define many different Templates which only > differ in the length of the packet section field. But there are other > ways of defining many Templates in a stupid way which lead to Template > exhaustion as well. Therefore, I do not think that Template exhaustion > is a problem which is specific to the padding issue. Sure: template exhaustion isn't necessarily caused by careless use of packet sections. However, careless use of packet sections will definitely lead to template exhaustion. > My remark is not in favor or against allowing padding. I just do no > think that your argumentation forces us to allow padding. I'd be quite happy for this text to be removed: "The data for this field MUST NOT be padded." Then padding is neither required nor forced. But neither is it precluded! -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 00:56:44 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A2A3A6A51; Wed, 16 Jul 2008 00:56:43 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D183A6A3D for ; Wed, 16 Jul 2008 00:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR2+TLvGtWFV for ; Wed, 16 Jul 2008 00:56:41 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4B0FD3A6A47 for ; Wed, 16 Jul 2008 00:56:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 11FD22C000304; Wed, 16 Jul 2008 09:57:10 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfQeAFyyu2AW; Wed, 16 Jul 2008 09:57:09 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id D95662C000303; Wed, 16 Jul 2008 09:56:54 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 07:56:55 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 09:56:52 +0200 From: Juergen Quittek To: Paul Aitken , Gerhard Muenz Message-ID: Thread-Topic: PSAMP-INFO: padding of reported packet sections Thread-Index: AcjnGYHsC5VIGfs6hUOQPnbAt3lCpA== In-Reply-To: <487CCB8C.8040202@cisco.com> Mime-version: 1.0 Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Speaking as technical contributor: I fully support Paul's statement that sending some packet data that is by nature of variable length in fixed length Information Elements would require a different template for each length of the information you want to send. This may lead to an absurd number of templates to be used for reporting. And my conclusion is quite simple: Trying to send something that is by nature of variable length in fixed length Information Elements is a bad idea. The alternative that we are discussing is using a single template with fixed length fields and filling the fixed length field with padding octets when the actual data is shorter than the fixed length field. In order to know the actual length of the information, we send another Information Element that tells us how many octets in the padded IE are actual data. This this alternative would probably work well. It would be a nice workaround if we did not had variable length encoding. But we do have it and it is much than the workaround. - Variable length encoding is more efficient for variable length packet data than fixed length encoding because - you do not fill your Data Record with useless padding octets - you do not need to send the length of the encoded packet data in a separate Information Element - Variable length encoding is more self-contained than padded fixed length encoding, because you can store, forward and interpret the IE without having to take care of another accompanying one that tells you which octets inside are valid Consequently, I would keep the statement that *Section IEs MUST NOT be padded. However, I would still not suggest to disallow fixed length encoding of *section IEs because there are cases where you know that your section always has the same length, for example, if you report in ipHeaderPacketSection the first 12 octets of the IP header. Juergen > Gerhard, > >> Template exhaustion is not an implicit consequence of not mandating VLE. >> If fixed length encoding is used, the Exporter may define a small number >> of Templates with packet section fields of different lengths and choose >> the one with the maximum length not exceeding the packet boundary. > > Absolutely! > > But then some data may be lost from the end of the packet, so we'd have > a similar issue to when padding is used - ie, the need for additional > IEs to be exported indicating how much of the packet data was exported. > > >> Of course, it is possible to define many different Templates which only >> differ in the length of the packet section field. But there are other >> ways of defining many Templates in a stupid way which lead to Template >> exhaustion as well. Therefore, I do not think that Template exhaustion >> is a problem which is specific to the padding issue. > > Sure: template exhaustion isn't necessarily caused by careless use of > packet sections. However, careless use of packet sections will > definitely lead to template exhaustion. > > >> My remark is not in favor or against allowing padding. I just do no >> think that your argumentation forces us to allow padding. > > I'd be quite happy for this text to be removed: "The data for this > field MUST NOT be padded." > > Then padding is neither required nor forced. But neither is it precluded! _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 02:18:20 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A0028C0FC; Wed, 16 Jul 2008 02:18:20 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AE028C0FC for ; Wed, 16 Jul 2008 02:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4DaohAOeALL for ; Wed, 16 Jul 2008 02:18:18 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 3E8063A689D for ; Wed, 16 Jul 2008 02:18:18 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KJ39n-0007vT-QT; Wed, 16 Jul 2008 11:18:43 +0200 Message-ID: <487DBCF8.9030004@informatik.uni-tuebingen.de> Date: Wed, 16 Jul 2008 11:18:48 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1386875570==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1386875570== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070005090308020201000400" This is a cryptographically signed message in MIME format. --------------ms070005090308020201000400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable J=FCrgen, Paul, Juergen Quittek wrote: > Speaking as technical contributor: >=20 > I fully support Paul's statement that sending some packet data > that is by nature of variable length in fixed length Information > Elements would require a different template for each length of > the information you want to send. This may lead to an absurd > number of templates to be used for reporting. >=20 > And my conclusion is quite simple: > Trying to send something that is by nature of variable length > in fixed length Information Elements is a bad idea. >=20 > The alternative that we are discussing is using a single template > with fixed length fields and filling the fixed length field with > padding octets when the actual data is shorter than the fixed length > field. In order to know the actual length of the information, we > send another Information Element that tells us how many octets in > the padded IE are actual data. >=20 > This this alternative would probably work well. It would be a nice > workaround if we did not had variable length encoding. But we do > have it and it is much than the workaround. >=20 > - Variable length encoding is more efficient for variable length > packet data than fixed length encoding because > - you do not fill your Data Record with useless padding octets > - you do not need to send the length of the encoded packet > data in a separate Information Element >=20 > - Variable length encoding is more self-contained than padded > fixed length encoding, because you can store, forward and > interpret the IE without having to take care of another > accompanying one that tells you which octets inside are valid One disadvantage of VLE is that parsing a Data Sets of Records including variable length fields is much more complex and therefore requires more processing time at the collector. For example, in our Data Set parser implementation, we first check if the length of the Record is known from the Template (i.e., if there is no VLE). The complexity of the Data Set treatment which comes behind this IF-statement is significantly different for fixed-length and variable-length Records because VLE requires a complex calculation of the offset for each Record. Therefore, in practice, it can make sense to accept a slightly increased Record length if this allows the collector to decode Records at a much higher rate. > Consequently, I would keep the statement that *Section IEs MUST NOT > be padded. The only working alternative would be allowing both options: 1) VLE 2) fixed length encoding with mandatory additional length IE However, I'm not sure if 2) represents a real advantage compared to using different Templates with different fixed-length for *Section fields= =2E Assumed that we are many interested in the export of network and transport layer information (IP+TCP/UDP/ICMP) and that IP/TCP options are rare, then only a small number of different lengths would be required= : IP+TCP=3D20+20=3D40 IP+UDP=3D20+8=3D28 =2E.. For the small number of special cases differing from this scheme, we can define another template with variable length field. Regards, Gerhard > However, I would still not suggest to disallow fixed length > encoding of *section IEs because there are cases where you > know that your section always has the same length, for example, > if you report in ipHeaderPacketSection the first 12 octets of > the IP header. >=20 > Juergen >=20 >=20 >> Gerhard, >> >>> Template exhaustion is not an implicit consequence of not mandating V= LE. >>> If fixed length encoding is used, the Exporter may define a small num= ber >>> of Templates with packet section fields of different lengths and choo= se >>> the one with the maximum length not exceeding the packet boundary. >> Absolutely! >> >> But then some data may be lost from the end of the packet, so we'd hav= e >> a similar issue to when padding is used - ie, the need for additional >> IEs to be exported indicating how much of the packet data was exported= =2E >> >> >>> Of course, it is possible to define many different Templates which on= ly >>> differ in the length of the packet section field. But there are other= >>> ways of defining many Templates in a stupid way which lead to Templat= e >>> exhaustion as well. Therefore, I do not think that Template exhaustio= n >>> is a problem which is specific to the padding issue. >> Sure: template exhaustion isn't necessarily caused by careless use of >> packet sections. However, careless use of packet sections will >> definitely lead to template exhaustion. >> >> >>> My remark is not in favor or against allowing padding. I just do no >>> think that your argumentation forces us to allow padding. >> I'd be quite happy for this text to be removed: "The data for this >> field MUST NOT be padded." >> >> Then padding is neither required nor forced. But neither is it preclud= ed! >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070005090308020201000400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDcxNjA5MTg0OFowIwYJKoZIhvcNAQkEMRYEFJREubINITPE N2p5DXyPJVMDBtVKMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBrjdm//wxG0IiASqWAsVqU8TE//39k692YuzVGO0lqlo67dUtEwwP3OiXv rGV3lUQDaBhrytzUlmFsHVSRthHT5CIEP0DlSVN8Bbd0W1XSTrE3Cs1j/lr5b9LsTyoWFLCx XTeAjFDtSHXIJP1+lpaMEoQa2vRGjeyZHEtdgXNqQV+VJ8/b3U7r4143MZNX5qGbNgw1AWI/ lGyV8pn7snCmcwl2+fb5Qym7ze2KzJ1t+nOAsOkg1qYTUcROnYxKkDBw3hoaPV/tZ6PL2fEI fyP8qvUZX8EuvNGCWky2abkDhjIuydZl6Lo5KSvyYC0YEwRwUQjea2Ygm9Av3hz0uc0EAAAA AAAA --------------ms070005090308020201000400-- --===============1386875570== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1386875570==-- From psamp-bounces@ietf.org Wed Jul 16 04:09:48 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416E63A68CB; Wed, 16 Jul 2008 04:09:48 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6783A68CB for ; Wed, 16 Jul 2008 04:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ2cUV2KhmgB for ; Wed, 16 Jul 2008 04:09:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 891733A6846 for ; Wed, 16 Jul 2008 04:09:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14504407" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 11:10:12 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6GBACKd019285; Wed, 16 Jul 2008 13:10:12 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GBAC2K004942; Wed, 16 Jul 2008 11:10:12 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6GBABE06173; Wed, 16 Jul 2008 12:10:12 +0100 (BST) Message-ID: <487DD713.8000304@cisco.com> Date: Wed, 16 Jul 2008 12:10:11 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1503; t=1216206612; x=1217070612; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=3A=20padding=20of=20reported =20packet=20sections |Sender:=20; bh=JQY+3GnZRiP8Xzr7UQXGbwN3vAS08VBAhKJCLRYp21o=; b=YMqiZkgcLysSsjKJYpUf1YzinNTVqzTdWkmX7SD8guH0mz7D7083JPJ4c/ f3iVSn6ntDu9auLfuLlQLOgxosnVMm/Gx+RTBo5UzSaWrCtL9T7aHo7dGfvJ Lh8p3zQla6; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Juergen, In our implementation the user specifies how much data is to be captured, eg "capture packet-data length 200". The length tells us how wide a field to allocate in the cache. It's important that the cache field is of a fixed size (ie, regardless of the packet data) for two reasons: 1. To ensure that any following fields are located at a constant offset. 2. So we can hash on the data in the case that it's a key field. Obviously we have to pad the cached data if it's less than the specified length. Since we now have a fixed length field (including the padding) it's straightforward for us to export it as such - which is why I'd like the "MUST NOT be padded" restriction to be removed. It'd be more complicated to export as a variable-length field since we'd also need to cache the length - which we don't necessarily do, unless the user has also configured it. And if the user has configured it then we'd also export it, which gives them the necessary information to decode the fixed length field! Another view is that the user has asked for 200 bytes, so that's what we should provide. Finally, variable length fields are also not backwards compatible with netflow v9 - and we've been striving to ensure as much v9 and IPFIX compatibility as possible, to make the transition as simple as possible. So we'd prefer not to mandate that variable length MUST be used. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 04:28:29 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156233A6A51; Wed, 16 Jul 2008 04:28:29 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96A13A6A51 for ; Wed, 16 Jul 2008 04:28:27 -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=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgIpMyFYa7NO for ; Wed, 16 Jul 2008 04:28:26 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 685B03A6982 for ; Wed, 16 Jul 2008 04:28:26 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KJ5Bj-0007zX-4Z; Wed, 16 Jul 2008 13:28:51 +0200 Message-ID: <487DDB74.9030401@informatik.uni-tuebingen.de> Date: Wed, 16 Jul 2008 13:28:52 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Aitken References: <487DD713.8000304@cisco.com> In-Reply-To: <487DD713.8000304@cisco.com> Cc: IETF PSAMP Working Group , Juergen Quittek Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0901939929==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0901939929== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020008000207080908030104" This is a cryptographically signed message in MIME format. --------------ms020008000207080908030104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Paul, Paul Aitken wrote: > Juergen, >=20 > In our implementation the user specifies how much data is to be > captured, eg "capture packet-data length 200". >=20 > The length tells us how wide a field to allocate in the cache. >=20 > It's important that the cache field is of a fixed size (ie, regardless > of the packet data) for two reasons: >=20 > 1. To ensure that any following fields are located at a constant offset= =2E > 2. So we can hash on the data in the case that it's a key field. >=20 > Obviously we have to pad the cached data if it's less than the specifie= d > length. >=20 > Since we now have a fixed length field (including the padding) it's > straightforward for us to export it as such - which is why I'd like the= > "MUST NOT be padded" restriction to be removed. >=20 > It'd be more complicated to export as a variable-length field since we'= d > also need to cache the length - which we don't necessarily do, unless > the user has also configured it. And if the user has configured it then= > we'd also export it, which gives them the necessary information to > decode the fixed length field! In the presence of padding, we should mandate (or at least recommend) that the section length of valid section data is also included in the Record. Otherwise, there may be problems to correctly interprete the exported information. Regards, Gerhard > Another view is that the user has asked for 200 bytes, so that's what w= e > should provide. >=20 > Finally, variable length fields are also not backwards compatible with > netflow v9 - and we've been striving to ensure as much v9 and IPFIX > compatibility as possible, to make the transition as simple as possible= =2E >=20 > So we'd prefer not to mandate that variable length MUST be used. >=20 > Cheers. --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms020008000207080908030104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDcxNjExMjg1MlowIwYJKoZIhvcNAQkEMRYEFI89+S+s0BMZ tC28L176zUVvKkcnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBQ/IBcIWwadasV4nNnIC/2n1YefsFcQ7Z/RS7aRCloKDf9hMknudT+FOsa OqnWhgkrbxvSdLygoteC3NIRzzef8UBn+bpbw8mlZtWEWAwznGDMaOs/O5E0Z1sK4TBdHm/v sNKQKFHilI9L+Cs2+t70GGAwRnOp/ZnQNFBNiCWBqBOLrh0X1X1PLwH33QzmQmAyS3FksBRx ExkTTxj9JAqtto+FP5jB8hscoUpuDRqZm/c/ShOM4ieaEYnW8xvCvj9V99NYssSFr3A64A52 fye6meWjted5X3AZdOpoNyCc5mCIono0LvmC6egDkOpI6mKuRE1NucfQQo9TdHrsyG2QAAAA AAAA --------------ms020008000207080908030104-- --===============0901939929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0901939929==-- From psamp-bounces@ietf.org Wed Jul 16 04:32:24 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210B43A6AFE; Wed, 16 Jul 2008 04:32:24 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C7A3A6982 for ; Wed, 16 Jul 2008 04:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+hcb1BzsRSn for ; Wed, 16 Jul 2008 04:32:21 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2A0AB3A686C for ; Wed, 16 Jul 2008 04:32:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3A74C2C000350; Wed, 16 Jul 2008 13:32:50 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbbpNr0VYjl7; Wed, 16 Jul 2008 13:32:50 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 0A1D62C000304; Wed, 16 Jul 2008 13:32:40 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 16 Jul 2008 13:32:34 +0200 Message-ID: <547F018265F92642B577B986577D671C1AD379@VENUS.office> In-Reply-To: <487DD713.8000304@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO: padding of reported packet sections Thread-Index: AcjnNJR7ePsv0CFnRCu5ZGLdSpTIqAAAYqaQ References: <487DD713.8000304@cisco.com> From: "Thomas Dietz" To: "Paul Aitken" , "Juergen Quittek" Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1094139781==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============1094139781== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0033_01C8E748.67D716B0" This is a multipart message in MIME format. ------=_NextPart_000_0033_01C8E748.67D716B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Paul, find my comments inline... -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf > Of Paul Aitken > Sent: Mittwoch, 16. Juli 2008 13:10 > To: Juergen Quittek > Cc: IETF PSAMP Working Group > Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections > > Juergen, > > In our implementation the user specifies how much data is to be > captured, eg "capture packet-data length 200". > > The length tells us how wide a field to allocate in the cache. > > It's important that the cache field is of a fixed size (ie, regardless > of the packet data) for two reasons: > > 1. To ensure that any following fields are located at a constant > offset. > 2. So we can hash on the data in the case that it's a key field. > > Obviously we have to pad the cached data if it's less than the > specified > length. > > Since we now have a fixed length field (including the padding) it's > straightforward for us to export it as such - which is why I'd like the > "MUST NOT be padded" restriction to be removed. > > It'd be more complicated to export as a variable-length field since > we'd > also need to cache the length - which we don't necessarily do, unless > the user has also configured it. And if the user has configured it then > we'd also export it, which gives them the necessary information to > decode the fixed length field! > First, if you just export the section without the length it is useless for the user. If you export the length then you can (with the same effort) export a variable length field. Btw. at one time of the processing you must have the length anyway because you need to know where the padding starts. At that point in time you can also cache it. It's just so easy to write it at the beginning (or the end whatever you like better) of the 200 byte buffer and have it at maximum 2 bytes longer if you store it in IPFIX format. > Another view is that the user has asked for 200 bytes, so that's what > we > should provide. > Hey, but if the packet is only 27 bytes a 200 byte information element does give the same information as a 27 byte information element and wastes network bandwidth. > Finally, variable length fields are also not backwards compatible with > netflow v9 - and we've been striving to ensure as much v9 and IPFIX > compatibility as possible, to make the transition as simple as > possible. > You can keep your internal processing as is. You just need to change the exporting. If the user wants to have IPFIX and not Netflow v9 then he/she must have a collector for it. If he/she has a collector it must conform to the IPFIX protocol, thus it must support variable length information elements. So I don't see your point here. Just my point of view, Best Regards, Thomas > So we'd prefer not to mandate that variable length MUST be used. > > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www.ietf.org/mailman/listinfo/psamp ------=_NextPart_000_0033_01C8E748.67D716B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCAuowggLmAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwNzE2MTEzMjM0WjAjBgkqhkiG9w0BCQQxFgQUaEhwzadd+aWZHDbh2fvMy/8r yjwwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBoBgsqhkiG 9w0BCRACCzFZoFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYCLIVHGTkxIR+LosZ/1ukFklWrTkMPHv4CuTAU/6VusBAdfJHTsxHu8 5U2TJxbRKIULBrEVHOXnbbEn65SYuNUtT35p8Bv7Dhnl2Edj1LTrqIvNTVud+DN99NacUxpWbeZh R4KtdYYP1dfibz7tZ1sdC6IC1N9OqkwfGxyjCqbrTQAAAAAAAA== ------=_NextPart_000_0033_01C8E748.67D716B0-- --===============1094139781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1094139781==-- From psamp-bounces@ietf.org Wed Jul 16 04:58:06 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20A23A6B40; Wed, 16 Jul 2008 04:58:05 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3063A6982 for ; Wed, 16 Jul 2008 04:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kgCxM07o+8Gl for ; Wed, 16 Jul 2008 04:58:03 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DBA1C3A69C9 for ; Wed, 16 Jul 2008 04:58:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 049A12C0008C1; Wed, 16 Jul 2008 13:58:32 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw6E0EIJeFgN; Wed, 16 Jul 2008 13:58:31 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id C6E082C000304; Wed, 16 Jul 2008 13:58:21 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 16 Jul 2008 13:58:19 +0200 Message-ID: <547F018265F92642B577B986577D671C1AD384@VENUS.office> In-Reply-To: <487DBCF8.9030004@informatik.uni-tuebingen.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO: padding of reported packet sections Thread-Index: AcjnJQIC5K47fTJoS4KCQLjOr+MQMAAFR4dw References: <487DBCF8.9030004@informatik.uni-tuebingen.de> From: "Thomas Dietz" To: "Gerhard Muenz" , "Juergen Quittek" Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1556596019==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============1556596019== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0038_01C8E74C.00DCA4D0" This is a multipart message in MIME format. ------=_NextPart_000_0038_01C8E74C.00DCA4D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Gehard, all, find my comments inline... --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf > Of Gerhard Muenz > Sent: Mittwoch, 16. Juli 2008 11:19 > To: Juergen Quittek > Cc: IETF PSAMP Working Group > Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections >=20 >=20 > J=FCrgen, Paul, >=20 > Juergen Quittek wrote: > > Speaking as technical contributor: > > > > I fully support Paul's statement that sending some packet data > > that is by nature of variable length in fixed length Information > > Elements would require a different template for each length of > > the information you want to send. This may lead to an absurd > > number of templates to be used for reporting. > > > > And my conclusion is quite simple: > > Trying to send something that is by nature of variable length > > in fixed length Information Elements is a bad idea. > > > > The alternative that we are discussing is using a single template > > with fixed length fields and filling the fixed length field with > > padding octets when the actual data is shorter than the fixed length > > field. In order to know the actual length of the information, we > > send another Information Element that tells us how many octets in > > the padded IE are actual data. > > > > This this alternative would probably work well. It would be a nice > > workaround if we did not had variable length encoding. But we do > > have it and it is much than the workaround. > > > > - Variable length encoding is more efficient for variable length > > packet data than fixed length encoding because > > - you do not fill your Data Record with useless padding octets > > - you do not need to send the length of the encoded packet > > data in a separate Information Element > > > > - Variable length encoding is more self-contained than padded > > fixed length encoding, because you can store, forward and > > interpret the IE without having to take care of another > > accompanying one that tells you which octets inside are valid >=20 > One disadvantage of VLE is that parsing a Data Sets of Records > including > variable length fields is much more complex and therefore requires = more > processing time at the collector. >=20 > For example, in our Data Set parser implementation, we first check if > the length of the Record is known from the Template (i.e., if there is > no VLE). The complexity of the Data Set treatment which comes behind > this IF-statement is significantly different for fixed-length and > variable-length Records because VLE requires a complex calculation of > the offset for each Record. >=20 > Therefore, in practice, it can make sense to accept a slightly > increased > Record length if this allows the collector to decode Records at a much > higher rate. >=20 >From my point of view the processing rate is only important if we talk = about mediator/concentrators etc. A normal collector can just store the = received records and process them as time allows. I personally would include a special case here which just imposes a = small impact on processing (at least I believe so): one VLE at the very end of = the record. Then you know in advance at what position of the packet the VLE length is and can quickly add it to the fixed size and get the position = of the next record. > > Consequently, I would keep the statement that *Section IEs MUST NOT > > be padded. >=20 > The only working alternative would be allowing both options: >=20 > 1) VLE > 2) fixed length encoding with mandatory additional length IE >=20 > However, I'm not sure if 2) represents a real advantage compared to > using different Templates with different fixed-length for *Section > fields. >=20 > Assumed that we are many interested in the export of network and > transport layer information (IP+TCP/UDP/ICMP) and that IP/TCP options > are rare, then only a small number of different lengths would be > required: >=20 > IP+TCP=3D20+20=3D40 > IP+UDP=3D20+8=3D28 > ... >=20 > For the small number of special cases differing from this scheme, we > can > define another template with variable length field. >=20 I would call this the ideal solution. Maybe it need a little more configuration and processing effort on the exporter (because it must = decide: is the length 40 take template a, is it 28 take template b or else take template c), but I think that is affordable. Best Regards, Thomas > Regards, > Gerhard >=20 >=20 > > However, I would still not suggest to disallow fixed length > > encoding of *section IEs because there are cases where you > > know that your section always has the same length, for example, > > if you report in ipHeaderPacketSection the first 12 octets of > > the IP header. > > > > Juergen > > > > > >> Gerhard, > >> > >>> Template exhaustion is not an implicit consequence of not = mandating > VLE. > >>> If fixed length encoding is used, the Exporter may define a small > number > >>> of Templates with packet section fields of different lengths and > choose > >>> the one with the maximum length not exceeding the packet boundary. > >> Absolutely! > >> > >> But then some data may be lost from the end of the packet, so we'd > have > >> a similar issue to when padding is used - ie, the need for > additional > >> IEs to be exported indicating how much of the packet data was > exported. > >> > >> > >>> Of course, it is possible to define many different Templates which > only > >>> differ in the length of the packet section field. But there are > other > >>> ways of defining many Templates in a stupid way which lead to > Template > >>> exhaustion as well. Therefore, I do not think that Template > exhaustion > >>> is a problem which is specific to the padding issue. > >> Sure: template exhaustion isn't necessarily caused by careless use > of > >> packet sections. However, careless use of packet sections will > >> definitely lead to template exhaustion. > >> > >> > >>> My remark is not in favor or against allowing padding. I just do = no > >>> think that your argumentation forces us to allow padding. > >> I'd be quite happy for this text to be removed: "The data for this > >> field MUST NOT be padded." > >> > >> Then padding is neither required nor forced. But neither is it > precluded! > > >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz ------=_NextPart_000_0038_01C8E74C.00DCA4D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCAuowggLmAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwNzE2MTE1ODE5WjAjBgkqhkiG9w0BCQQxFgQUKzmiGyJurtb4w05NtifZ3frg decwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBoBgsqhkiG 9w0BCRACCzFZoFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYCaaNAo68Ic8uROqSS+38UzFwzc63VXLRbm8P0MDO9tGuD52ip1iJ57 /r4PLZvPfYCBoibJLSuIMW5BGgZKyvdjshbEmj08qK1+2EO2CUOrGyhvCPMnXqg97JXo61isWgkq ShSMhKe2Yy4dNssPZ8fjiK2sfmw+NT0dvErc5aQNgwAAAAAAAA== ------=_NextPart_000_0038_01C8E74C.00DCA4D0-- --===============1556596019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1556596019==-- From psamp-bounces@ietf.org Wed Jul 16 05:37:12 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C969E3A6B8A; Wed, 16 Jul 2008 05:37:12 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E760C3A6B53 for ; Wed, 16 Jul 2008 05:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQIiymw3BMu8 for ; Wed, 16 Jul 2008 05:37:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 96F253A6ADD for ; Wed, 16 Jul 2008 05:37:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14516125" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 12:37:38 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6GCbc5n014373; Wed, 16 Jul 2008 14:37:38 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GCbcCp014412; Wed, 16 Jul 2008 12:37:38 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6GCbbE13459; Wed, 16 Jul 2008 13:37:38 +0100 (BST) Message-ID: <487DEB91.8090109@cisco.com> Date: Wed, 16 Jul 2008 13:37:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Gerhard Muenz References: <487DD713.8000304@cisco.com> <487DDB74.9030401@informatik.uni-tuebingen.de> In-Reply-To: <487DDB74.9030401@informatik.uni-tuebingen.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=662; t=1216211858; x=1217075858; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=3A=20padding=20of=20reported =20packet=20sections |Sender:=20; bh=IejciDZzVtC4JgRNWE2x2LjFUt0/NLEVBMH1HEzLhA4=; b=kwreSkNXX94xlUTGpt0s6EwJOoWx3vMuvijfI1iOms1C+DVaFDf4ueISem YrINGSnStGImxJKg1DfGr1co1W9Rj69c5dZxlovieQD4FgJLQGFN6GO8HBji qtM8YHRatR; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF PSAMP Working Group , Juergen Quittek Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Gerhard, > In the presence of padding, we should mandate (or at least recommend) I agree with "at least recommend". We cannot know what the user wants to do with the data, so we should not try to guess. > that the section length of valid section data is also included in the > Record. Otherwise, there may be problems to correctly interprete the > exported information. The length can be calculated from existing IEs, eg ipHeaderLength, ipPayloadLength and ipTotalLength. So it's not necessary to export a further IE to indicate the amount of "valid" data in the section. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 05:42:00 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A0A3A6BAB; Wed, 16 Jul 2008 05:41:59 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5189F3A6B9D for ; Wed, 16 Jul 2008 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOGdPoDwS479 for ; Wed, 16 Jul 2008 05:41:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 189CE3A6B76 for ; Wed, 16 Jul 2008 05:41:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14516888" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 12:42:21 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6GCgLnf016207; Wed, 16 Jul 2008 14:42:21 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GCgLlq016860; Wed, 16 Jul 2008 12:42:21 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6GCgKE13841; Wed, 16 Jul 2008 13:42:20 +0100 (BST) Message-ID: <487DECAC.1060006@cisco.com> Date: Wed, 16 Jul 2008 13:42:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Thomas Dietz References: <487DBCF8.9030004@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C1AD384@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C1AD384@VENUS.office> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=490; t=1216212141; x=1217076141; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20psamp-bounces@ietf.org] =20=20Re=3A=20[PSAMP]=20PSAMP-INFO=3A=20padding=0A=20of=20re ported=20packet=20sections |Sender:=20; bh=UXnI4xOkgAMWI85y7a79ucthGLcDzUQe0fwAl1KS7IA=; b=ffX1xZEYRfNXO8zanJAqJYcVixzsUBto3muzm9arzWstl7h/mqa/5IBpUU WWddfwwS3A9NkpvqQUmw8gwGBR9pwAMdnaa+sZ4AwSX8C8QM+pEJuXviUncG G+buumDxCt; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Juergen Quittek , IETF PSAMP Working Group Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Thomas, > I personally would include a special case here which just imposes a > small impact on processing (at least I believe so): one VLE at the > very end of the record. There may be multiple VLEs. > Then you know in advance at what position of the packet the VLE > length is and can quickly add it to the fixed size and get the > position of the next record. Sounds a bit like draft-irino-ipfix-ie-order? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 06:00:56 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86EE28C282; Wed, 16 Jul 2008 06:00:56 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CC828C299 for ; Wed, 16 Jul 2008 06:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpySr0gk9ffk for ; Wed, 16 Jul 2008 06:00:55 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id EC80528C21A for ; Wed, 16 Jul 2008 06:00:53 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KJ6dF-000835-4k; Wed, 16 Jul 2008 15:01:21 +0200 Message-ID: <487DF129.3070200@informatik.uni-tuebingen.de> Date: Wed, 16 Jul 2008 15:01:29 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Aitken References: <487DBCF8.9030004@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C1AD384@VENUS.office> <487DECAC.1060006@cisco.com> In-Reply-To: <487DECAC.1060006@cisco.com> Cc: IETF PSAMP Working Group , Juergen Quittek Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1904602506==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1904602506== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030200050303000302080708" This is a cryptographically signed message in MIME format. --------------ms030200050303000302080708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Paul, Paul Aitken wrote: > Thomas, >=20 >> I personally would include a special case here which just imposes a >> small impact on processing (at least I believe so): one VLE at the >> very end of the record. >=20 > There may be multiple VLEs. >=20 >=20 >> Then you know in advance at what position of the packet the VLE length= >> is and can quickly add it to the fixed size and get the >> position of the next record. >=20 > Sounds a bit like draft-irino-ipfix-ie-order? Indeed. However, I have not yet understood why VLE fields at the end of the Record are advantageous. If the goal is to calculate the Record boundary and if there is only one VLE field in the Record, the parser can jump to its position and extract the variable length field. However, the VLE field does not have to be the last field in the Record in order to do so. More generally, the number of iterations in the VLE parser depends on the number of VLE fields in the Record. Therefore, fewer VLE fields result in a faster parsing and Record boundary determination. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms030200050303000302080708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDcxNjEzMDEyOVowIwYJKoZIhvcNAQkEMRYEFA+QYdPEaFHz ebcktQ6quMuscS/JMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQDGFJVY+39qpV9MdajFs6urb8TttCLMYTPJRUQ46i6s1gMRl7UqUGyCSwMQ VnTSIne69VQO52wM6yH+4ed2lKX2agg5Q9uAqsWWuiv0h8XJbDIpzSFDB2gKVz//W+SYmz4a G2hSjnf+NyMUb5iPbVLZCROiFYiNUCnZYMjjspUD4SCzbs3AZBPzgjbbUjcJoOIv1altqpTj pP+0SCGGhwvhG2ZHqHO9xRQ/Vle/fb/o06b75hGHQwHNASm9PWCjxAwmpLTUszkNFewALlnI hYOnBi4N/rDJ5fAJupmv3DE6sfp5ta7VP1pEpAc0+L8h+bm2NoVgrXNLjefGe0i6sx6nAAAA AAAA --------------ms030200050303000302080708-- --===============1904602506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1904602506==-- From psamp-bounces@ietf.org Wed Jul 16 06:39:32 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789723A6BE5; Wed, 16 Jul 2008 06:39:32 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9822F3A6BDD for ; Wed, 16 Jul 2008 06:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 QlvhBJq2CUC1 for ; Wed, 16 Jul 2008 06:39:30 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B67FD3A6A5C for ; Wed, 16 Jul 2008 06:39:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id F0A832C00035D; Wed, 16 Jul 2008 15:39:59 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi4ovmApUPL1; Wed, 16 Jul 2008 15:39:59 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id CC0532C000304; Wed, 16 Jul 2008 15:39:44 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 13:39:44 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 15:39:41 +0200 From: Juergen Quittek To: Paul Aitken , Gerhard Muenz Message-ID: Thread-Topic: PSAMP-INFO: padding of reported packet sections Thread-Index: AcjnSWYAr9ljvEZcX0i38liQ0IbRzQ== In-Reply-To: <487DEB91.8090109@cisco.com> Mime-version: 1.0 Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Paul, On 16.07.08 14:37 "Paul Aitken" wrote: > Gerhard, > >> In the presence of padding, we should mandate (or at least recommend) > > I agree with "at least recommend". > > We cannot know what the user wants to do with the data, so we should not > try to guess. > > >> that the section length of valid section data is also included in the >> Record. Otherwise, there may be problems to correctly interprete the >> exported information. > > The length can be calculated from existing IEs, eg ipHeaderLength, > ipPayloadLength and ipTotalLength. > > So it's not necessary to export a further IE to indicate the amount of > "valid" data in the section. It is definitely necessary to export at least one further IE. The further IEs would contain packet length or the header length in one IE and the payload length in another one. But it is indeed not necessary to define further IEs for this purpose. We have them already. Juergen _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 06:49:10 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FD228C301; Wed, 16 Jul 2008 06:49:10 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9023928C301 for ; Wed, 16 Jul 2008 06:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvzvzyh2A1Tj for ; Wed, 16 Jul 2008 06:49:08 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 876F828C2AE for ; Wed, 16 Jul 2008 06:49:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id BAC7F2C00035D; Wed, 16 Jul 2008 15:49:36 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeGsHXUDZ4GE; Wed, 16 Jul 2008 15:49:36 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 86A7F2C000304; Wed, 16 Jul 2008 15:49:21 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 16 Jul 2008 15:49:19 +0200 Message-ID: <547F018265F92642B577B986577D671C1AD3C0@VENUS.office> In-Reply-To: <487DF129.3070200@informatik.uni-tuebingen.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sender: psamp-bounces@ietf.org] Re: [PSAMP] PSAMP-INFO: padding of reported packet sections Thread-Index: AcjnRBUJtW61xUMLR3ewMEyRUWgJZAABY8FA References: <487DBCF8.9030004@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C1AD384@VENUS.office> <487DECAC.1060006@cisco.com> <487DF129.3070200@informatik.uni-tuebingen.de> From: "Thomas Dietz" To: "Gerhard Muenz" , "Paul Aitken" Cc: IETF PSAMP Working Group , Juergen Quittek Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1124030191==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============1124030191== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0052_01C8E75B.82605290" This is a multipart message in MIME format. ------=_NextPart_000_0052_01C8E75B.82605290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gerhard, > -----Original Message----- > From: Gerhard Muenz [mailto:muenz@informatik.uni-tuebingen.de] > Sent: Mittwoch, 16. Juli 2008 15:01 > To: Paul Aitken > Cc: Thomas Dietz; Juergen Quittek; IETF PSAMP Working Group > Subject: Re: [Sender: psamp-bounces@ietf.org] Re: [PSAMP] PSAMP-INFO: > padding of reported packet sections >=20 >=20 > Hi Thomas, Paul, >=20 > Paul Aitken wrote: > > Thomas, > > > >> I personally would include a special case here which just imposes a > >> small impact on processing (at least I believe so): one VLE at the > >> very end of the record. > > > > There may be multiple VLEs. > > > > > >> Then you know in advance at what position of the packet the VLE > length > >> is and can quickly add it to the fixed size and get the > >> position of the next record. > > > > Sounds a bit like draft-irino-ipfix-ie-order? >=20 > Indeed. However, I have not yet understood why VLE fields at the end = of > the Record are advantageous. >=20 > If the goal is to calculate the Record boundary and if there is only > one > VLE field in the Record, the parser can jump to its position and > extract > the variable length field. However, the VLE field does not have to be > the last field in the Record in order to do so. >=20 The VLE does not need to be at the end. But if it is at the end then the offsets for all other fields (counted from the start of the record) = always remain constant and the elements can be read quickly. You then need only = to add the length of the (last) VLE field to the known constant length and = you know the start of the next record. > More generally, the number of iterations in the VLE parser depends on > the number of VLE fields in the Record. Therefore, fewer VLE fields > result in a faster parsing and Record boundary determination. That's of course true, but I would expect to have only 1 VLE most of the time. Then being smart with decoding this special case where the single = VLE is at the end may speed up processing. Nevertheless I do not expect performance issues with new powerful collectors/mediators/concentrators anyway. They must anyway have CPU power to do the concentrator/mediator work. Regards, Thomas >=20 > Regards, > Gerhard >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL ------=_NextPart_000_0052_01C8E75B.82605290 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCAuowggLmAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwNzE2MTM0OTE5WjAjBgkqhkiG9w0BCQQxFgQUS02RMjDvApYnojWRnsqheNd0 X4EwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBoBgsqhkiG 9w0BCRACCzFZoFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYATVQL8ezVWkGzWH8xJ0Y8WYj/5SXF2/w265Z8qxdMOuAatb+c2Vudk pnaN4PhMaUqCxaiqGA3FBH1v1kKrkDsE92KyRaY+pnUbcMTPAXxYOtwMO3jqYEoJcHKUQdRT3GZR EffrVe2Cu8n+pBJbdiv5+5f4OS1IanEFXqFrHixbbgAAAAAAAA== ------=_NextPart_000_0052_01C8E75B.82605290-- --===============1124030191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1124030191==-- From psamp-bounces@ietf.org Wed Jul 16 06:54:03 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631FA3A6B53; Wed, 16 Jul 2008 06:54:03 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486CC3A6B21 for ; Wed, 16 Jul 2008 06:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 USOaLzS8OJiw for ; Wed, 16 Jul 2008 06:54:00 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id EBD663A68E1 for ; Wed, 16 Jul 2008 06:53:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 2EF7F2C000304; Wed, 16 Jul 2008 15:54:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK3LDp6riVI6; Wed, 16 Jul 2008 15:54:29 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id F11562C00035A; Wed, 16 Jul 2008 15:54:13 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 16 Jul 2008 15:54:12 +0200 Message-ID: <547F018265F92642B577B986577D671C1AD3C2@VENUS.office> In-Reply-To: <487DECAC.1060006@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sender: psamp-bounces@ietf.org] Re: [PSAMP] PSAMP-INFO: padding of reported packet sections Thread-Index: AcjnQW9J0+UffoE5RKyjj/PJowaffAACVggw References: <487DBCF8.9030004@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C1AD384@VENUS.office> <487DECAC.1060006@cisco.com> From: "Thomas Dietz" To: "Paul Aitken" Cc: Juergen Quittek , IETF PSAMP Working Group Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1136726675==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multipart message in MIME format. --===============1136726675== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0056_01C8E75C.3112EAF0" This is a multipart message in MIME format. ------=_NextPart_000_0056_01C8E75C.3112EAF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Paul, > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Mittwoch, 16. Juli 2008 14:42 > To: Thomas Dietz > Cc: Gerhard Muenz; Juergen Quittek; IETF PSAMP Working Group > Subject: Re: [Sender: psamp-bounces@ietf.org] Re: [PSAMP] PSAMP-INFO: > padding of reported packet sections > > Thomas, > > > I personally would include a special case here which just imposes a > > small impact on processing (at least I believe so): one VLE at the > > very end of the record. > > There may be multiple VLEs. True, but that's why I called this special case. Btw. I wouldn't expect more than one VLE in a record in the majority of cases anyway. > > > > Then you know in advance at what position of the packet the VLE > > length is and can quickly add it to the fixed size and get the > > position of the next record. > > Sounds a bit like draft-irino-ipfix-ie-order? Well, yes. If you are that concerned about performance... But I expect the device that needs does mediation/concentration anyway to be powerful because of the processing it needs to do for the concentration. Then decoding VLEs is not an issue (otherwise decoding IP packets which are by nature variable length would also be a problem). Best Regards, Thomas > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL ------=_NextPart_000_0056_01C8E75C.3112EAF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggM5MIICoqADAgECAhBD3kUGfpHtO7Zw5BdS Zkm1MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTkwMDAw MDBaFw0wOTEwMTIyMzU5NTlaMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKB gQDcKpmdbjP8u0F2xDkejfd255APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLR F7kUBGmGXGFPs2Vli2Oi7iF8Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYt atavL37bESqF+2VgWkXoGwIBA6OBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0 BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAImQvq5zldxCHk2g j+8C+6loWwvtLEWziOuOTs80iqY1DoOM0LQTL+uqlfw2fmiFnPw3WVPKuQwGhOE7ZAcLITREdYg3 NsW1WA2oODuvoGG4fGwXn+H/4dpDqEKGAl1K7ZyQjRKqTMJuA5gfQ69+m0m1tHSjbq1qW+svscua HqaaMIIDZjCCAs+gAwIBAgIQRuECOhCAVuaaKKVALy7ycDANBgkqhkiG9w0BAQQFADBDMREwDwYD VQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTAeFw0wNzEwMjQwMDAwMDBaFw0wODEwMjMyMzU5NTlaMIHdMRswGQYDVQQKDBJORUMgRXVy b3BlIExpbWl0ZWQxRjBEBgNVBAsMPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5j b3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxNTAzBgNVBAsMLENvbXBhbnkgLSBORUMgTGFib3Jh dG9yaWVzIEV1cm9wZSBIZWlkZWxiZXJnMRUwEwYDVQQDDAxUaG9tYXMgRGlldHoxKDAmBgkqhkiG 9w0BCQEWGXRob21hcy5kaWV0ekBudy5uZWNsYWIuZXUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALC4yWRsqDAwBYKjb3zoUfE18Tj5pOb+b2u/jmoeW6I3KKtzQxSIcW6qGrkrks0px63VYr72 6VF72Qhv4K31ntSOOLVOgz/yUXu2TBqsGxzcpjHD9LIJPK2LbEoo8m4t5mcVQReNhvrsCFukpYZn tb6xoCmmFfxcXeZh48Rhn4wVAgMBAAGjgb8wgbwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD VR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIHgDBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vb25z aXRlY3JsLnZlcmlzaWduLmNvbS9PblNpdGVQdWJsaWMvTGF0ZXN0Q1JMLmNybDANBgkqhkiG9w0B AQQFAAOBgQAeld8hZLp3F1TtzJkmSe1io5guKbUqux6y0l//Ya5ESWBOpApe3vweWAsZYbn3dw0U F73oKpjuW6qdSNJizqtngj9is0DLLqH3u2PG3zksB7oy4hYPKejEuq4HXz3/bIxZSwvl7S9XL0Ce tSXJji+Rh4wFkL3GLZkWrlXPO+Y5tTGCAuowggLmAgEBMFcwQzERMA8GA1UEChMIVmVyaVNpZ24x LjAsBgNVBAsTJVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbm miilQC8u8nAwCQYFKw4DAhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwNzE2MTM1NDEyWjAjBgkqhkiG9w0BCQQxFgQUV+ODETTTO7giZQYbY4wmoMB2 8ewwZgYJKwYBBAGCNxAEMVkwVzBDMREwDwYDVQQKEwhWZXJpU2lnbjEuMCwGA1UECxMlVmVyaVNp Z24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBDQQIQRuECOhCAVuaaKKVALy7ycDBoBgsqhkiG 9w0BCRACCzFZoFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsTJVZlcmlTaWduIENsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEbhAjoQgFbmmiilQC8u8nAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYBRQSSG81JhFuzLm+j9P3F2MJuOgFwPnkRAO3tu1p7p2U8BRSfSeMyY 9QSb426iqczyxiNMYzOlTOPkZxnDc1SeAPEbQ/p0QjBSYuEA5tubZP7AQUicrH/44xplgdUlMu0U UyhHVq+DXLfapodHKYPZRikPEeXs5+EP5H4xQVDESwAAAAAAAA== ------=_NextPart_000_0056_01C8E75C.3112EAF0-- --===============1136726675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1136726675==-- From psamp-bounces@ietf.org Wed Jul 16 07:17:58 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B943A68B0; Wed, 16 Jul 2008 07:17:58 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98BB3A687E for ; Wed, 16 Jul 2008 07:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGYY9fXU0YP8 for ; Wed, 16 Jul 2008 07:17:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 52A223A6846 for ; Wed, 16 Jul 2008 07:17:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14530042" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 14:18:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6GEIKgH019596; Wed, 16 Jul 2008 16:18:20 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GEIK1n000286; Wed, 16 Jul 2008 14:18:20 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6GEIKE22163; Wed, 16 Jul 2008 15:18:20 +0100 (BST) Message-ID: <487E032B.4050104@cisco.com> Date: Wed, 16 Jul 2008 15:18:19 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1424; t=1216217900; x=1217081900; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20psamp-bounces@ietf.org] =20=20[PSAMP]=20PSAMP-INFO=3A=20linkLayerFrame*=0A=20IEs |Sender:=20; bh=5zlZrmjXujs4bwY1ZnPx6kko5coNuY6Z+TYpKskUDpY=; b=VVT+IJd0lFbkjtm+osuPVHl48Gej6kVFrqo76papXtp/cKizwmyqmFuf/E wyjE4mVd1SbKKYe7iK//UADBo3m0UVOTPLzmTVLC5UYmkIL+ULkCI+zN1/Ka 9HmT0dYXxI; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Juergen, > Here is another issue for PSAMP-INFO: > > In the current version of draft-ietf-psamp-info there are two > Information Elements related to link layer frames: dataLinkFrameSize > and dataLinkFrameSection. > > I would like to discuss whether it is of advantage to have generic > dataLinkFrame* IEs rather than specific ones. > > A generic one is nice, if you are reporting different types of data > link layer frames. > > But if you don't know which data link layer was present, > interpretation of the IE becomes tricky. We definitely need a layer 2 protocol IE to allow the layer 2 frame to be understood. > The most common case is probably an Ethernet frame. Also for 802.11 > the concept of a frame is pretty clear. > > It gets more difficult if you use MPLS. What is then the data link > frame? Or for 802.16 (WiMAX, where multiple packets for multiple > receivers may be contained in a single frame (burst). > > Things would get much clearer is we used link layer-specific IEs > instead of a dataLinkFrame* IEs, such as ethernetFrameSection, > wlanFrameSection, wimaxBurstSection, etc. > > Any opinions on this issue? Instead of IEs specific to each link layer, we should have a generic section field and extract specific and useful fields into their own IEs. Exactly as we do for L3, in fact. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 07:19:49 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438233A68F7; Wed, 16 Jul 2008 07:19:49 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AD33A68F7 for ; Wed, 16 Jul 2008 07:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od7bSaHv0Nit for ; Wed, 16 Jul 2008 07:19:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1D6F43A687E for ; Wed, 16 Jul 2008 07:19:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14530342" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 14:20:15 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6GEKF3k020366; Wed, 16 Jul 2008 16:20:15 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GEKFYd001265; Wed, 16 Jul 2008 14:20:15 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6GEKEE22390; Wed, 16 Jul 2008 15:20:14 +0100 (BST) Message-ID: <487E039E.308@cisco.com> Date: Wed, 16 Jul 2008 15:20:14 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Thomas Dietz References: <487DBCF8.9030004@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C1AD384@VENUS.office> <487DECAC.1060006@cisco.com> <547F018265F92642B577B986577D671C1AD3C2@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C1AD3C2@VENUS.office> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=307; t=1216218015; x=1217082015; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=3A=20padding=20of=20reported =20packet=20sections |Sender:=20; bh=Z3SeEB+kQp7PI7CkiyH56H9Z3Ll2TYk6cZlbr8JbPJ0=; b=V3OMb1AvpA6oa1xrZGusaSW6QvSAl2GXmITIdaQ4prS/YcR4JCQ3Xnekdu 0yMzH9f+x1qyVPhBY6bBbjf2K3ZZM7wDK7O5QRfQEYTWNKgHDU4Am/kyZVgX MOTVqP2JwF; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Juergen Quittek , IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: padding of reported packet sections X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Thomas, > Btw. I wouldn't expect more than one VLE in a record in the majority > of cases anyway. That very much depends on the monitor and exporter. We can have no expectations when the user can configure whatever fields they like. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 10:03:44 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DAFD3A698C; Wed, 16 Jul 2008 10:03:44 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72593A69B5 for ; Wed, 16 Jul 2008 10:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF15hxIy3SwQ for ; Wed, 16 Jul 2008 10:03:42 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0DF423A698C for ; Wed, 16 Jul 2008 10:03:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 54CDC2C000304; Wed, 16 Jul 2008 19:04:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppGTCJ0LBPHE; Wed, 16 Jul 2008 19:04:11 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 34A3D2C000303; Wed, 16 Jul 2008 19:04:01 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jul 2008 17:04:01 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 16 Jul 2008 19:03:57 +0200 From: Juergen Quittek To: Paul Aitken Message-ID: Thread-Topic: [Sender: psamp-bounces@ietf.org] [PSAMP] PSAMP-INFO: linkLayerFrame* IEs Thread-Index: AcjnZe8lmvfKgbpRaUWNmpkAWJ08mw== In-Reply-To: <487E032B.4050104@cisco.com> Mime-version: 1.0 Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Hi Paul, On 16.07.08 16:18 "Paul Aitken" wrote: > Juergen, > >> Here is another issue for PSAMP-INFO: >> >> In the current version of draft-ietf-psamp-info there are two >> Information Elements related to link layer frames: dataLinkFrameSize >> and dataLinkFrameSection. >> >> I would like to discuss whether it is of advantage to have generic >> dataLinkFrame* IEs rather than specific ones. >> >> A generic one is nice, if you are reporting different types of data >> link layer frames. >> >> But if you don't know which data link layer was present, >> interpretation of the IE becomes tricky. > > We definitely need a layer 2 protocol IE to allow the layer 2 frame to > be understood. I don't think we have them yet. Is there a need for more IEs? Juergen _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 11:23:48 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265C928C165; Wed, 16 Jul 2008 11:23:48 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F58128C165 for ; Wed, 16 Jul 2008 11:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYnK2GyZTjK7 for ; Wed, 16 Jul 2008 11:23:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5E0E628C0E6 for ; Wed, 16 Jul 2008 11:23:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,198,1215388800"; d="scan'208";a="14554997" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 18:24:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6GIOD6x020622; Wed, 16 Jul 2008 20:24:13 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GIODud028793; Wed, 16 Jul 2008 18:24:13 GMT Received: from [10.61.97.229] (dhcp-10-61-97-229.cisco.com [10.61.97.229]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6GIOCE13940; Wed, 16 Jul 2008 19:24:12 +0100 (BST) Message-ID: <487E3CCC.3020704@cisco.com> Date: Wed, 16 Jul 2008 19:24:12 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=472; t=1216232653; x=1217096653; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=3A=20=20linkLayerFrame*=20IE s |Sender:=20; bh=FiZRibS9Fcan6WUqDImpgphyyn78BPaffpcECwSF3MI=; b=NONivsgF90HVtWUMOsPQEZe9ApLOzhZzYKqwen0xTPSunEjgOmT+5hUc6+ V1S4uDO+fHk9QeG1n1vm3+0EMKGjb3TurQKc6Dl0NJiXmGAqCbvC/OvBgj1/ y/EpFoEAHc; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Juergen, >> We definitely need a layer 2 protocol IE to allow the layer 2 frame to >> be understood. > > I don't think we have them yet. Correct. > Is there a need for more IEs? At least the L2 protocol. Else, how would you interpret the frame? We could also define individual L2 fields - though I would see that as a separate work; no need to stall any other work in progress. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 16 23:59:47 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD00F3A6A95; Wed, 16 Jul 2008 23:59:47 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25BF03A6A96 for ; Wed, 16 Jul 2008 23:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2FWuwxWgj0ZJ for ; Wed, 16 Jul 2008 23:59:45 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3B0123A6A95 for ; Wed, 16 Jul 2008 23:59:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C3ACB2C000304; Thu, 17 Jul 2008 09:00:13 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dn6z6FuJNKc; Thu, 17 Jul 2008 09:00:13 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id A28932C00035D; Thu, 17 Jul 2008 09:00:03 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Jul 2008 07:00:04 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 17 Jul 2008 09:00:00 +0200 From: Juergen Quittek To: Paul Aitken Message-ID: Thread-Topic: PSAMP-INFO: linkLayerFrame* IEs Thread-Index: Acjn2rqgVUzjGEwl2UiiA9a/RyPoHg== In-Reply-To: <487E3CCC.3020704@cisco.com> Mime-version: 1.0 Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Paul, On 16.07.08 20:24 "Paul Aitken" wrote: > Juergen, > >>> We definitely need a layer 2 protocol IE to allow the layer 2 frame to >>> be understood. >> >> I don't think we have them yet. > > Correct. > > >> Is there a need for more IEs? > > At least the L2 protocol. Else, how would you interpret the frame? > > We could also define individual L2 fields - though I would see that as a > separate work; no need to stall any other work in progress. I would create EthernetFrameSize, EthernetFrameSection, wlanFrameSize, wlanFrameSection, wimaxBurstSize, wimaxBurstSection, mplspacketsize (if we don't have it already), etc. These would all be self-contained and none of them would need any further IEs for interpreting their content. Cheers, Juergen _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Thu Jul 17 01:50:03 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12BFA3A6817; Thu, 17 Jul 2008 01:50:03 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414A93A6A7C for ; Thu, 17 Jul 2008 01:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1AaQmSOK4C0 for ; Thu, 17 Jul 2008 01:50:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EA4C83A6817 for ; Thu, 17 Jul 2008 01:50:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,202,1215388800"; d="scan'208";a="14602943" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2008 08:50:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6H8oSjH025009; Thu, 17 Jul 2008 10:50:28 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6H8oSPw000406; Thu, 17 Jul 2008 08:50:28 GMT Received: from [10.61.97.229] (dhcp-10-61-97-229.cisco.com [10.61.97.229]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6H8oMs29166; Thu, 17 Jul 2008 09:50:22 +0100 (BST) Message-ID: <487F07D2.4000701@cisco.com> Date: Thu, 17 Jul 2008 09:50:26 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=934; t=1216284628; x=1217148628; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20PSAMP-INFO=3A=20=20linkLayerFrame*=20IE s |Sender:=20; bh=MBXMQvCWnfmEQEEwCQkcvW36x1Zazc3iiPgioLQZb4o=; b=ZkYinMVtzkRu72aaAnfAgUpCz1Ud7LpxUWJlFrrmNIX4wgDzO+BoQJNoIS 1O09gUT+8vhPw8L6TTgZ0wIdf+QbxNutDvvJ+e+w90RXS+/G71+pAbKtBzxE +ZDkGK7+ms; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Juergen, > I would create EthernetFrameSize, EthernetFrameSection, wlanFrameSize, > wlanFrameSection, wimaxBurstSize, wimaxBurstSection, mplspacketsize (if > we don't have it already), etc. That's exactly what I *wouldn't* do. > These would all be self-contained and none of them would need any > further IEs for interpreting their content. By the same token we should throw away all the L3 fields and retain just the IPv4packetSection and IPv6packetSection - since these are both "self-contained and none of them would need any further IEs for interpreting their content". Clearly it makes no sense at all. As I recall, the previous IPFIX charter said something about defining all the fields that are required for the information model. I guess there was an assumption that this wouldn't be a minimalistic set of packet/frame sections. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Jul 18 07:33:33 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770453A6802; Fri, 18 Jul 2008 07:33:33 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3843A68EB for ; Fri, 18 Jul 2008 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oowcdyq8v7Ve for ; Fri, 18 Jul 2008 07:33:31 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 34C213A6802 for ; Fri, 18 Jul 2008 07:33:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4EF462C0004E2; Fri, 18 Jul 2008 16:34:04 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sqbZqR1Boe0; Fri, 18 Jul 2008 16:34:04 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 3057D2C000305; Fri, 18 Jul 2008 16:33:54 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Jul 2008 14:33:54 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 18 Jul 2008 16:33:50 +0200 From: Juergen Quittek To: Paul Aitken Message-ID: Thread-Topic: PSAMP-INFO: linkLayerFrame* IEs Thread-Index: Acjo40ti1HVkxEKwH0GsiGVgfhYOZQ== In-Reply-To: <487F07D2.4000701@cisco.com> Mime-version: 1.0 Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Hi Paul, On 17.07.08 10:50 "Paul Aitken" wrote: > Juergen, > >> I would create EthernetFrameSize, EthernetFrameSection, wlanFrameSize, >> wlanFrameSection, wimaxBurstSize, wimaxBurstSection, mplspacketsize (if >> we don't have it already), etc. > > That's exactly what I *wouldn't* do. > >> These would all be self-contained and none of them would need any >> further IEs for interpreting their content. > > By the same token we should throw away all the L3 fields and retain just > the IPv4packetSection and IPv6packetSection - since these are both > "self-contained and none of them would need any further IEs for > interpreting their content". > > Clearly it makes no sense at all. I think it makes a lot of sense. All of the Information Elements we standardized so far are self-contained. Packet sections with an unspecified number of padding octets and linkLayerFrameSections for an unspecified link layer technology would be the first ones that are not self-contained. In order to read the full content you need to have another IE that tells you the the use link layer technology or length of the padding, respectively. I would not be happy with introducing such a new class of IEs that are only readable in the presence of others. > As I recall, the previous IPFIX charter said something about defining > all the fields that are required for the information model. I guess > there was an assumption that this wouldn't be a minimalistic set of > packet/frame sections. Definitely not. We have different IEs for v4 and v6. There is no general problem with having different IEs for Ethernet and WLAN. Juergen _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Jul 21 08:22:53 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA683A69C5; Mon, 21 Jul 2008 08:22:53 -0700 (PDT) X-Original-To: psamp@ietf.org Delivered-To: psamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E6C303A69F6; Mon, 21 Jul 2008 06:44:55 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080721134455.E6C303A69F6@core3.amsl.com> Date: Mon, 21 Jul 2008 06:44:55 -0700 (PDT) X-Mailman-Approved-At: Mon, 21 Jul 2008 08:22:52 -0700 Cc: psamp chair , Internet Architecture Board , psamp mailing list , RFC Editor Subject: [PSAMP] Protocol Action: 'Packet Sampling (PSAMP) Protocol Specifications' to Proposed Standard X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org The IESG has approved the following document: - 'Packet Sampling (PSAMP) Protocol Specifications ' as a Proposed Standard This document is the product of the Packet Sampling Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-09.txt Technical Summary This document specifies the export of packet information from a Packet Sampling (PSAMP) Exporting Process to a PSAMP Collecting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. Working Group Summary There is a solid WG consensus on the content of the draft. Protocol Quality The document was reviewed in the WG, and by key members of the IPFIX Working Group. An expert review was performed by Mark Allman from the TSV Directorate. Dan Romascanu reviewed the document on behalf of the IESG. Note to RFC Editor RFC Editor, Please make the following changes in the document prior to publication: 1) in Section 6.4.1 "Basic Packet Report", 2nd paragraph OLD: For each selected packet, the Packet Report SHOULD contain the following information: - the observationTimeMicroseconds Information Element NEW: For each selected packet, the Packet Report SHOULD contain a time-related Information Element that matches the Metering Process time accuracy. Typically, the observationTimeMicroseconds Information Element. Other possible Information Elements are the observationTimeSeconds, the observationTimeMilliseconds, or the observationTimeNanoseconds 2) in Section 5 "PSAMP Requirements versus the IPFIX Solution", first paragraph: OLD In the "Generic Requirements for PSAMP" section, [PSAMP-FMWK] describes some requirements that affect directly the PSAMP export protocol. NEW: The [PSAMP-FMWK] contains PSAMP protocol requirements throughout the document, with a special focus in the "Generic Requirements for PSAMP" section and subsections. 3) in Section 5 "PSAMP Requirements versus the IPFIX Solution", first paragraph OLD Finally, [PSAMP-FMWK] describes a series of requirements specifying the different Information Elements that MUST and SHOULD be reported to the Collector. Nevertheless IPFIX, being a generic export protocol, can export any Information Elements as long as they are described in the information model. So these requirements are mainly targeted for the [PSAMP-INFO] document. NEW: [PSAMP-FMWK] also describes a series of requirements specifying the different Information Elements that MUST and SHOULD be reported to the Collector. Nevertheless IPFIX, being a generic export protocol, can export any Information Elements as long as they are described in the information model. So these requirements are mainly targeted for the [PSAMP-INFO] document. 4) in Section 3.3.1 "IPFIX and PSAMP Processes", first paragraph OLD: The figure B indicates the sequence of the processes (Metering and Exporting) within the PSAMP Device. NEW: The figure B indicates the sequence of the IPFIX processes (Metering and Exporting) within the PSAMP Device. 5) in Section 3.3.2 "Packet Report, Packet Interpretation, and Data Record", first OLD: The PSAMP terminology speaks of Packet Report and Packet Interpretation, while the IPFIX terminology speaks of Data Record and (Option) Template Record. The PSAMP Packet Report, which comprises information about the observed packet, can be viewed as analogous to the IPFIX Data Record defined by a Template Record. The PSAMP Packet Interpretation, which comprises subsidiary information used for the interpretation of the Packet Reports, can be viewed as analogous to the IPFIX Data Record defined by an Option Template Record. NEW: The PSAMP terminology speaks of Packet Report and Packet Interpretation, while the IPFIX terminology speaks of Data Record and (Option) Template Record. The PSAMP Packet Report, which comprises information about the observed packet, can be viewed as analogous to the IPFIX Data Record defined by a Template Record. The PSAMP Report Interpretation, which comprises subsidiary information used for the interpretation of the Packet Reports, can be viewed as analogous to the IPFIX Data Record defined by an Option Template Record. This Option Template Record contains subsidiary information, applicable to the observed packet sent into the PSAMP Packet Report. 6) in Section 4.1 "Architecture Point of View", 4th paragraph OLD: Packet Sampling as described in the PSAMP framework [PSAMP-FMWK] covers only stage 1 of the IPFIX architecture with the packet classification replaced by packet record export. NEW: Packet Sampling as described in the PSAMP framework [PSAMP-FMWK] covers only stage 1 of the IPFIX architecture with the packet classification replaced by packet record export, while IPFIX covers also the stage 2, as it generates Flow Records out of the selected packets. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Jul 21 08:55:45 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF893A6828; Mon, 21 Jul 2008 08:55:45 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDA83A686B for ; Mon, 21 Jul 2008 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 MvKSgdyUZf25 for ; Mon, 21 Jul 2008 08:55:44 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 823733A6828 for ; Mon, 21 Jul 2008 08:55:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,224,1215403200"; d="scan'208";a="115421271" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Jul 2008 11:56:20 -0400 X-IronPort-AV: E=Sophos;i="4.31,224,1215403200"; d="scan'208";a="239723202" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jul 2008 11:56:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 17:56:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] Protocol Action: 'Packet Sampling (PSAMP) Protocol Specifications' to Proposed Standard Thread-Index: AcjrRcHrSVnqA71hSlmYmcI3l+AJtAABG75g From: "Romascanu, Dan (Dan)" To: Subject: [PSAMP] FW: Protocol Action: 'Packet Sampling (PSAMP) Protocol Specifications' to Proposed Standard X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Congratulations to the editors, WG chair and the whole WG for reaching this milestone. Dan -----Original Message----- From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, July 21, 2008 4:45 PM To: IETF-Announce Cc: psamp chair; Internet Architecture Board; psamp mailing list; RFC Editor Subject: [PSAMP] Protocol Action: 'Packet Sampling (PSAMP) Protocol Specifications' to Proposed Standard The IESG has approved the following document: - 'Packet Sampling (PSAMP) Protocol Specifications ' as a Proposed Standard This document is the product of the Packet Sampling Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-09.txt Technical Summary This document specifies the export of packet information from a Packet Sampling (PSAMP) Exporting Process to a PSAMP Collecting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. Working Group Summary There is a solid WG consensus on the content of the draft. Protocol Quality The document was reviewed in the WG, and by key members of the IPFIX Working Group. An expert review was performed by Mark Allman from the TSV Directorate. Dan Romascanu reviewed the document on behalf of the IESG. Note to RFC Editor RFC Editor, Please make the following changes in the document prior to publication: 1) in Section 6.4.1 "Basic Packet Report", 2nd paragraph OLD: For each selected packet, the Packet Report SHOULD contain the following information: - the observationTimeMicroseconds Information Element NEW: For each selected packet, the Packet Report SHOULD contain a time-related Information Element that matches the Metering Process time accuracy. Typically, the observationTimeMicroseconds Information Element. Other possible Information Elements are the observationTimeSeconds, the observationTimeMilliseconds, or the observationTimeNanoseconds 2) in Section 5 "PSAMP Requirements versus the IPFIX Solution", first paragraph: OLD In the "Generic Requirements for PSAMP" section, [PSAMP-FMWK] describes some requirements that affect directly the PSAMP export protocol. NEW: The [PSAMP-FMWK] contains PSAMP protocol requirements throughout the document, with a special focus in the "Generic Requirements for PSAMP" section and subsections. 3) in Section 5 "PSAMP Requirements versus the IPFIX Solution", first paragraph OLD Finally, [PSAMP-FMWK] describes a series of requirements specifying the different Information Elements that MUST and SHOULD be reported to the Collector. Nevertheless IPFIX, being a generic export protocol, can export any Information Elements as long as they are described in the information model. So these requirements are mainly targeted for the [PSAMP-INFO] document. NEW: [PSAMP-FMWK] also describes a series of requirements specifying the different Information Elements that MUST and SHOULD be reported to the Collector. Nevertheless IPFIX, being a generic export protocol, can export any Information Elements as long as they are described in the information model. So these requirements are mainly targeted for the [PSAMP-INFO] document. 4) in Section 3.3.1 "IPFIX and PSAMP Processes", first paragraph OLD: The figure B indicates the sequence of the processes (Metering and Exporting) within the PSAMP Device. NEW: The figure B indicates the sequence of the IPFIX processes (Metering and Exporting) within the PSAMP Device. 5) in Section 3.3.2 "Packet Report, Packet Interpretation, and Data Record", first OLD: The PSAMP terminology speaks of Packet Report and Packet Interpretation, while the IPFIX terminology speaks of Data Record and (Option) Template Record. The PSAMP Packet Report, which comprises information about the observed packet, can be viewed as analogous to the IPFIX Data Record defined by a Template Record. The PSAMP Packet Interpretation, which comprises subsidiary information used for the interpretation of the Packet Reports, can be viewed as analogous to the IPFIX Data Record defined by an Option Template Record. NEW: The PSAMP terminology speaks of Packet Report and Packet Interpretation, while the IPFIX terminology speaks of Data Record and (Option) Template Record. The PSAMP Packet Report, which comprises information about the observed packet, can be viewed as analogous to the IPFIX Data Record defined by a Template Record. The PSAMP Report Interpretation, which comprises subsidiary information used for the interpretation of the Packet Reports, can be viewed as analogous to the IPFIX Data Record defined by an Option Template Record. This Option Template Record contains subsidiary information, applicable to the observed packet sent into the PSAMP Packet Report. 6) in Section 4.1 "Architecture Point of View", 4th paragraph OLD: Packet Sampling as described in the PSAMP framework [PSAMP-FMWK] covers only stage 1 of the IPFIX architecture with the packet classification replaced by packet record export. NEW: Packet Sampling as described in the PSAMP framework [PSAMP-FMWK] covers only stage 1 of the IPFIX architecture with the packet classification replaced by packet record export, while IPFIX covers also the stage 2, as it generates Flow Records out of the selected packets. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Jul 22 01:31:40 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F71C28C0D9; Tue, 22 Jul 2008 01:31:40 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E172C3A68A5; Tue, 22 Jul 2008 01:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+d+h0VN5yEP; Tue, 22 Jul 2008 01:31:38 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id B2DC63A63CB; Tue, 22 Jul 2008 01:31:37 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KLDI7-0004ia-3l; Tue, 22 Jul 2008 10:32:15 +0200 Message-ID: <48859B1E.9030102@informatik.uni-tuebingen.de> Date: Tue, 22 Jul 2008 10:32:30 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "ipfix@ietf.org" , psamp Subject: [PSAMP] IPFIX/PSAMP configuration data model X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0670885864==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0670885864== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090708080000060705060703" This is a cryptographically signed message in MIME format. --------------ms090708080000060705060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, As you may have noticed, the WG draft on the IPFIX/PSAMP configuration data model was finally published: http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-00 As an individual draft, the document was already presented various times. Many of you read and reviewed one of the earlier versions of the document. So, most of you do have a general notion of what the draft is about, which is great. Now, as we have a WG document, I would like to direct your attention to the draft again. I would appreciate receiving critical feedback in Dublin or on the mailing list. It will also be very useful to have some draft readers in the audience of the IPFIX session since there will be questions about how to proceed. Thanks, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms090708080000060705060703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDcyMjA4MzIzMFowIwYJKoZIhvcNAQkEMRYEFDL0totyu9HY ieH+/HWmZvH/MMnWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAobsM7mrxC3Ba1I05u807mF38OmZ2J+2EmoR60u6+oatvillIPOmQxDHz9 BFEGEIi1yGPeBLAh01jiPfesMIHP6imBe6pOsgAurgnNZugvQzXITpwN0YKC4ROBc6w551UB /u9clj+AhVX+dzoywOrtnc7rvuMBebpLUrP+OVjE8X9/ia3vimc+UAl7uZxBJsn04nG7cFMh vJ9kWOUDv0WWpw0d/jJ1QjY6sMwtiVGVJPF/5WPi8BoMsF64IfTj+FAUWO20XqVvqB6/ueKi Q8cpqWVa1Yjb6nQUQf07kkQEGQ9rVSCWNRnlPAFPak69pUxgtWkHGmES1kSWvqNgIYuRAAAA AAAA --------------ms090708080000060705060703-- --===============0670885864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0670885864==-- From psamp-bounces@ietf.org Tue Jul 22 05:22:13 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DD13A6882; Tue, 22 Jul 2008 05:22:13 -0700 (PDT) X-Original-To: psamp@ietf.org Delivered-To: psamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 881143A6839; Mon, 21 Jul 2008 09:37:46 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080721163746.881143A6839@core3.amsl.com> Date: Mon, 21 Jul 2008 09:37:46 -0700 (PDT) X-Mailman-Approved-At: Tue, 22 Jul 2008 05:22:12 -0700 Cc: psamp chair , Internet Architecture Board , psamp mailing list , RFC Editor Subject: [PSAMP] Document Action: 'A Framework for Packet Selection and Reporting' to Informational RFC X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org The IESG has approved the following document: - 'A Framework for Packet Selection and Reporting ' as an Informational RFC This document is the product of the Packet Sampling Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-13.txt Technical Summary This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized selectors, to form a stream of reports on the selected packets, and to export the reports to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and exporting are described, along with configuration requirements of the PSAMP functions. Working Group Summary There is a solid WG consensus on the content of the draft. However, it was discussed controversially whether this document should become an informational RFC or a standards track RFC. Protocol Quality This is a framework document. The protocol is defined in a different document. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Jul 22 05:22:13 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A833A68F3; Tue, 22 Jul 2008 05:22:13 -0700 (PDT) X-Original-To: psamp@ietf.org Delivered-To: psamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A28D028C14E; Mon, 21 Jul 2008 10:02:26 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080721170226.A28D028C14E@core3.amsl.com> Date: Mon, 21 Jul 2008 10:02:26 -0700 (PDT) X-Mailman-Approved-At: Tue, 22 Jul 2008 05:22:12 -0700 Cc: psamp chair , Internet Architecture Board , psamp mailing list , RFC Editor Subject: [PSAMP] Protocol Action: 'Sampling and Filtering Techniques for IP Packet Selection' to Proposed Standard X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org The IESG has approved the following document: - 'Sampling and Filtering Techniques for IP Packet Selection ' as a Proposed Standard This document is the product of the Packet Sampling Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-11.txt Technical Summary This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Measurement Processes and for reporting the technique in use to a Collector. Working Group Summary This document has been a regular WG document. There is strong consensus in the working group concerning the content of this document and the fact that it describes an appropriate sampling and filtering techniques for IP packet selection. Protocol Quality Dan Romascanu reviewed this document for the IESG, Vijay K. Gurbani did the Gen-Art review and Mark Allman performed an expert review on behalf of the TSV directorate. There are no known implementations yet, but two vendors and academic research institutes announced implementations. The document is fully supported by the WG and there has no concerns been raised that there are better alternatives or that the document is not useful. Note to RFC Editor Please perform the following edits: 1) Update all psamp and ipfix references to the latest versions by the date of the publication 2) Section 1: s/demand by measurement-based/demand of measurement-based/ 3) Section 5, second paragraph: s/First of all it/First of all, it/ 4) Section 13 s/[IPFIX-PROTO]B. Claise/[IPFIX-PROTO] B. Claise 5) in Section 1: OLD classification for flow analysis. All these factors can lead to an overwhelming amount of measurement data, resulting in high demands on resources for measurement, storage, transport and post processing. NEW classification for flow analysis. All these factors can lead to an overwhelming amount of measurement data, resulting in high demands on resources for measurement, storage, transfer and post processing. 6) In Section 6.1 OLD Property match operations should be available for different protocol portions of the packet header: (i) the IP header (excluding options in IPv4, stacked headers in IPv6) (ii) transport header NEW Property match operations should be available for different protocol portions of the packet header: (i) the IP header (excluding options in IPv4, stacked headers in IPv6) (ii) transport protocol header _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Jul 28 02:11:01 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974D33A682C; Mon, 28 Jul 2008 02:11:01 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651F13A682C for ; Mon, 28 Jul 2008 02:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhKcx0WkaFtS for ; Mon, 28 Jul 2008 02:10:59 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (mailgwb1.fraunhofer.de [153.96.87.18]) by core3.amsl.com (Postfix) with ESMTP id 4F6B33A67ED for ; Mon, 28 Jul 2008 02:10:58 -0700 (PDT) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m6S9B3Hn001021 for ; Mon, 28 Jul 2008 11:11:03 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m6S9B3QH001000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 11:11:03 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m6S9B2cA021086 for ; Mon, 28 Jul 2008 11:11:03 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:11:01 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A41E@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSAMP-INFO Thread-Index: Acjwkdq6QI9yHvy0Tuy3+X2f6QhAVA== From: "Zseby, Tanja" To: "psamp" X-Fraunhofer-Email-Policy: accepted Subject: [PSAMP] PSAMP-INFO X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0375891004==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0375891004== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F091.DB66ED22" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F091.DB66ED22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi PSAMP-INFO editors, =20 I had a look at the PSAMP-INFO document and have a question: What is meant with the fixed and relative error? Are this absolute/relative confidence boundaries to provide an accuracy statement? If yes, we also need an IE to report the confidence level. Furthermore, I would suggest to rename fixed error to absolute error.=20 If something else is meant, we could discuss to add an accuracy statement as further IE. Maybe we can discuss this after the IPFIX session or later this week? =20 Kind regards Tanja =20 =20 ------_=_NextPart_001_01C8F091.DB66ED22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi PSAMP-INFO editors,

 

I had a look at the PSAMP-INFO document and have a = question:

What is meant with the fixed and relative error? = Are this absolute/relative confidence boundaries to provide an accuracy statement?  If yes, we = also need an IE to report the confidence level. Furthermore, I would suggest = to rename fixed error to absolute error.

If something else is meant, we could discuss to add = an accuracy statement as further IE.

Maybe we can discuss this after the IPFIX session = or later this week?

 

Kind regards

Tanja

 

 

------_=_NextPart_001_01C8F091.DB66ED22-- --===============0375891004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0375891004==-- From psamp-bounces@ietf.org Mon Jul 28 02:51:05 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933293A68C8; Mon, 28 Jul 2008 02:51:05 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862613A691C for ; Mon, 28 Jul 2008 02:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhJuVIU--iqZ for ; Mon, 28 Jul 2008 02:51:02 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1E8F33A6809 for ; Mon, 28 Jul 2008 02:51:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id F10942C000304; Mon, 28 Jul 2008 11:51:10 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zihXrfirH9tk; Mon, 28 Jul 2008 11:51:10 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id D08152C000351; Mon, 28 Jul 2008 11:51:00 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 28 Jul 2008 09:51:00 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 28 Jul 2008 11:50:58 +0200 From: Juergen Quittek To: "Zseby, Tanja" , IETF PSAMP Working Group Message-ID: Thread-Topic: [PSAMP] PSAMP-INFO Thread-Index: Acjwkdq6QI9yHvy0Tuy3+X2f6QhAVAABZSv/ In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A41E@EXCHSRV.fokus.fraunhofer.de> Mime-version: 1.0 Subject: Re: [PSAMP] PSAMP-INFO X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org For a clear definition of these values, it would probably be required to either specify the formula for calculating them or to provide a reference (may be a text book) which exactly defines these values. Thanks, Juergen On 28.07.08 11:11 "Zseby, Tanja" wrote: > Hi PSAMP-INFO editors, > > > > I had a look at the PSAMP-INFO document and have a question: > > What is meant with the fixed and relative error? Are this > absolute/relative confidence boundaries to provide an accuracy > statement? If yes, we also need an IE to report the confidence level. > Furthermore, I would suggest to rename fixed error to absolute error. > > If something else is meant, we could discuss to add an accuracy > statement as further IE. > > Maybe we can discuss this after the IPFIX session or later this week? > > > > Kind regards > > Tanja > > > > > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Jul 28 04:14:34 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D644B3A6839; Mon, 28 Jul 2008 04:14:34 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA963A6839 for ; Mon, 28 Jul 2008 04:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpp+sBUEcqRT for ; Mon, 28 Jul 2008 04:14:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id C75AB3A67E7 for ; Mon, 28 Jul 2008 04:14:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SBEfO06695; Mon, 28 Jul 2008 13:14:41 +0200 (CEST) Received: from [10.61.96.82] (dhcp-10-61-96-82.cisco.com [10.61.96.82]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SBEeA20374; Mon, 28 Jul 2008 13:14:40 +0200 (CEST) Message-ID: <488DAA21.2050702@cisco.com> Date: Mon, 28 Jul 2008 12:14:41 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gerhard Muenz References: <4868F94C.1020500@informatik.uni-tuebingen.de> In-Reply-To: <4868F94C.1020500@informatik.uni-tuebingen.de> Cc: psamp Subject: Re: [PSAMP] psamp-protocol: Packet Records specific term in PSAMP? X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0005332739==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0005332739== Content-Type: multipart/alternative; boundary="------------090707010603030108050405" This is a multi-part message in MIME format. --------------090707010603030108050405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, Good catch. I think that the 3 instances of packet record in [PSAMP-PROTO] should be replaced by the Packet Report. Note: Regards, Benoit. > Dear Benoit, all, > > I fell over the following section in psamp-protocol: > > > 4.2 Protocol Point of View > > Concerning the protocol, the major difference between IPFIX and PSAMP > is that the IPFIX protocol exports Flow Records while the PSAMP > protocol exports Packet Records. > > > Words with capitalized first letter are usually specific terms. However, > Packet Records does not appear in the terminology section. > > Is "Packet Record" considered as a specific term or not? > > Regards, > Gerhard > > > ------------------------------------------------------------------------ > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www.ietf.org/mailman/listinfo/psamp > --------------090707010603030108050405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

Good catch.
I think that the 3 instances of packet record in [PSAMP-PROTO] should be replaced by the Packet Report.

Note:

Regards, Benoit.
Dear Benoit, all,

I fell over the following section in psamp-protocol:


4.2 Protocol Point of View

   Concerning the protocol, the major difference between IPFIX and PSAMP
   is that the IPFIX protocol exports Flow Records while the PSAMP
   protocol exports Packet Records.


Words with capitalized first letter are usually specific terms. However,
Packet Records does not appear in the terminology section.

Is "Packet Record" considered as a specific term or not?

Regards,
Gerhard

  

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp

--------------090707010603030108050405-- --===============0005332739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0005332739==-- From psamp-bounces@ietf.org Mon Jul 28 04:21:06 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCD13A69CE; Mon, 28 Jul 2008 04:21:06 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB633A6983 for ; Mon, 28 Jul 2008 04:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV8pgxoFIR0W for ; Mon, 28 Jul 2008 04:21:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 844083A68DE for ; Mon, 28 Jul 2008 04:21:04 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SBLDU07301; Mon, 28 Jul 2008 13:21:13 +0200 (CEST) Received: from [10.61.96.82] (dhcp-10-61-96-82.cisco.com [10.61.96.82]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SBLCA06215; Mon, 28 Jul 2008 13:21:12 +0200 (CEST) Message-ID: <488DABA9.5010200@cisco.com> Date: Mon, 28 Jul 2008 12:21:13 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] float64 needed for samplingProbability X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577991793==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0577991793== Content-Type: multipart/alternative; boundary="------------010305080608050107020903" This is a multi-part message in MIME format. --------------010305080608050107020903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, I think that the logic has been: since we have "6.2. Reduced Size Encoding of Integer and Float Types' in RFC5101, why not use float64? Just in case someone needs this granularity later on, we would not need to define a new I.E. Now it's true that I can't find a business case for samplingProbability float64. So "reducing" to float32 probably makes sense. No strong opinion on that one to be frank. Regards, Benoit. > Dear all, > > Dan's AD review identified a set of issues to be solved in PSAMP-INFO. > Most of them can be dealt with by the authors, but there is one for which > input from others is needed: > > Dan asked why we use float64 as data type for Information Element > samplingProbability (#311, section 8.2.11): > > >> T4. Section 8.2.11 - why is Abstract Data type float64 needed? It looks >> to me like float32 would be enough to express a probability value, or am >> I missing something? >> > > Can anyone give us a good reason for using float64 instead of the > smaller float32? > > Thanks, > > Juergen > --------------010305080608050107020903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen,

I think that the logic has been: since we have "6.2. Reduced Size Encoding of Integer and Float Types' in RFC5101, why not use float64? Just in case someone needs this granularity later on, we would not need to define a new I.E.
Now it's true that I can't find a business case for samplingProbability float64.
So "reducing" to float32 probably makes sense. No strong opinion on that one to be frank.

Regards, Benoit.
Dear all,

Dan's AD review identified a set of issues to be solved in PSAMP-INFO.
Most of them can be dealt with by the authors, but there is one for which
input from others is needed:

Dan asked why we use float64 as data type for Information Element
samplingProbability (#311, section 8.2.11):

  
T4. Section 8.2.11 - why is Abstract Data type float64 needed? It looks
to me like float32 would be enough to express a probability value, or am
I missing something?
    

Can anyone give us a good reason for using float64 instead of the
smaller float32?

Thanks,

    Juergen

--------------010305080608050107020903-- --===============0577991793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============0577991793==-- From psamp-bounces@ietf.org Tue Jul 29 08:47:04 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB55128C118; Tue, 29 Jul 2008 08:47:03 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E663A6BC2 for ; Tue, 29 Jul 2008 08:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eety0QlX5t8n for ; Tue, 29 Jul 2008 08:46:49 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id ACAAD3A6BC1 for ; Tue, 29 Jul 2008 08:46:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6TFl0v01187; Tue, 29 Jul 2008 17:47:00 +0200 (CEST) Received: from [10.61.81.214] (ams3-vpn-dhcp4567.cisco.com [10.61.81.214]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6TFkxA03290; Tue, 29 Jul 2008 17:47:00 +0200 (CEST) Message-ID: <488F3B75.2070508@cisco.com> Date: Tue, 29 Jul 2008 16:47:01 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Zseby, Tanja" References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A41E@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A41E@EXCHSRV.fokus.fraunhofer.de> Cc: psamp Subject: Re: [PSAMP] PSAMP-INFO X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1331907529==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============1331907529== Content-Type: multipart/alternative; boundary="------------060905020308040504050206" This is a multi-part message in MIME format. --------------060905020308040504050206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tanja, Those two information elements are used in section 6.5.4 Accuracy Report Interpretation from [PSAMP-PROTO]. There are even some examples in there. Let's discuss this week during the IETF Regards, Benoit. > > Hi PSAMP-INFO editors, > > > > I had a look at the PSAMP-INFO document and have a question: > > What is meant with the fixed and relative error? Are this > absolute/relative confidence boundaries to provide an accuracy > statement? If yes, we also need an IE to report the confidence level. > Furthermore, I would suggest to rename fixed error to absolute error. > > If something else is meant, we could discuss to add an accuracy > statement as further IE. > > Maybe we can discuss this after the IPFIX session or later this week? > > > > Kind regards > > Tanja > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www.ietf.org/mailman/listinfo/psamp > --------------060905020308040504050206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tanja,

Those two information elements are used in section 6.5.4 Accuracy Report Interpretation from [PSAMP-PROTO].
There are even some examples in there.
Let's discuss this week during the IETF

Regards, Benoit.

Hi PSAMP-INFO editors,

 

I had a look at the PSAMP-INFO document and have a question:

What is meant with the fixed and relative error? Are this absolute/relative confidence boundaries to provide an accuracy statement?  If yes, we also need an IE to report the confidence level. Furthermore, I would suggest to rename fixed error to absolute error.

If something else is meant, we could discuss to add an accuracy statement as further IE.

Maybe we can discuss this after the IPFIX session or later this week?

 

Kind regards

Tanja

 

 


_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp

--------------060905020308040504050206-- --===============1331907529== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp --===============1331907529==-- From psamp-bounces@ietf.org Tue Jul 29 15:15:07 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76D028C16E; Tue, 29 Jul 2008 15:15:07 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924DD28C176 for ; Tue, 29 Jul 2008 15:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] 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 wdQX2NRdcoI8 for ; Tue, 29 Jul 2008 15:15:05 -0700 (PDT) Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.17]) by core3.amsl.com (Postfix) with ESMTP id 85AB428C173 for ; Tue, 29 Jul 2008 15:15:04 -0700 (PDT) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw26] (8.14.2+/8.14.2) with ESMTP id m6TMFBtk007741; Wed, 30 Jul 2008 00:15:11 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m6TMFBn2007719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2008 00:15:11 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m6TMF8Tj028007; Wed, 30 Jul 2008 00:15:09 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 00:15:08 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A508@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] PSAMP-INFO Thread-Index: Acjxklu1mIJNgWXJTvOgZJCsBYDh8QAEFOEw References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A41E@EXCHSRV.fokus.fraunhofer.de> <488F3B75.2070508@cisco.com> From: "Zseby, Tanja" To: "Benoit Claise" X-Fraunhofer-Email-Policy: accepted Cc: psamp Subject: Re: [PSAMP] PSAMP-INFO X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org Hi Benoit, I had a look at the example. It seems that the intended usage is different from what I thought. So its probably sufficient to keep the IEs as they are, but it maybe good to improve the description a bit in PSMP-INFO. We can sort this out tomorrow. Kind regards Tanja > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, July 29, 2008 5:47 PM > To: Zseby, Tanja > Cc: psamp > Subject: Re: [PSAMP] PSAMP-INFO > > Hi Tanja, > > Those two information elements are used in section 6.5.4 Accuracy > Report Interpretation from [PSAMP-PROTO]. > There are even some examples in there. > Let's discuss this week during the IETF > > Regards, Benoit. > > > Hi PSAMP-INFO editors, > > > > I had a look at the PSAMP-INFO document and have a question: > > What is meant with the fixed and relative error? Are this > absolute/relative confidence boundaries to provide an accuracy > statement? If yes, we also need an IE to report the confidence level. > Furthermore, I would suggest to rename fixed error to absolute error. > > If something else is meant, we could discuss to add an accuracy > statement as further IE. > > Maybe we can discuss this after the IPFIX session or later this > week? > > > > Kind regards > > Tanja > > > > > > > ________________________________ > > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www.ietf.org/mailman/listinfo/psamp > > _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Wed Jul 30 09:40:02 2008 Return-Path: X-Original-To: psamp-text-archive@optimus.ietf.org Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D956F28C385; Wed, 30 Jul 2008 09:40:02 -0700 (PDT) X-Original-To: psamp@core3.amsl.com Delivered-To: psamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6932728C370 for ; Wed, 30 Jul 2008 09:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZPz4wEMrWfr for ; Wed, 30 Jul 2008 09:40:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id E5A5728C340 for ; Wed, 30 Jul 2008 09:40:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6UGeFB02231; Wed, 30 Jul 2008 18:40:15 +0200 (CEST) Received: from [10.61.64.233] (ams3-vpn-dhcp233.cisco.com [10.61.64.233]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6UGeEA09204; Wed, 30 Jul 2008 18:40:14 +0200 (CEST) Message-ID: <4890996D.4060601@cisco.com> Date: Wed, 30 Jul 2008 17:40:13 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Cc: IETF PSAMP Working Group Subject: Re: [PSAMP] PSAMP-INFO: linkLayerFrame* IEs X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0024374158==" Sender: psamp-bounces@ietf.org Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0024374158== Content-Type: multipart/alternative; boundary="------------020205020603040605050804" This is a multi-part message in MIME format. --------------020205020603040605050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I propose to remove that dataLinkFrameSection I.E. We inserted that one to be complete. When the specific need will be required, then a request to IANA will have to be done. And I think that there is a high chance that L2 specific section (ethernet, dot1Q, etc..) will be requested, which will solve the current issue of a vague definition. Regards, Benoit > Hi Paul, > > On 17.07.08 10:50 "Paul Aitken" wrote: > > >> Juergen, >> >> >>> I would create EthernetFrameSize, EthernetFrameSection, wlanFrameSize, >>> wlanFrameSection, wimaxBurstSize, wimaxBurstSection, mplspacketsize (if >>> we don't have it already), etc. >>> >> That's exactly what I *wouldn't* do. >> >> >>> These would all be self-contained and none of them would need any >>> further IEs for interpreting their content. >>> >> By the same token we should throw away all the L3 fields and retain just >> the IPv4packetSection and IPv6packetSection - since these are both >> "self-contained and none of them would need any further IEs for >> interpreting their content". >> >> Clearly it makes no sense at all. >> > > I think it makes a lot of sense. > > All of the Information Elements we standardized so far are > self-contained. Packet sections with an unspecified number of > padding octets and linkLayerFrameSections for an unspecified link > layer technology would be the first ones that are not self-contained. > In order to read the full content you need to have another IE that > tells you the the use link layer technology or length of the padding, > respectively. > > I would not be happy with introducing such a new class of IEs that > are only readable in the presence of others. > > >> As I recall, the previous IPFIX charter said something about defining >> all the fields that are required for the information model. I guess >> there was an assumption that this wouldn't be a minimalistic set of >> packet/frame sections. >> > > Definitely not. We have different IEs for v4 and v6. There is no general > problem with having different IEs for Ethernet and WLAN. > > Juergen > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www.ietf.org/mailman/listinfo/psamp > --------------020205020603040605050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I propose to remove that dataLinkFrameSection I.E.
We inserted that one to be complete.
When the specific need will be required, then a request to IANA will have to be done. And I think that there is a high chance that L2 specific section (ethernet, dot1Q, etc..) will be requested, which will solve the current issue of a vague definition.

Regards, Benoit



  
Hi Paul,

On 17.07.08 10:50  "Paul Aitken" <paitken@cisco.com> wrote:

  

  

    
Juergen,

    

    

      
I would create EthernetFrameSize, EthernetFrameSection, wlanFrameSize,
wlanFrameSection, wimaxBurstSize, wimaxBurstSection, mplspacketsize (if
we don't have it already), etc.
      

    

    
That's exactly what I *wouldn't* do.

    

    

      
These would all be self-contained and none of them would need any
further IEs for interpreting their content.
      

    

    
By the same token we should throw away all the L3 fields and retain just
the IPv4packetSection and IPv6packetSection - since these are both
"self-contained and none of them would need any further IEs for
interpreting their content".

Clearly it makes no sense at all.
    

  

  

I think it makes a lot of sense.

All of the Information Elements we standardized so far are
self-contained.   Packet sections with an unspecified number of
padding octets and linkLayerFrameSections for an unspecified link
layer technology would be the first ones that are not self-contained.
In order to read the full content you need to have another IE that
tells you the the use link layer technology or length of the padding,
respectively.

I would not be happy with introducing such a new class of IEs that
are only readable in the presence of others.
 
  

  

    
As I recall, the previous IPFIX charter said something about defining
all the fields that are required for the information model. I guess
there was an assumption that this wouldn't be a minimalistic set of
packet/frame sections.
    

  

  

Definitely not. We have different IEs for v4 and v6. There is no general
problem with having different IEs for Ethernet and WLAN.

    Juergen

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp
  








--------------020205020603040605050804--

--===============0024374158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp

--===============0024374158==--


From psamp-bounces@ietf.org  Wed Jul 30 09:48:32 2008
Return-Path: 
X-Original-To: psamp-text-archive@optimus.ietf.org
Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7B3D83A6B48;
	Wed, 30 Jul 2008 09:48:32 -0700 (PDT)
X-Original-To: psamp@core3.amsl.com
Delivered-To: psamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D48DB3A67C0
	for ; Wed, 30 Jul 2008 09:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.091
X-Spam-Level: 
X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.508, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 41nQ+4bCYUr7 for ;
	Wed, 30 Jul 2008 09:48:28 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140])
	by core3.amsl.com (Postfix) with ESMTP id E8C0628C39B
	for ; Wed, 30 Jul 2008 09:48:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,280,1215388800"; d="scan'208";a="15833536"
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 30 Jul 2008 16:48:32 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UGmVbE030180
	for ; Wed, 30 Jul 2008 18:48:31 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UGmVaX017934
	for ; Wed, 30 Jul 2008 16:48:31 GMT
Received: from [10.61.96.214] (dhcp-10-61-96-214.cisco.com [10.61.96.214])
	by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6UGmVI13396
	for ; Wed, 30 Jul 2008 17:48:31 +0100 (BST)
Message-ID: <48909B5F.8030909@cisco.com>
Date: Wed, 30 Jul 2008 17:48:31 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB;
	rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11
MIME-Version: 1.0
To: IETF PSAMP Working Group 
References: 	<487DBCF8.9030004@informatik.uni-tuebingen.de>	<547F018265F92642B577B986577D671C1AD384@VENUS.office>	<487DECAC.1060006@cisco.com>	<547F018265F92642B577B986577D671C1AD3C2@VENUS.office>
	<487E039E.308@cisco.com>
In-Reply-To: <487E039E.308@cisco.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=310; t=1217436511; x=1218300511;
	c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=paitken@cisco.com;
	z=From:=20Paul=20Aitken=20
	|Subject:=20Re=3A=20[Sender=3A=20=20psamp-bounces@ietf.org]
	=20=20Re=3A=20[PSAMP]=20PSAMP-INFO=3A=20padding=0A=20of=20re
	ported=20packet=20sections |Sender:=20;
	bh=TB455fpiN2SWToMjaI9tUiKKFhEDSdI/JjkVHHTv3aY=;
	b=XWPRAFW70FmUaw+OZQuga9kD9jUUhjKglNOrPgCFvA3AdfoQAthdhhnMwC
	d50Q4eg0p9XHglUu7t0MaI5aaujsbBsQRgwjsNzMAL+I8TyHL8oupaMLoBkI
	kGgQCFW/Oa;
Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim1002 verified; ); 
Subject: Re: [PSAMP] [Sender: psamp-bounces@ietf.org] Re: PSAMP-INFO:
 padding of reported packet sections
X-BeenThere: psamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This mailing list is used for discussion within the IETF packet
	sampling \(PSAMP\) WG" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: psamp-bounces@ietf.org
Errors-To: psamp-bounces@ietf.org

Dear All,

After discussing this issue with Juergen, I agree that the right 
solution for IPFIX is for packet sections not to be padded.

eg, variable length encoding can be used.

Unfortunately this isn't possible for netflow v9 export :-(

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp


From psamp-bounces@ietf.org  Thu Jul 31 10:05:45 2008
Return-Path: 
X-Original-To: psamp-text-archive@optimus.ietf.org
Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 108AA3A6CE8;
	Thu, 31 Jul 2008 10:05:45 -0700 (PDT)
X-Original-To: psamp@core3.amsl.com
Delivered-To: psamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B9FE43A6ACC
	for ; Thu, 31 Jul 2008 10:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.264
X-Spam-Level: 
X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[AWL=0.984, 
	BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001,
	RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id MbYfciMLRYUp for ;
	Thu, 31 Jul 2008 10:05:42 -0700 (PDT)
Received: from mailgwb1.fraunhofer.de (mailgwb1.fraunhofer.de [153.96.87.18])
	by core3.amsl.com (Postfix) with ESMTP id C63133A6D05
	for ; Thu, 31 Jul 2008 10:05:41 -0700 (PDT)
Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1])
	by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id
	m6VH5oRr026619; Thu, 31 Jul 2008 19:05:50 +0200 (CEST)
Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de
	[195.37.77.164])
	by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m6VH5oVQ026606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 31 Jul 2008 19:05:50 +0200 (CEST)
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id
	m6VH5la2023549; Thu, 31 Jul 2008 19:05:48 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 19:05:48 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PSAMP-INFO IE realtiveError 
Thread-Index: AcjzK+BlHTeSGZsoReewZs1Reqy41Q==
From: "Zseby, Tanja" 
To: "Benoit Claise" , "Paul Aitken" 
X-Fraunhofer-Email-Policy: accepted
Cc: psamp , Juergen Quittek 
Subject: [PSAMP] PSAMP-INFO IE realtiveError
X-BeenThere: psamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This mailing list is used for discussion within the IETF packet
	sampling \(PSAMP\) WG" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1762806517=="
Sender: psamp-bounces@ietf.org
Errors-To: psamp-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1762806517==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8F32F.ADC77689"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F32F.ADC77689
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Benoit and Paul,

=20

here my suggestions for clarification of the error IEs in PSAMP-INFO.

-    I suggest to rename the fixedError to absoluteError

-    I suggest to introduce CI limits and level to also report
estimation errors

-    If it is still possible I would suggest to make a few small changes
in PSAMP-PROTO for consistency.

-    Upper and lower CI limits can be also specified as provided
absolute or relative limits. So we could also add 2 more IEs (for the
relative CI limits)

=20

New description of IEs:

=20

absoluteError

This Information Element specifies the maximum possible measurement
error of the reported value for a given Information Element. The
absoluteError has the same unit as the information element it is
associated to. The real value of the metric can differ by absoluteError
(positive or negative) from the measured value. This information element
provides only the error for measured values. If an information element
contains an estimated values (from sampling) the confidence boundaries
and confidence level have to be provided instead.

=20

relativeError

This Information Element specifies the maximum possible measurement
error of the reported value for a given Information Element as
percentage of the measured value. The real value of the metric can
differ by relativeError percent (positive or negative) from the measured
value. This information element provides only the error for measured
values. If an information element contains an estimated values (from
sampling) the confidence boundaries and confidence level have to be
provided instead.

=20

upperCILimit

This Information Element specifies the upper limit of a confidence
interval. It is used to provide an accuracy statement for an estimated
value. The confidence limits define the range in which the real value is
assumed to be with a certain probability p. Confidence limits always
need to be associated with a confidence level that defines this
probability p. Please note that a confidence interval only provides a
probability that the real values lies within the limits. That means the
real value can lie outside the confidence limits.

=20

lowerCILimit

This Information Element specifies the lower limit of a confidence
interval. For further information see the description of upperCILimit.

=20

confidenceLevel

This Information Element specifies the confidence level. It is used to
provide an accuracy statement for estimated values. The confidence level
provides the probability p with which the real value lies within a given
range. A confidence level always needs to be associated with confidence
limits that define the range in which the real value is assumed to be.

=20

=20

Changes to PSAMP-PROTO if still possible:

=20

-    Rename fixedError to absoluteError

-    Slightly modify paragraph 2

OLD:

...  The accuracy SHOULD be reported either with the fixedError
Information Element [PSAMP-INFO

], or with the relativeError Information Element [PSAMP-INFO

].

NEW:

... The accuracy for a measured information elelment SHOULD be reported
either with the fixedError Information Element [PSAMP-INFO

], or with the relativeError Information Element [PSAMP-INFO

]. The accuracy for an estimated information element (from sampling)
SHOULD be reported with confidence limits and confidence
level.[PSAMP-INFO]

=20

-    Remove the following paragraph (very important! Otherwise it would
lead to confusion):

For example, the accuracy of an Information Element to estimate the
accuracy of a sampled flow, for which the unit would be specified in
octets, can be specified with the relativeError Information Element with
the octet units.  In this case, the error interval is the Information
Element value +/- the value reported in the relativeError times the
reported Information Element value.

=20

-    Avoid the term error interval

OLD:=20

In this case, the error interval is the Information Element value +/-
the value reported in the fixedError.

NEW:=20

In this case, the real values lies within the range of the Information
Element value +/- the value reported in the absoluteError.

=20

=20

-    Remove the following paragraph (since absolute or relative error
are just different representations I would not gain something if I
report both)

Alternatively to reporting either the fixedError Information Element or
the relativeError Information Element in the Accuracy Report
Interpretation, both Information Elements MAY be present.  This scenario
could help in more complex situations where the system clock drifts, on
the top of having its own accuracy, during the duration of a
measurement.

=20

Sorry for the late comments, I was quite busy with PSAMP-TECH before...

=20

Kind regards,

Tanja

=20

=20


------_=_NextPart_001_01C8F32F.ADC77689
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi
Benoit and Paul,



 



here
my suggestions for clarification of the error IEs in =
PSAMP-INFO.



-    =
I suggest to rename =
the
fixedError to absoluteError



-    =
I suggest to =
introduce CI
limits and level to also report estimation errors



-    =
If it is still =
possible I
would suggest to make a few small changes in PSAMP-PROTO for =
consistency.



-    =
Upper and lower CI =
limits
can be also specified as provided absolute or relative limits. So we =
could also
add 2 more IEs (for the relative CI limits)



 



New
description of IEs:



 



absoluteError



This
Information Element specifies the maximum possible measurement error of =
the
reported value for a given Information Element. The absoluteError has =
the same unit
as the information element it is associated to. The real value of the =
metric
can differ by absoluteError (positive or negative) from the measured =
value.
This information element provides only the error for measured values. If =
an
information element contains an estimated values (from sampling) the =
confidence
boundaries and confidence level have to be provided =
instead.



 



relativeError



This
Information Element specifies the maximum possible measurement error of =
the
reported value for a given Information Element as percentage of the =
measured
value. The real value of the metric can differ by relativeError percent
(positive or negative) from the measured value. This information element
provides only the error for measured values. If an information element =
contains
an estimated values (from sampling) the confidence boundaries and =
confidence
level have to be provided instead.



 



upperCILimit



This
Information Element specifies the upper limit of a confidence interval. =
It is
used to provide an accuracy statement for an estimated value. The =
confidence
limits define the range in which the real value is assumed to be with a =
certain
probability p. Confidence limits always need to be associated with a =
confidence
level that defines this probability p. Please note that a confidence =
interval
only provides a probability that the real values lies within the limits. =
That
means the real value can lie outside the confidence =
limits.



 



lowerCILimit



This
Information Element specifies the lower limit of a confidence interval. =
For
further information see the description of =
upperCILimit.



 



confidenceLevel



This
Information Element specifies the confidence level. It is used to =
provide an
accuracy statement for estimated values. The confidence level provides =
the
probability p with which the real value lies within a given range. A =
confidence
level always needs to be associated with confidence limits that define =
the
range in which the real value is assumed to be.



 



 



Changes
to PSAMP-PROTO if still possible:



 



-    =
Rename fixedError =
to
absoluteError



-    =
Slightly modify =
paragraph 2



OLD:



... 
The accuracy SHOULD be reported either with the fixedError Information =
Element
[PSAMP-INFO],
or with the relativeError Information Element [PSAMP-INFO].



NEW:



...
The accuracy for a measured information elelment SHOULD be reported =
either with
the fixedError Information Element [PSAMP-INFO],
or with the relativeError Information Element [PSAMP-INFO].
The accuracy for an estimated information element (from sampling) SHOULD =
be
reported with confidence limits and confidence =
level.[PSAMP-INFO]



 



-    =
Remove the =
following
paragraph (very important! Otherwise it would lead to =
confusion):



For
example, the accuracy of an Information Element to estimate the accuracy =
of a
sampled flow, for which the unit would be specified in octets, can be =
specified
with the relativeError Information Element with the octet units.  =
In this case,
the error interval is the Information Element value +/- the value =
reported in
the relativeError times the reported Information Element =
value.



 



-    =
Avoid the term =
error
interval



OLD:




In
this case, the error interval is the Information Element value +/- the =
value
reported in the fixedError.



NEW:




In
this case, the real values lies within the range of the Information =
Element
value +/- the value reported in the absoluteError.



 



 



-    =
Remove the =
following
paragraph (since absolute or relative error are just different =
representations
I would not gain something if I report both)



Alternatively
to reporting either the fixedError Information Element or the =
relativeError
Information Element in the Accuracy Report Interpretation, both =
Information
Elements MAY be present.  This scenario could help in more complex =
situations
where the system clock drifts, on the top of having its own accuracy, =
during
the duration of a measurement.



 



Sorry
for the late comments, I was quite busy with PSAMP-TECH =
before...



 



Kind
regards,



Tanja



 



 









------_=_NextPart_001_01C8F32F.ADC77689--

--===============1762806517==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp

--===============1762806517==--


From psamp-bounces@ietf.org  Thu Jul 31 15:46:44 2008
Return-Path: 
X-Original-To: psamp-text-archive@optimus.ietf.org
Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EDB9D3A6AB6;
	Thu, 31 Jul 2008 15:46:44 -0700 (PDT)
X-Original-To: psamp@core3.amsl.com
Delivered-To: psamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D5F093A6AB6
	for ; Thu, 31 Jul 2008 15:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.667
X-Spam-Level: 
X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5
	tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id uQnre7VQionc for ;
	Thu, 31 Jul 2008 15:46:42 -0700 (PDT)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119])
	by core3.amsl.com (Postfix) with ESMTP id 8F2E93A67A5
	for ; Thu, 31 Jul 2008 15:46:41 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m6VMkT402377; Fri, 1 Aug 2008 00:46:29 +0200 (CEST)
Received: from [10.61.96.241] (dhcp-10-61-96-241.cisco.com [10.61.96.241])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m6VMkFA15925; Fri, 1 Aug 2008 00:46:15 +0200 (CEST)
Message-ID: <489240B1.8090803@cisco.com>
Date: Thu, 31 Jul 2008 23:46:09 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: "Zseby, Tanja" 
References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de>
In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de>
Cc: psamp , Juergen Quittek 
Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
X-BeenThere: psamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This mailing list is used for discussion within the IETF packet
	sampling \(PSAMP\) WG" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0945775166=="
Sender: psamp-bounces@ietf.org
Errors-To: psamp-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0945775166==
Content-Type: multipart/alternative;
 boundary="------------000704040401070604080905"

This is a multi-part message in MIME format.
--------------000704040401070604080905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tanja,
>
> Hi Benoit and Paul,
>
>  
>
> here my suggestions for clarification of the error IEs in PSAMP-INFO.
>
> -    I suggest to rename the fixedError to absoluteError
>
No problem with that, but [PSAMP-PROTO] must follow otherwise we have a 
problem
Can we still change that in AUTH48 maybe?
>
> -    I suggest to introduce CI limits and level to also report 
> estimation errors
>
I'm wondering whether this is a good idea to add upperCILimit, 
lowerCILimit, and confidenceLevel at this stage.
Because it implies that we need a complete new section in [PSAMP-PROTO] 
(as opposed to just editorial change) similar to "Accuracy Report 
Interpretation" but for the accuracy statement for estimated value. 
Now, the simple solution is to add the information elements in 
PSAMP-INFO and don't discuss the accuracy statement for estimated value 
in [PSAMP-PROTO].
>
> -    If it is still possible I would suggest to make a few small 
> changes in PSAMP-PROTO for consistency.
>
> -    Upper and lower CI limits can be also specified as provided 
> absolute or relative limits. So we could also add 2 more IEs (for the 
> relative CI limits)
>
>  
>
> New description of IEs:
>
>  
>
> absoluteError
>
> This Information Element specifies the maximum possible measurement 
> error of the reported value for a given Information Element. The 
> absoluteError has the same unit as the information element it is 
> associated to. The real value of the metric can differ by 
> absoluteError (positive or negative) from the measured value. This 
> information element provides only the error for measured values. If an 
> information element contains an estimated values (from sampling) the 
> confidence boundaries and confidence level have to be provided instead.
>
>  
>
> relativeError
>
> This Information Element specifies the maximum possible measurement 
> error of the reported value for a given Information Element as 
> percentage of the measured value. The real value of the metric can 
> differ by relativeError percent (positive or negative) from the 
> measured value. This information element provides only the error for 
> measured values. If an information element contains an estimated 
> values (from sampling) the confidence boundaries and confidence level 
> have to be provided instead.
>
I like your suggestions for absoluteError and relativeError because 
something that was not clear (neither from PSAMP-PROTO or PSAMP-INFO) is 
that we wanted to quantify the accuracy of the measurement estimation, 
as opposed to the accuracy of the estimated value
>
>  
>
> upperCILimit
>
> This Information Element specifies the upper limit of a confidence 
> interval. It is used to provide an accuracy statement for an estimated 
> value. The confidence limits define the range in which the real value 
> is assumed to be with a certain probability p. Confidence limits 
> always need to be associated with a confidence level that defines this 
> probability p. Please note that a confidence interval only provides a 
> probability that the real values lies within the limits. That means 
> the real value can lie outside the confidence limits.
>
>  
>
> lowerCILimit
>
> This Information Element specifies the lower limit of a confidence 
> interval. For further information see the description of upperCILimit.
>
>  
>
> confidenceLevel
>
> This Information Element specifies the confidence level. It is used to 
> provide an accuracy statement for estimated values. The confidence 
> level provides the probability p with which the real value lies within 
> a given range. A confidence level always needs to be associated with 
> confidence limits that define the range in which the real value is 
> assumed to be.
>
>  
>
>  
>
> Changes to PSAMP-PROTO if still possible:
>
>  
>
> -    Rename fixedError to absoluteError
>
> -    Slightly modify paragraph 2
>
> OLD:
>
> ...  The accuracy SHOULD be reported either with the fixedError 
> Information Element [PSAMP-INFO 
> ], 
> or with the relativeError Information Element [PSAMP-INFO 
> ].
>
> NEW:
>
> ... The accuracy for a measured information elelment SHOULD be 
> reported either with the fixedError Information Element [PSAMP-INFO 
> ], 
> or with the relativeError Information Element [PSAMP-INFO 
> ]. 
> T
>
To be consistent with my statement above, I would not add the following 
sentence.
>
> he accuracy for an estimated information element (from sampling) 
> SHOULD be reported with confidence limits and confidence 
> level.[PSAMP-INFO]
>
>  
>
> -    Remove the following paragraph (very important! Otherwise it 
> would lead to confusion):
>
> For example, the accuracy of an Information Element to estimate the 
> accuracy of a sampled flow, for which the unit would be specified in 
> octets, can be specified with the relativeError Information Element 
> with the octet units.  In this case, the error interval is the 
> Information Element value +/- the value reported in the relativeError 
> times the reported Information Element value.
>
>  
>
> -    Avoid the term error interval
>
> OLD:
>
> In this case, the error interval is the Information Element value +/- 
> the value reported in the fixedError.
>
> NEW:
>
> In this case, the real values lies within the range of the Information 
> Element value +/- the value reported in the absoluteError.
>
>  
>
>  
>
> -    Remove the following paragraph (since absolute or relative error 
> are just different representations I would not gain something if I 
> report both)
>
> Alternatively to reporting either the fixedError Information Element 
> or the relativeError Information Element in the Accuracy Report 
> Interpretation, both Information Elements MAY be present.  This 
> scenario could help in more complex situations where the system clock 
> drifts, on the top of having its own accuracy, during the duration of 
> a measurement.
>
I would also change "Accuracy Report Interpretation" into "Measurement 
Accuracy Report Interpretation" in  [PSAMP-PROTO]

Regards, Benoit.
>
>  
>
> Sorry for the late comments, I was quite busy with PSAMP-TECH before...
>
>  
>
> Kind regards,
>
> Tanja
>
>  
>
>  
>


--------------000704040401070604080905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Hi Tanja,



  
  
  

  

  
Hi
Benoit and Paul,

  
 

  
here
my suggestions for clarification of the error IEs in PSAMP-INFO.

  
-   
  I suggest to
rename the
fixedError to absoluteError

  



No problem with that, but [PSAMP-PROTO] must follow otherwise we have a
problem

Can we still change that in AUTH48 maybe?



  

  

  
-   
  I suggest to
introduce CI
limits and level to also report estimation errors

  



I'm wondering whether this is a good idea to add upperCILimit,
lowerCILimit, and confidenceLevel
at this stage.

Because it implies that we need a complete new section in [PSAMP-PROTO]
(as opposed to just editorial change) similar to "Accuracy Report
Interpretation" but for the accuracy statement for estimated value.  

Now, the simple solution is to add the information elements in
PSAMP-INFO and don't discuss the accuracy statement for estimated value
in [PSAMP-PROTO]. 




  

  

  
-   
  If it is still
possible I
would suggest to make a few small changes in PSAMP-PROTO for
consistency.

  
-   
  Upper and lower
CI limits
can be also specified as provided absolute or relative limits. So we
could also
add 2 more IEs (for the relative CI limits)

  
 

  
New
description of IEs:

  
 

  
absoluteError

  
This
Information Element specifies the maximum possible measurement error of
the
reported value for a given Information Element. The absoluteError has
the same unit
as the information element it is associated to. The real value of the
metric
can differ by absoluteError (positive or negative) from the measured
value.
This information element provides only the error for measured values.
If an
information element contains an estimated values (from sampling) the
confidence
boundaries and confidence level have to be provided instead.

  
 

  
relativeError

  
This
Information Element specifies the maximum possible measurement error of
the
reported value for a given Information Element as percentage of the
measured
value. The real value of the metric can differ by relativeError percent
(positive or negative) from the measured value. This information
element
provides only the error for measured values. If an information element
contains
an estimated values (from sampling) the confidence boundaries and
confidence
level have to be provided instead.

  



I like your suggestions for absoluteError and
relativeError
because something that was not clear (neither
from PSAMP-PROTO or PSAMP-INFO) is that we wanted to quantify the
accuracy of the measurement estimation, as opposed to the accuracy of
the estimated value



  

  

  
 

  
upperCILimit

  
This
Information Element specifies the upper limit of a confidence interval.
It is
used to provide an accuracy statement for an estimated value. The
confidence
limits define the range in which the real value is assumed to be with a
certain
probability p. Confidence limits always need to be associated with a
confidence
level that defines this probability p. Please note that a confidence
interval
only provides a probability that the real values lies within the
limits. That
means the real value can lie outside the confidence limits.

  
 

  
lowerCILimit

  
This
Information Element specifies the lower limit of a confidence interval.
For
further information see the description of upperCILimit.

  
 

  
confidenceLevel

  
This
Information Element specifies the confidence level. It is used to
provide an
accuracy statement for estimated values. The confidence level provides
the
probability p with which the real value lies within a given range. A
confidence
level always needs to be associated with confidence limits that define
the
range in which the real value is assumed to be.

  
 

  
 

  
Changes
to PSAMP-PROTO if still possible:

  
 

  
-   
  Rename fixedError
to
absoluteError

  
-   
  Slightly modify
paragraph 2

  
OLD:

  
... 
The accuracy SHOULD be reported either with the fixedError Information
Element
[PSAMP-INFO],
or with the relativeError Information Element [PSAMP-INFO].

  
NEW:

  
...
The accuracy for a measured information elelment SHOULD be reported
either with
the fixedError Information Element [PSAMP-INFO],
or with the relativeError Information Element [PSAMP-INFO].
T

  



To be consistent with my statement above, I would not add the following
sentence.



  

  
he accuracy for
an estimated information element (from sampling) SHOULD be
reported with confidence limits and confidence level.[PSAMP-INFO]

  
 

  
-   
  Remove the
following
paragraph (very important! Otherwise it would lead to confusion):

  
For
example, the accuracy of an Information Element to estimate the
accuracy of a
sampled flow, for which the unit would be specified in octets, can be
specified
with the relativeError Information Element with the octet units.  In
this case,
the error interval is the Information Element value +/- the value
reported in
the relativeError times the reported Information Element value.

  
 

  
-   
  Avoid the term
error
interval

  
OLD:
  

  
In
this case, the error interval is the Information Element value +/- the
value
reported in the fixedError.

  
NEW:
  

  
In
this case, the real values lies within the range of the Information
Element
value +/- the value reported in the absoluteError.

  
 

  
 

  
-   
  Remove the
following
paragraph (since absolute or relative error are just different
representations
I would not gain something if I report both)

  
Alternatively
to reporting either the fixedError Information Element or the
relativeError
Information Element in the Accuracy Report Interpretation, both
Information
Elements MAY be present.  This scenario could help in more complex
situations
where the system clock drifts, on the top of having its own accuracy,
during
the duration of a measurement.

  



I would also change "Accuracy Report Interpretation" into "Measurement
Accuracy Report Interpretation" in  [PSAMP-PROTO] 



Regards, Benoit.



  

  

  
 

  
Sorry
for the late comments, I was quite busy with PSAMP-TECH before...

  
 

  
Kind
regards,

  
Tanja

  
 

  
 

  








--------------000704040401070604080905--

--===============0945775166==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp

--===============0945775166==--


From psamp-bounces@ietf.org  Fri Aug  1 01:30:28 2008
Return-Path: 
X-Original-To: psamp-text-archive@optimus.ietf.org
Delivered-To: ietfarch-psamp-text-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8D1D128C2DF;
	Fri,  1 Aug 2008 01:30:28 -0700 (PDT)
X-Original-To: psamp@core3.amsl.com
Delivered-To: psamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7880528C2DF
	for ; Fri,  1 Aug 2008 01:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.593
X-Spam-Level: 
X-Spam-Status: No, score=-5.593 tagged_above=-999 required=5 tests=[AWL=0.656, 
	BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id hFT7QDmadpEP for ;
	Fri,  1 Aug 2008 01:30:26 -0700 (PDT)
Received: from mailgw1.fraunhofer.de (mailgw1.fraunhofer.de [153.96.1.17])
	by core3.amsl.com (Postfix) with ESMTP id 059AB3A6AD6
	for ; Fri,  1 Aug 2008 01:30:25 -0700 (PDT)
Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1])
	by mailgw1.fraunhofer.de[host mailgw24] (8.14.2+/8.14.2) with ESMTP id
	m718So8Y005335; Fri, 1 Aug 2008 10:28:50 +0200 (CEST)
Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de
	[195.37.77.164])
	by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m718SngM005331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Aug 2008 10:28:50 +0200 (CEST)
Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231])
	by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id
	m718Smss002144; Fri, 1 Aug 2008 10:28:48 +0200 (MEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 1 Aug 2008 10:28:44 +0200
Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A607@EXCHSRV.fokus.fraunhofer.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PSAMP] PSAMP-INFO IE realtiveError
Thread-Index: AcjzX1+jbdnY7+Z8QSCcn2o21oD8ygAUIUTQ
References: <804B13F8F3D94A4AB18B9B01ACB68FA101F5A5F9@EXCHSRV.fokus.fraunhofer.de>
	<489240B1.8090803@cisco.com>
From: "Zseby, Tanja" 
To: "Benoit Claise" 
X-Fraunhofer-Email-Policy: accepted
Cc: psamp , Juergen Quittek 
Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
X-BeenThere: psamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This mailing list is used for discussion within the IETF packet
	sampling \(PSAMP\) WG" 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: psamp-bounces@ietf.org
Errors-To: psamp-bounces@ietf.org

Hi Benoit,

I think we need no new section in PSAMP-PROTO and can only introduce the
CI limits in PSAMP-INFO. We can stick with the example in PSAMP-PROTO
but need to clarify that the example is only for the accuracy of
measured values. That means mainly to remove the 2 sentences that refer
to estimation error. It depends how much we can still change in
PSAMP-PROTO. Is removing 2 sentences o.k.?

Kind regards
Tanja

> -----Original Message-----
> From: psamp-bounces@ietf.org [mailto:psamp-bounces@ietf.org] On Behalf
> Of Benoit Claise
> Sent: Friday, August 01, 2008 12:46 AM
> To: Zseby, Tanja
> Cc: psamp; Juergen Quittek
> Subject: Re: [PSAMP] PSAMP-INFO IE realtiveError
> 
> Hi Tanja,
> 
> 
> 	Hi Benoit and Paul,
> 
> 
> 
> 	here my suggestions for clarification of the error IEs in PSAMP-
> INFO.
> 
> 	-    I suggest to rename the fixedError to absoluteError
> 
> No problem with that, but [PSAMP-PROTO] must follow otherwise we have
a
> problem Can we still change that in AUTH48 maybe?
> 
> 
> 
> 
> 	-    I suggest to introduce CI limits and level to also report
> estimation errors
> 
> I'm wondering whether this is a good idea to add upperCILimit,
> lowerCILimit, and confidenceLevel at this stage.
> Because it implies that we need a complete new section in
[PSAMP-PROTO]
> (as opposed to just editorial change) similar to "Accuracy Report
> Interpretation" but for the accuracy statement for estimated value.
> Now, the simple solution is to add the information elements in PSAMP-
> INFO and don't discuss the accuracy statement for estimated value in
> [PSAMP-PROTO].
> 
> 
> 
> 
> 	-    If it is still possible I would suggest to make a few small
> changes in PSAMP-PROTO for consistency.
> 
> 	-    Upper and lower CI limits can be also specified as provided
> absolute or relative limits. So we could also add 2 more IEs (for the
> relative CI limits)
> 
> 
> 
> 	New description of IEs:
> 
> 
> 
> 	absoluteError
> 
> 	This Information Element specifies the maximum possible
> measurement error of the reported value for a given Information
> Element. The absoluteError has the same unit as the information
element
> it is associated to. The real value of the metric can differ by
> absoluteError (positive or negative) from the measured value. This
> information element provides only the error for measured values. If an
> information element contains an estimated values (from sampling) the
> confidence boundaries and confidence level have to be provided
instead.
> 
> 
> 
> 	relativeError
> 
> 	This Information Element specifies the maximum possible
> measurement error of the reported value for a given Information
Element
> as percentage of the measured value. The real value of the metric can
> differ by relativeError percent (positive or negative) from the
> measured value. This information element provides only the error for
> measured values. If an information element contains an estimated
values
> (from sampling) the confidence boundaries and confidence level have to
> be provided instead.
> 
> I like your suggestions for absoluteError and relativeError because
> something that was not clear (neither from PSAMP-PROTO or PSAMP-INFO)
> is that we wanted to quantify the accuracy of the measurement
> estimation, as opposed to the accuracy of the estimated value
> 
> 
> 
> 
> 
> 
> 	upperCILimit
> 
> 	This Information Element specifies the upper limit of a
> confidence interval. It is used to provide an accuracy statement for
an
> estimated value. The confidence limits define the range in which the
> real value is assumed to be with a certain probability p. Confidence
> limits always need to be associated with a confidence level that
> defines this probability p. Please note that a confidence interval
only
> provides a probability that the real values lies within the limits.
> That means the real value can lie outside the confidence limits.
> 
> 
> 
> 	lowerCILimit
> 
> 	This Information Element specifies the lower limit of a
> confidence interval. For further information see the description of
> upperCILimit.
> 
> 
> 
> 	confidenceLevel
> 
> 	This Information Element specifies the confidence level. It is
> used to provide an accuracy statement for estimated values. The
> confidence level provides the probability p with which the real value
> lies within a given range. A confidence level always needs to be
> associated with confidence limits that define the range in which the
> real value is assumed to be.
> 
> 
> 
> 
> 
> 	Changes to PSAMP-PROTO if still possible:
> 
> 
> 
> 	-    Rename fixedError to absoluteError
> 
> 	-    Slightly modify paragraph 2
> 
> 	OLD:
> 
> 	...  The accuracy SHOULD be reported either with the fixedError
> Information Element [PSAMP-INFO
 psamp-protocol-09#ref-PSAMP-INFO> ], or with the relativeError
> Information Element [PSAMP-INFO
 psamp-protocol-09#ref-PSAMP-INFO> ].
> 
> 	NEW:
> 
> 	... The accuracy for a measured information elelment SHOULD be
> reported either with the fixedError Information Element [PSAMP-INFO
>  INFO> ], or with the relativeError Information Element [PSAMP-INFO
>  INFO> ]. T
> 
> To be consistent with my statement above, I would not add the
following
> sentence.
> 
> 
> 	he accuracy for an estimated information element (from sampling)
> SHOULD be reported with confidence limits and confidence level.[PSAMP-
> INFO]
> 
> 
> 
> 	-    Remove the following paragraph (very important! Otherwise
it
> would lead to confusion):
> 
> 	For example, the accuracy of an Information Element to estimate
> the accuracy of a sampled flow, for which the unit would be specified
> in octets, can be specified with the relativeError Information Element
> with the octet units.  In this case, the error interval is the
> Information Element value +/- the value reported in the relativeError
> times the reported Information Element value.
> 
> 
> 
> 	-    Avoid the term error interval
> 
> 	OLD:
> 
> 	In this case, the error interval is the Information Element
value
> +/- the value reported in the fixedError.
> 
> 	NEW:
> 
> 	In this case, the real values lies within the range of the
> Information Element value +/- the value reported in the absoluteError.
> 
> 
> 
> 
> 
> 	-    Remove the following paragraph (since absolute or relative
> error are just different representations I would not gain something if
> I report both)
> 
> 	Alternatively to reporting either the fixedError Information
> Element or the relativeError Information Element in the Accuracy
Report
> Interpretation, both Information Elements MAY be present.  This
> scenario could help in more complex situations where the system clock
> drifts, on the top of having its own accuracy, during the duration of
a
> measurement.
> 
> I would also change "Accuracy Report Interpretation" into "Measurement
> Accuracy Report Interpretation" in  [PSAMP-PROTO]
> 
> Regards, Benoit.
> 
> 
> 
> 
> 
> 
> 	Sorry for the late comments, I was quite busy with PSAMP-TECH
> before...
> 
> 
> 
> 	Kind regards,
> 
> 	Tanja
> 
> 
> 
> 
> 

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org
https://www.ietf.org/mailman/listinfo/psamp