From psamp-bounces@ietf.org Fri Oct 13 10:03:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNcP-0000Jw-1P; Fri, 13 Oct 2006 10:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNcO-0000Jp-EV for psamp@ietf.org; Fri, 13 Oct 2006 10:02:32 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYNcK-0006ql-07 for psamp@ietf.org; Fri, 13 Oct 2006 10:02:32 -0400 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 k9DE2R419205; Fri, 13 Oct 2006 16:02:27 +0200 (CEST) Received: from [10.61.81.80] (ams3-vpn-dhcp4433.cisco.com [10.61.81.80]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id k9DE2QP02027; Fri, 13 Oct 2006 16:02:26 +0200 (CEST) Message-ID: <452F9C72.1000803@cisco.com> Date: Fri, 13 Oct 2006 16:02:26 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Schmoll, Carsten" References: <70524A4436C03E43A293958B505008B637A04F@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B637A04F@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: psamp Subject: [PSAMP] Re: small typos in PSAMP-PROTO X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: psamp-bounces@ietf.org Carsten, Thanks for reading the draft. Your editorial modifications are inserted. Regards, Benoit. > FYI > > wrt. > http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-06.txt > > line 1905: > If the full set of statistics is not sent *as* part of the Basic > Packet > > line 2076: > time*s* the reported Information Element value. > > regards > Carsten > > > > -- > "The difference between theory and practice is that in theory > theory and practice are the same but in practice they are not." > > Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS > schmoll@fokus.fraunhofer.de National Research Institute > Fraunhofer FOKUS / dept. ANTS for Open Communication Systems > Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 > Fax: +49-30-3463-8000 D-10589 Berlin, Germany > _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Oct 13 12:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPwq-0004EZ-JT; Fri, 13 Oct 2006 12:31:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPwp-0004ET-Ay for psamp@ietf.org; Fri, 13 Oct 2006 12:31:47 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYPwl-0007ju-J8 for psamp@ietf.org; Fri, 13 Oct 2006 12:31:47 -0400 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 k9DGVgE28429 for ; Fri, 13 Oct 2006 18:31:42 +0200 (CEST) Received: from [10.61.81.80] (ams3-vpn-dhcp4433.cisco.com [10.61.81.80]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id k9DGVfP22789 for ; Fri, 13 Oct 2006 18:31:41 +0200 (CEST) Message-ID: <452FBF6D.9030309@cisco.com> Date: Fri, 13 Oct 2006 18:31:41 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp X-Spam-Score: 0.1 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 Subject: [PSAMP] Metering Process and/or Selection Process X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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="===============0169773122==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0169773122== Content-Type: multipart/alternative; boundary="------------090902090509040100010901" This is a multi-part message in MIME format. --------------090902090509040100010901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tanja, all, I want to start a new email thread, discussing one of the point raised by Tanja in http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html 2: Section 3.3.1: As far as I know we agreed that we use the same metering process definition for IPFIX and PSAMP. So the only difference I see between PSAMP and IPFIX processes are the Information elements that are reported. So I found section 3.3.1. a bit confusing. Note: in Dallas, we agreed to replace the "measurement process" by the "metering process" While re-reading this section 3.3.1, I agree this is confusing. So we have to change this text/picture The figure B indicates the sequence of the processes (selection and exporting) within the PSAMP Device. +----------+ +-----------+ Observed | Metering | | Exporting | Packet--->| Process |----->| Process |--->Collector Stream +----------+ +-----------+ Figure B: PSAMP Processes The Selection Process, which takes an Observed Packet Stream as its input and produces Packet Reports as its output, is an integral part of the Metering Process, which by its definition produces Flow Records as its output. I was wondering how to change this: basically, we've got 2 choices! _Drawing 1:_ +------------------+ | Metering Process | | +-----------+ | +-----------+ Observed | | Selection | | | Exporting | Packet--->| | Process |--------->| Process |--->Collector Stream | +-----------+ | +-----------+ +------------------+ This would be consistent with the text in section 3.3.1: The Selection Process, which takes an Observed Packet Stream as its input and produces Packet Reports as its output, is an integral part of the Metering Process, which by its definition produces Flow Records as its output. _Drawing 2:_ +-----------+ +----------+ +-----------+ Observed | Selection | | Metering | | Exporting | Packet--->| Process |-->| Process |--->| Process |--->Collector Stream +-----------+ +----------+ +-----------+ Figure B: PSAMP Processes This would be consistent with the text in section 3.2.2: Selection Process A Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output. However, we quickly realize that we've an inconsistency in the following definitions; Selection Process A Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output. Report Stream The Report Stream is the output of a Selection Process, comprising two distinguished types of information: Packet Reports, and Report Interpretation. One definition says that the selection process doesn't generate the report stream while another says the reverse. To solve this issue we've got 2 solutions: _Solution 1:_ We divide the metering process into a Selection Process (Packet Stream in, Selected Packets out) and a Reporting Process (Selected Packets In, Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]: * Report Stream: The report stream is the output of a reporting process, comprising two distinguished types of information: packet reports, and report interpretation. As far as I recall, we decided to remove the Reporting Process from [PSAMP-PROTO]... This rules out solution 1. _Solution 2:_ +-----------+ +----------+ +-----------+ Observed | Selection | | Metering | | Exporting | Packet--->| Process |-->| Process |--->| Process |--->Collector Stream +-----------+ +----------+ +-----------+ Figure B: PSAMP Processes So it means that PSAMP = IPFIX + an extra Selection Process. We must update Report Stream The Report Stream is the output of a Metering (AND NOT SELECTION) Process, comprising two distinguished types of information: Packet Reports, and Report Interpretation _Solution 3: _ +------------------+ | Metering Process | | +-----------+ | +-----------+ Observed | | Selection | | | Exporting | Packet--->| | Process |--------->| Process |--->Collector Stream | +-----------+ | +-----------+ +------------------+ So the metering process: Packet Stream in, Packet Reports out. We must update Report Stream The Report Stream is the output of a Metering (AND NOT SELECTION) Process, comprising two distinguished types of information: Packet Reports, and Report Interpretation What's your preferred solution? Regards, Benoit. --------------090902090509040100010901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tanja, all,

I want to start a new email thread, discussing one of the point raised by Tanja in http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html
2: Section 3.3.1: As far as I know we agreed that we use the same metering process definition for IPFIX and PSAMP. So the only difference I see between PSAMP and IPFIX processes are the Information elements that are reported. So I found section 3.3.1. a bit confusing.
Note: in Dallas, we agreed to replace the "measurement process" by the "metering process"
While re-reading this section 3.3.1, I agree this is confusing. So we have to change this text/picture      
   The figure B indicates the sequence of the processes (selection and 
   exporting) within the PSAMP Device. 
          
                  +----------+      +-----------+ 
        Observed  | Metering |      | Exporting | 
        Packet--->| Process  |----->| Process   |--->Collector 
        Stream    +----------+      +-----------+ 
    
       Figure B: PSAMP Processes 
                          
   The Selection Process, which takes an Observed Packet Stream as its 
   input and produces Packet Reports as its output, is an integral part 
   of the Metering Process, which by its definition produces Flow 
   Records as its output.


I was wondering how to change this: basically, we've got 2 choices!
Drawing 1:
 
           +------------------+
           | Metering Process |
           | +-----------+    |     +-----------+
 Observed  | | Selection |    |     | Exporting |
 Packet--->| | Process   |--------->| Process   |--->Collector
 Stream    | +-----------+    |     +-----------+
           +------------------+

This would be consistent with the text in section 3.3.1:
The Selection Process, which takes an Observed Packet Stream as its input and produces Packet Reports as its output, is an integral part of the Metering Process, which by its definition produces Flow Records as its output.

Drawing 2:

           +-----------+   +----------+    +-----------+
 Observed  | Selection |   | Metering |    | Exporting |
 Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
 Stream    +-----------+   +----------+    +-----------+
 
    Figure B: PSAMP Processes

This would be consistent with the text in section 3.2.2: 
   Selection Process 
         
   A Selection Process takes the Observed Packet Stream as its input and 
   selects a subset of that stream as its output.




However, we quickly realize that we've an inconsistency in the following definitions;

 
   Selection Process 
         
   A Selection Process takes the Observed Packet Stream as its input and 
   selects a subset of that stream as its output. 
   Report Stream 
         
   The Report Stream is the output of a Selection Process, comprising 
   two distinguished types of information: Packet Reports, and Report 
   Interpretation.
One definition says that the selection process doesn't generate the report stream while another says the reverse.
To solve this issue we've got 2 solutions:


Solution 1:
We divide the metering process into a Selection Process (Packet Stream in, Selected Packets out) and a Reporting Process (Selected Packets In, Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]:
      * Report Stream: 
            
           The report stream is the output of a reporting process, 
           comprising two distinguished types of information: packet 
           reports, and report interpretation.
As far as I recall, we decided to remove the Reporting Process from [PSAMP-PROTO]... This rules out solution 1.

Solution 2:

           +-----------+   +----------+    +-----------+
 Observed  | Selection |   | Metering |    | Exporting |
 Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
 Stream    +-----------+   +----------+    +-----------+
 
    Figure B: PSAMP Processes

So it means that PSAMP = IPFIX + an extra Selection Process.
We must update 
   Report Stream 
         
   The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
   comprising two distinguished types of information: Packet Reports, and Report 
   Interpretation

Solution 3:

 
           +------------------+
           | Metering Process |
           | +-----------+    |     +-----------+
 Observed  | | Selection |    |     | Exporting |
 Packet--->| | Process   |--------->| Process   |--->Collector
 Stream    | +-----------+    |     +-----------+
           +------------------+

So the metering process: Packet Stream in, Packet Reports out.
We must update 
   Report Stream 
         
   The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
   comprising two distinguished types of information: Packet Reports, and Report 
   Interpretation

What's your preferred solution?

Regards, Benoit.



 

--------------090902090509040100010901-- --===============0169773122== 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://www1.ietf.org/mailman/listinfo/psamp --===============0169773122==-- From psamp-bounces@ietf.org Fri Oct 13 13:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRE1-0003nr-Tm; Fri, 13 Oct 2006 13:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRE0-0003j1-IO for psamp@ietf.org; Fri, 13 Oct 2006 13:53:36 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRDw-000641-KK for psamp@ietf.org; Fri, 13 Oct 2006 13:53:36 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3E40A125 for ; Fri, 13 Oct 2006 19:53:31 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28750-05 for ; Fri, 13 Oct 2006 19:53:28 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5ACD2115 for ; Fri, 13 Oct 2006 19:53:28 +0200 (MST) Message-ID: <452FD2D9.5030507@informatik.uni-tuebingen.de> Date: Fri, 13 Oct 2006 19:54:33 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: psamp Subject: Re: [PSAMP] Metering Process and/or Selection Process References: <452FBF6D.9030309@cisco.com> In-Reply-To: <452FBF6D.9030309@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: psamp-bounces@ietf.org Benoit, In draft-muenz-ipfix-configuration-00, I tried to combine the different aspects of an IPFIX/PSAMP Metering Process: 4.3. Metering Process Metering Processes perform the data processing within the IPFIX Device. In case that the input of a Metering Process is raw packets from Observation Points, the data are processed and transformed into exportable records. If the input is records received from Collecting Processes or other Metering Processes, the records are processed and transformed into a new stream of records. In principle, packet-based and flow-based metering can be distinguished. Various packet-based processing techniques are specified in [I-D.ietf-psamp-sample-tech], and their configurable parameters are defined in [I-D.ietf-psamp-mib]. [I-D.ietf-psamp- framework] divides the packet-based Metering Process into a packet selection process and a reporting process. This is mapped on corresponding structures in the configuration data model. Flow-based processing techniques are described in [I-D.ietf-ipfix- architecture] and [I-D.dressler-ipfix-aggregation]. [RFC3917] gives an overview on the configurable parameters. [I-D.dressler-ipfix- aggregation] proposes a description language for flow metering rules (therein called aggregation rules) that define the Flow Keys as well as the metered and exported flow attributes. This rule-based description of flow metering can also be applied to devices that do not support multiple metering rules. For example, if a device performs flow metering with a single set of Flow Keys only, this can be mapped to exactly one metering rule. All in all, the configurable parameters of a Metering Process can be summarized as follows: Packet Selection: Incoming raw packets can be processed in a sequence of filters and sampling algorithms. The possible filtering and sampling parameters are defined in [I-D.ietf-psamp-mib]. Packet Reporting: If the output of the Metering Process are records with packet- based monitoring data (or PSAMP data), the packet reporting parameters define the Information Elements that are present in the records. Flow Metering: Flow-based metering can be described by one or more metering rules. Each metering rule defines the Information Elements that are present in the resulting records. Two different types of Information Elements are distinguished: Information Elements that are used as Flow Keys and Information Elements specifying the additional information reported for each flow. The application of a metering rule can be restricted to incoming data matching given patterns. Apart from metering rules, the flow-based data processing depends on active and inactive flow timeout values that control the flow expiration. Next Pointer: The output of a Metering Process can be passed to Exporting Processes and/or to other Metering Processes. This allows mapping different realizations of the Metering Processes: PSAMP probe: Packet Selection (optional) + Packet Reporting IPFIX probe: Packet Selecton (optional) + Flow Metering Concentrator: Flow Metering (alone) Note that my considerations were based on the assumption that we combine the former PSAMP Measurement Process and the IPFIX Metering Process into a single process. Of course, there are other possibilities, e.g. defining new types of Processes as you propose. Regards, Gerhard Benoit Claise wrote: > Tanja, all, > > I want to start a new email thread, discussing one of the point raised > by Tanja in > http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html > > 2: Section 3.3.1: As far as I know we agreed that we use the same > metering process definition for IPFIX and PSAMP. So the only > difference I see between PSAMP and IPFIX processes are the > Information elements that are reported. So I found section 3.3.1. a > bit confusing. > > Note: in Dallas, we agreed to replace the "measurement process" by the > "metering process" > While re-reading this section 3.3.1, I agree this is confusing. So we > have to change this text/picture > > The figure B indicates the sequence of the processes (selection and > exporting) within the PSAMP Device. > > +----------+ +-----------+ > Observed | Metering | | Exporting | > Packet--->| Process |----->| Process |--->Collector > Stream +----------+ +-----------+ > > Figure B: PSAMP Processes > > The Selection Process, which takes an Observed Packet Stream as its > input and produces Packet Reports as its output, is an integral part > of the Metering Process, which by its definition produces Flow > Records as its output. > > > > I was wondering how to change this: basically, we've got 2 choices! > Drawing 1: > > +------------------+ > | Metering Process | > | +-----------+ | +-----------+ > Observed | | Selection | | | Exporting | > Packet--->| | Process |--------->| Process |--->Collector > Stream | +-----------+ | +-----------+ > +------------------+ > > This would be consistent with the text in section 3.3.1: > > The Selection Process, which takes an Observed Packet Stream as its > input and produces Packet Reports as its output, is an integral part > of the Metering Process, which by its definition produces Flow > Records as its output. > > Drawing 2: > > +-----------+ +----------+ +-----------+ > Observed | Selection | | Metering | | Exporting | > Packet--->| Process |-->| Process |--->| Process |--->Collector > Stream +-----------+ +----------+ +-----------+ > > Figure B: PSAMP Processes > > This would be consistent with the text in section 3.2.2: > > Selection Process > > A Selection Process takes the Observed Packet Stream as its input and > selects a subset of that stream as its output. > > > > > > However, we quickly realize that we've an inconsistency in the following > definitions; > > Selection Process > > A Selection Process takes the Observed Packet Stream as its input and > selects a subset of that stream as its output. > > Report Stream > > The Report Stream is the output of a Selection Process, comprising > two distinguished types of information: Packet Reports, and Report > Interpretation. > > > One definition says that the selection process doesn't generate the > report stream while another says the reverse. > To solve this issue we've got 2 solutions: > > > Solution 1: > We divide the metering process into a Selection Process (Packet Stream > in, Selected Packets out) and a Reporting Process (Selected Packets In, > Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]: > > * Report Stream: > > The report stream is the output of a reporting process, > comprising two distinguished types of information: packet > reports, and report interpretation. > > As far as I recall, we decided to remove the Reporting Process from > [PSAMP-PROTO]... This rules out solution 1. > > Solution 2: > > +-----------+ +----------+ +-----------+ > Observed | Selection | | Metering | | Exporting | > Packet--->| Process |-->| Process |--->| Process |--->Collector > Stream +-----------+ +----------+ +-----------+ > > Figure B: PSAMP Processes > > So it means that PSAMP = IPFIX + an extra Selection Process. > We must update > > Report Stream > > The Report Stream is the output of a Metering (AND NOT SELECTION) Process, > comprising two distinguished types of information: Packet Reports, and Report > Interpretation > > > Solution 3: > > > +------------------+ > | Metering Process | > | +-----------+ | +-----------+ > Observed | | Selection | | | Exporting | > Packet--->| | Process |--------->| Process |--->Collector > Stream | +-----------+ | +-----------+ > +------------------+ > > So the metering process: Packet Stream in, Packet Reports out. > We must update > > Report Stream > > The Report Stream is the output of a Metering (AND NOT SELECTION) Process, > comprising two distinguished types of information: Packet Reports, and Report > Interpretation > > > What's your preferred solution? > > Regards, Benoit. > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Oct 16 03:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMRY-0007CJ-S5; Mon, 16 Oct 2006 02:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMRY-0007CD-BZ for psamp@ietf.org; Mon, 16 Oct 2006 02:59:24 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZMRX-0000k6-Nq for psamp@ietf.org; Mon, 16 Oct 2006 02:59:24 -0400 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 k9G6xMS27909; Mon, 16 Oct 2006 08:59:22 +0200 (CEST) Received: from [10.61.81.92] (ams3-vpn-dhcp4445.cisco.com [10.61.81.92]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id k9G6xLP23807; Mon, 16 Oct 2006 08:59:21 +0200 (CEST) Message-ID: <45332DC9.3070105@cisco.com> Date: Mon, 16 Oct 2006 08:59:21 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tanja Zseby References: <804B13F8F3D94A4AB18B9B01ACB68FA12534B4@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA12534B4@EXCHSRV.fokus.fraunhofer.de> X-Spam-Score: 0.5 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: psamp Subject: [PSAMP] Re: PSAMP-PROTO comments X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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="===============0093944931==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0093944931== Content-Type: multipart/alternative; boundary="------------000600060103040903090803" This is a multi-part message in MIME format. --------------000600060103040903090803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id k9G6xMS27909 Hi Tanja, Thanks for reading the draft. > Hi Benoit, J=FCrgen and Andrew, > > I reviewed version 6 of the PSAMP-PROTO. I have only some minor comment= s: > > ---- > 1: Intro: " deterministic selection (filtering)" gives the impression t= hat all deterministic selection processes are called filtering, which is = not the case. Proposal: remove "(filtering)" > =20 Done. > --- > 2: Section 3.3.1: As far as I know we agreed that we use the same meter= ing process definition for IPFIX and PSAMP. So the only difference I see = between PSAMP and IPFIX processes are the Information elements that are r= eported. So I found section 3.3.1. a bit confusing. =20 > =20 See the other thread > --- > 3: Section 4: I would add a sentence after the bullet points: "In the f= ollowing sections we investigate the differences between IPFIX and PSAMP = for each of those aspects." > =20 Done. > --- > 4: Section 6: I would add an introduction in order to give an overview = for the reader. Here a proposal: > > In this section we describes the usage of the IPFIX protocol for PSAMP.= We describe the record formats and the additional requirements that must= be met. PSAMP uses two different types of messages: > - Packet Reports > - Report Interpretation=09 > The format of Packet Reports is defined in IPFIX Template Record. The P= SAMP data is transferred as Information Elements (IEs) in IPFIX Data Reco= rds as described by the Template Record. There are two different types of= Packet Reports. Basic Packet Report contain only the basic IEs required = for PSAMP reporting. Extended Packet Report MAY contain further Informati= on Elements. > The format of Report Interpretations is defined in IPFIX Option Templat= e Record. The Information Elements (IEs) are transferred in IPFIX Data Re= cords as described by the Option Template Record. There are four differen= t types of Report Interpretation messages: > - Selection Sequence Report Interpretation > - Selector Report Interpretation > - Selection Sequence Statistics Report Interpretation > - Accuracy Report Interpretation > A description and examples about the usage of those reports is given be= low. > =20 Done. > --- > 5: Section 6.4.1, second bullet point: I would re-arrange the sentences= so that it is clear, that a hash value only has to be reported if it is = generated: > If there is a digest function in the selection sequence, the Packet rep= ort MUST contain the hash value (digestHashValue) generated by the digest= hash function for each selected packet. > If there is more than one digest function then each hash value must be = included in the same order as they appear in the selection sequence. =20 > If there are no digest functions in the selection sequence no element f= or the digest needs to be sent. =20 > =20 Done. > --- > 6: section 6.5.3, paragraph 7: > "The Attained Selection Fraction for the Selection Sequence is calculat= ed by dividing the number of observed packets (packetsObserved Informatio= n Element) by the value of selected packets (packetsSelected Information = Element) for the last Selector." =20 > > was probably meant to be: > > "The Attained Selection Fraction for the Selection Sequence is calculat= ed by dividing the number of selected packets (packetsSelected Informatio= n Element) for the last Selector by the number of observed packets (packe= tsObserved Information Element)." =20 > =20 Good catch. > --- > Typos, etc.: > - section 5.1, last paragraph: "...IPFIX protocol specifications are de= scribed in" =3D=3D> "...IPFIX protocol specifications described in"=20 > - section 6.5.2.6, paragraph 12: "select those packets select those pac= kets"=20 > =20 It was there to REALLY stress that you "MUST NOT select those packets" :) Corrected. Thanks for your comments. Regards, Benoit. > > Regards, > Tanja > =20 --------------000600060103040903090803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tanja,

Thanks for reading the draft.
Hi Benoit, Jürgen and Andrew,

I reviewed version 6 of the PSAMP-PROTO. I have only some minor comments:

----
1: Intro: " deterministic selection (filtering)" gives the impression that all deterministic selection processes are called filtering, which is not the case. Proposal: remove "(filtering)"
Done.
---
2: Section 3.3.1: As far as I know we agreed that we use the same metering process definition for IPFIX and PSAMP. So the only difference I see between PSAMP and IPFIX processes are the Information elements that are reported. So I found section 3.3.1. a bit confusing.
See the other thread

---
3: Section 4: I would add a sentence after the bullet points: "In the following sections we investigate the differences between IPFIX and PSAMP for each of those aspects."
Done.
---
4: Section 6: I would add an introduction in order to give an overview for the reader. Here a proposal:

In this section we describes the usage of the IPFIX protocol for PSAMP. We describe the record formats and the additional requirements that must be met. PSAMP uses two different types of messages:
	- Packet Reports
	- Report Interpretation	
The format of Packet Reports is defined in IPFIX Template Record. The PSAMP data is transferred as Information Elements (IEs) in IPFIX Data Records as described by the Template Record. There are two different types of Packet Reports. Basic Packet Report contain only the basic IEs required for PSAMP reporting. Extended Packet Report MAY contain further Information Elements.
The format of Report Interpretations is defined in IPFIX Option Template Record. The Information Elements (IEs) are transferred in IPFIX Data Records as described by the Option Template Record. There are four different types of Report Interpretation messages:
 - Selection Sequence Report Interpretation
 - Selector Report Interpretation
 - Selection Sequence Statistics Report Interpretation
 - Accuracy Report Interpretation
A description and examples about the usage of those reports is given below.
Done.
---
5: Section 6.4.1, second bullet point: I would re-arrange the sentences so that it is clear, that a hash value only has to be reported if it is generated:
If there is a digest function in the selection sequence, the Packet report MUST contain the hash value (digestHashValue) generated by the digest hash function for each selected packet.
If there is more than one digest function then each hash value must be included in the same order as they appear in the selection sequence.  
If there are no digest functions in the selection sequence no element for the digest needs to be sent.
Done.
---
6: section 6.5.3, paragraph 7:
"The Attained Selection Fraction for the Selection Sequence is calculated by dividing the number of observed packets (packetsObserved Information Element) by the value of selected packets (packetsSelected Information Element) for the last Selector."  

was probably meant to be:

"The Attained Selection Fraction for the Selection Sequence is calculated by dividing the number of selected packets (packetsSelected Information Element) for the last Selector by the number of observed packets (packetsObserved Information Element)."
Good catch.
---
Typos, etc.:
- section 5.1, last paragraph: "...IPFIX protocol specifications are described in" ==> "...IPFIX protocol specifications described in" 
- section 6.5.2.6, paragraph 12: "select those packets select those packets"
It was there to REALLY stress that you "MUST NOT select those packets" :)
Corrected.

Thanks for your comments.

Regards, Benoit.
 

Regards,
Tanja

--------------000600060103040903090803-- --===============0093944931== 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://www1.ietf.org/mailman/listinfo/psamp --===============0093944931==-- From psamp-bounces@ietf.org Mon Oct 16 06:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPw0-0000sM-Mm; Mon, 16 Oct 2006 06:43:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPvz-0000nN-CH for psamp@ietf.org; Mon, 16 Oct 2006 06:43:03 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPvy-0007cD-83 for psamp@ietf.org; Mon, 16 Oct 2006 06:43:03 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7F1F1122 for ; Mon, 16 Oct 2006 12:43:01 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28814-04 for ; Mon, 16 Oct 2006 12:42:58 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8B89911B for ; Mon, 16 Oct 2006 12:42:58 +0200 (MST) Message-ID: <45336273.3040704@informatik.uni-tuebingen.de> Date: Mon, 16 Oct 2006 12:44:03 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: psamp Subject: Re: [PSAMP] Metering Process and/or Selection Process References: <452FBF6D.9030309@cisco.com> <452FD2D9.5030507@informatik.uni-tuebingen.de> <45335312.7070501@cisco.com> In-Reply-To: <45335312.7070501@cisco.com> X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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="===============1421927222==" Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1421927222== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106050608090704010209" This is a cryptographically signed message in MIME format. --------------ms010106050608090704010209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Benoit, Yes, solution 3 is a good start. I see the following possible enhancements: 1) In order to avoid confusion, we should not define processes within processes but find another word for "Selection Process". For example, we could call it "Packet Selection Function". (If you do not like "function", you can replace it by something else.) 2) Sampled packets can be either used for PSAMP or IPFIX export. In the first case, we need a "Packet Reporting Function" to extract the exported IEs and to generate the report stream. In the second case, we have a "Flow Metering Function" that generates the flow records. So the whole picture could look like this: PSAMP Device: +--------------------------+ | Metering Process | | +---------+ +---------+ | +-----------+ Observed | |Packet | |Packet | | | Exporting | Packet--->| |Selection|->|Reporting|---->| Process |--->Collector Stream | +---------+ +---------+ | +-----------+ +--------------------------+ IPFIX Device: +--------------------------+ | Metering Process | | +---------+ +---------+ | +-----------+ Observed | |Packet | |Flow | | | Exporting | Packet--->| |Selection|->|Metering |---->| Process |--->Collector Stream | +---------+ +---------+ | +-----------+ +--------------------------+ Regards, Gerhard Benoit Claise wrote: > Hi Gerhard, > > Do I understand correctly that you favor solution 3 in my email. > This is also my preferred solution. > > Regards, Benoit. >> Benoit, >> >> In draft-muenz-ipfix-configuration-00, I tried to combine the different >> aspects of an IPFIX/PSAMP Metering Process: >> >> >> 4.3. Metering Process >> >> Metering Processes perform the data processing within the IPFIX >> Device. In case that the input of a Metering Process is raw packets >> from Observation Points, the data are processed and transformed into >> exportable records. If the input is records received from Collecting >> Processes or other Metering Processes, the records are processed and >> transformed into a new stream of records. >> >> In principle, packet-based and flow-based metering can be >> distinguished. Various packet-based processing techniques are >> specified in [I-D.ietf-psamp-sample-tech], and their configurable >> parameters are defined in [I-D.ietf-psamp-mib]. [I-D.ietf-psamp- >> framework] divides the packet-based Metering Process into a packet >> selection process and a reporting process. This is mapped on >> corresponding structures in the configuration data model. >> >> Flow-based processing techniques are described in [I-D.ietf-ipfix- >> architecture] and [I-D.dressler-ipfix-aggregation]. [RFC3917] gives >> an overview on the configurable parameters. [I-D.dressler-ipfix- >> aggregation] proposes a description language for flow metering rules >> (therein called aggregation rules) that define the Flow Keys as well >> as the metered and exported flow attributes. This rule-based >> description of flow metering can also be applied to devices that do >> not support multiple metering rules. For example, if a device >> performs flow metering with a single set of Flow Keys only, this can >> be mapped to exactly one metering rule. >> >> All in all, the configurable parameters of a Metering Process can be >> summarized as follows: >> >> Packet Selection: >> Incoming raw packets can be processed in a sequence of filters and >> sampling algorithms. The possible filtering and sampling >> parameters are defined in [I-D.ietf-psamp-mib]. >> >> Packet Reporting: >> If the output of the Metering Process are records with packet- >> based monitoring data (or PSAMP data), the packet reporting >> parameters define the Information Elements that are present in the >> records. >> >> Flow Metering: >> Flow-based metering can be described by one or more metering >> rules. Each metering rule defines the Information Elements that >> are present in the resulting records. Two different types of >> Information Elements are distinguished: Information Elements that >> are used as Flow Keys and Information Elements specifying the >> additional information reported for each flow. The application of >> a metering rule can be restricted to incoming data matching given >> patterns. Apart from metering rules, the flow-based data >> processing depends on active and inactive flow timeout values that >> control the flow expiration. >> >> Next Pointer: >> The output of a Metering Process can be passed to Exporting >> Processes and/or to other Metering Processes. >> >> >> This allows mapping different realizations of the Metering Processes: >> >> PSAMP probe: Packet Selection (optional) + Packet Reporting >> IPFIX probe: Packet Selecton (optional) + Flow Metering >> Concentrator: Flow Metering (alone) >> >> Note that my considerations were based on the assumption that we combine >> the former PSAMP Measurement Process and the IPFIX Metering Process into >> a single process. Of course, there are other possibilities, e.g. >> defining new types of Processes as you propose. >> >> Regards, >> Gerhard >> >> >> Benoit Claise wrote: >> >>> Tanja, all, >>> >>> I want to start a new email thread, discussing one of the point raised >>> by Tanja in >>> http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html >>> >>> 2: Section 3.3.1: As far as I know we agreed that we use the same >>> metering process definition for IPFIX and PSAMP. So the only >>> difference I see between PSAMP and IPFIX processes are the >>> Information elements that are reported. So I found section 3.3.1. a >>> bit confusing. >>> >>> Note: in Dallas, we agreed to replace the "measurement process" by the >>> "metering process" >>> While re-reading this section 3.3.1, I agree this is confusing. So we >>> have to change this text/picture >>> >>> The figure B indicates the sequence of the processes (selection and >>> exporting) within the PSAMP Device. >>> >>> +----------+ +-----------+ >>> Observed | Metering | | Exporting | >>> Packet--->| Process |----->| Process |--->Collector >>> Stream +----------+ +-----------+ >>> >>> Figure B: PSAMP Processes >>> >>> The Selection Process, which takes an Observed Packet Stream as its >>> input and produces Packet Reports as its output, is an integral part >>> of the Metering Process, which by its definition produces Flow >>> Records as its output. >>> >>> >>> >>> I was wondering how to change this: basically, we've got 2 choices! >>> Drawing 1: >>> >>> +------------------+ >>> | Metering Process | >>> | +-----------+ | +-----------+ >>> Observed | | Selection | | | Exporting | >>> Packet--->| | Process |--------->| Process |--->Collector >>> Stream | +-----------+ | +-----------+ >>> +------------------+ >>> >>> This would be consistent with the text in section 3.3.1: >>> >>> The Selection Process, which takes an Observed Packet Stream as its >>> input and produces Packet Reports as its output, is an integral part >>> of the Metering Process, which by its definition produces Flow >>> Records as its output. >>> >>> Drawing 2: >>> >>> +-----------+ +----------+ +-----------+ >>> Observed | Selection | | Metering | | Exporting | >>> Packet--->| Process |-->| Process |--->| Process |--->Collector >>> Stream +-----------+ +----------+ +-----------+ >>> >>> Figure B: PSAMP Processes >>> >>> This would be consistent with the text in section 3.2.2: >>> >>> Selection Process >>> >>> A Selection Process takes the Observed Packet Stream as its input and >>> selects a subset of that stream as its output. >>> >>> >>> >>> >>> >>> However, we quickly realize that we've an inconsistency in the following >>> definitions; >>> >>> Selection Process >>> >>> A Selection Process takes the Observed Packet Stream as its input and >>> selects a subset of that stream as its output. >>> >>> Report Stream >>> >>> The Report Stream is the output of a Selection Process, comprising >>> two distinguished types of information: Packet Reports, and Report >>> Interpretation. >>> >>> >>> One definition says that the selection process doesn't generate the >>> report stream while another says the reverse. >>> To solve this issue we've got 2 solutions: >>> >>> >>> Solution 1: >>> We divide the metering process into a Selection Process (Packet Stream >>> in, Selected Packets out) and a Reporting Process (Selected Packets In, >>> Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]: >>> >>> * Report Stream: >>> >>> The report stream is the output of a reporting process, >>> comprising two distinguished types of information: packet >>> reports, and report interpretation. >>> >>> As far as I recall, we decided to remove the Reporting Process from >>> [PSAMP-PROTO]... This rules out solution 1. >>> >>> Solution 2: >>> >>> +-----------+ +----------+ +-----------+ >>> Observed | Selection | | Metering | | Exporting | >>> Packet--->| Process |-->| Process |--->| Process |--->Collector >>> Stream +-----------+ +----------+ +-----------+ >>> >>> Figure B: PSAMP Processes >>> >>> So it means that PSAMP = IPFIX + an extra Selection Process. >>> We must update >>> >>> Report Stream >>> >>> The Report Stream is the output of a Metering (AND NOT SELECTION) Process, >>> comprising two distinguished types of information: Packet Reports, and Report >>> Interpretation >>> >>> >>> Solution 3: >>> >>> >>> +------------------+ >>> | Metering Process | >>> | +-----------+ | +-----------+ >>> Observed | | Selection | | | Exporting | >>> Packet--->| | Process |--------->| Process |--->Collector >>> Stream | +-----------+ | +-----------+ >>> +------------------+ >>> >>> So the metering process: Packet Stream in, Packet Reports out. >>> We must update >>> >>> Report Stream >>> >>> The Report Stream is the output of a Metering (AND NOT SELECTION) Process, >>> comprising two distinguished types of information: Packet Reports, and Report >>> Interpretation >>> >>> >>> What's your preferred solution? >>> >>> Regards, Benoit. >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> PSAMP mailing list >>> PSAMP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/psamp >>> >> _______________________________________________ >> PSAMP mailing list >> PSAMP@ietf.org >> https://www1.ietf.org/mailman/listinfo/psamp >> > --------------ms010106050608090704010209 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+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL 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 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MTAxNjEwNDQwM1owIwYJKoZIhvcNAQkEMRYEFBF20uKaHLhe PwzZh2qCRlycT3v+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQBV4Q3IV4hclJYBejDBHZrnBoe2L2MifOH6dqlydRx2kbh9vGpE3MVpyEdW pjGj0DJ54a7J+xPMezb2Ol2o/WOko5S34V29aVvA65KYnPivM9IYBSnG52JAYdKhc97RNBHh qZuzngbwL2SgN8IyTdZ9ZnTkVBYrg6ji+P/6VAhOthlJgiK4+08Iq2YeFvYnH/ReUBTnSZzk NbWh5SM3757nC8wfk37ynJTzaAxC9EQh0F1zrfXk1Ry03Zs7lHnD72JBw+oLuWAyxEDf4ie9 et1bcaUKhHzwYbIzI5OuPF3AkpiZss/4TvnK6LfEcyLbbzDpGQmS4TWz2HcoBiQfbMXkAAAA AAAA --------------ms010106050608090704010209-- --===============1421927222== 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://www1.ietf.org/mailman/listinfo/psamp --===============1421927222==-- From psamp-bounces@ietf.org Mon Oct 16 06:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZQ4h-0005ec-6w; Mon, 16 Oct 2006 06:52:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZQ4g-0005eV-1x for psamp@ietf.org; Mon, 16 Oct 2006 06:52:02 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZQ4c-00014K-Sk for psamp@ietf.org; Mon, 16 Oct 2006 06:52:02 -0400 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 k9GApv013617; Mon, 16 Oct 2006 12:51:57 +0200 (CEST) Received: from [10.61.81.175] (ams3-vpn-dhcp4528.cisco.com [10.61.81.175]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id k9GApuP28298; Mon, 16 Oct 2006 12:51:56 +0200 (CEST) Message-ID: <4533644B.4040508@cisco.com> Date: Mon, 16 Oct 2006 12:51:55 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [PSAMP] Metering Process and/or Selection Process References: <452FBF6D.9030309@cisco.com> <452FD2D9.5030507@informatik.uni-tuebingen.de> <45335312.7070501@cisco.com> <45336273.3040704@informatik.uni-tuebingen.de> In-Reply-To: <45336273.3040704@informatik.uni-tuebingen.de> X-Spam-Score: 0.5 (/) X-Scan-Signature: 3c5809f82a2ef36c74d8c0ab21f70455 Cc: psamp X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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="===============0771506020==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0771506020== Content-Type: multipart/alternative; boundary="------------010606000702030803080308" This is a multi-part message in MIME format. --------------010606000702030803080308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Hi Benoit, > > Yes, solution 3 is a good start. I see the following possible enhancements: > > 1) In order to avoid confusion, we should not define processes within > processes I don't see why! > but find another word for "Selection Process". For example, we > could call it "Packet Selection Function". (If you do not like > "function", you can replace it by something else.) > > 2) Sampled packets can be either used for PSAMP or IPFIX export. In the > first case, we need a "Packet Reporting Function" to extract the > exported IEs and to generate the report stream. In the second case, we > have a "Flow Metering Function" that generates the flow records. > > So the whole picture could look like this: > > PSAMP Device: > > +--------------------------+ > | Metering Process | > | +---------+ +---------+ | +-----------+ > Observed | |Packet | |Packet | | | Exporting | > Packet--->| |Selection|->|Reporting|---->| Process |--->Collector > Stream | +---------+ +---------+ | +-----------+ > +--------------------------+ > > IPFIX Device: > > +--------------------------+ > | Metering Process | > | +---------+ +---------+ | +-----------+ > Observed | |Packet | |Flow | | | Exporting | > Packet--->| |Selection|->|Metering |---->| Process |--->Collector > Stream | +---------+ +---------+ | +-----------+ > +--------------------------+ > > A couple of remarks: - this is too late to add a "Flow Metering" process into the IPFIX device. - your "packet reporting" is the "reporting process" as defined initially by [PSAMP-ARCH]. We decided to remove this term in one of the last IETF meeting. So, this is the reason why I think the best/easier solution is: Solution 3: +------------------+ | Metering Process | | +-----------+ | +-----------+ Observed | | Selection | | | Exporting | Packet--->| | Process |--------->| Process |--->Collector Stream | +-----------+ | +-----------+ +------------------+ So the metering process: Packet Stream in, Packet Reports out. We must update Report Stream The Report Stream is the output of a Metering (AND NOT SELECTION) Process, comprising two distinguished types of information: Packet Reports, and Report Interpretation Regards, Benoit. > Regards, > Gerhard > > > Benoit Claise wrote: > >> Hi Gerhard, >> >> Do I understand correctly that you favor solution 3 in my email. >> This is also my preferred solution. >> >> Regards, Benoit. >> >>> Benoit, >>> >>> In draft-muenz-ipfix-configuration-00, I tried to combine the different >>> aspects of an IPFIX/PSAMP Metering Process: >>> >>> >>> 4.3. Metering Process >>> >>> Metering Processes perform the data processing within the IPFIX >>> Device. In case that the input of a Metering Process is raw packets >>> from Observation Points, the data are processed and transformed into >>> exportable records. If the input is records received from Collecting >>> Processes or other Metering Processes, the records are processed and >>> transformed into a new stream of records. >>> >>> In principle, packet-based and flow-based metering can be >>> distinguished. Various packet-based processing techniques are >>> specified in [I-D.ietf-psamp-sample-tech], and their configurable >>> parameters are defined in [I-D.ietf-psamp-mib]. [I-D.ietf-psamp- >>> framework] divides the packet-based Metering Process into a packet >>> selection process and a reporting process. This is mapped on >>> corresponding structures in the configuration data model. >>> >>> Flow-based processing techniques are described in [I-D.ietf-ipfix- >>> architecture] and [I-D.dressler-ipfix-aggregation]. [RFC3917] gives >>> an overview on the configurable parameters. [I-D.dressler-ipfix- >>> aggregation] proposes a description language for flow metering rules >>> (therein called aggregation rules) that define the Flow Keys as well >>> as the metered and exported flow attributes. This rule-based >>> description of flow metering can also be applied to devices that do >>> not support multiple metering rules. For example, if a device >>> performs flow metering with a single set of Flow Keys only, this can >>> be mapped to exactly one metering rule. >>> >>> All in all, the configurable parameters of a Metering Process can be >>> summarized as follows: >>> >>> Packet Selection: >>> Incoming raw packets can be processed in a sequence of filters and >>> sampling algorithms. The possible filtering and sampling >>> parameters are defined in [I-D.ietf-psamp-mib]. >>> >>> Packet Reporting: >>> If the output of the Metering Process are records with packet- >>> based monitoring data (or PSAMP data), the packet reporting >>> parameters define the Information Elements that are present in the >>> records. >>> >>> Flow Metering: >>> Flow-based metering can be described by one or more metering >>> rules. Each metering rule defines the Information Elements that >>> are present in the resulting records. Two different types of >>> Information Elements are distinguished: Information Elements that >>> are used as Flow Keys and Information Elements specifying the >>> additional information reported for each flow. The application of >>> a metering rule can be restricted to incoming data matching given >>> patterns. Apart from metering rules, the flow-based data >>> processing depends on active and inactive flow timeout values that >>> control the flow expiration. >>> >>> Next Pointer: >>> The output of a Metering Process can be passed to Exporting >>> Processes and/or to other Metering Processes. >>> >>> >>> This allows mapping different realizations of the Metering Processes: >>> >>> PSAMP probe: Packet Selection (optional) + Packet Reporting >>> IPFIX probe: Packet Selecton (optional) + Flow Metering >>> Concentrator: Flow Metering (alone) >>> >>> Note that my considerations were based on the assumption that we combine >>> the former PSAMP Measurement Process and the IPFIX Metering Process into >>> a single process. Of course, there are other possibilities, e.g. >>> defining new types of Processes as you propose. >>> >>> Regards, >>> Gerhard >>> >>> >>> Benoit Claise wrote: >>> >>> >>>> Tanja, all, >>>> >>>> I want to start a new email thread, discussing one of the point raised >>>> by Tanja in >>>> http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html >>>> >>>> 2: Section 3.3.1: As far as I know we agreed that we use the same >>>> metering process definition for IPFIX and PSAMP. So the only >>>> difference I see between PSAMP and IPFIX processes are the >>>> Information elements that are reported. So I found section 3.3.1. a >>>> bit confusing. >>>> >>>> Note: in Dallas, we agreed to replace the "measurement process" by the >>>> "metering process" >>>> While re-reading this section 3.3.1, I agree this is confusing. So we >>>> have to change this text/picture >>>> >>>> The figure B indicates the sequence of the processes (selection and >>>> exporting) within the PSAMP Device. >>>> >>>> +----------+ +-----------+ >>>> Observed | Metering | | Exporting | >>>> Packet--->| Process |----->| Process |--->Collector >>>> Stream +----------+ +-----------+ >>>> >>>> Figure B: PSAMP Processes >>>> >>>> The Selection Process, which takes an Observed Packet Stream as its >>>> input and produces Packet Reports as its output, is an integral part >>>> of the Metering Process, which by its definition produces Flow >>>> Records as its output. >>>> >>>> >>>> >>>> I was wondering how to change this: basically, we've got 2 choices! >>>> Drawing 1: >>>> >>>> +------------------+ >>>> | Metering Process | >>>> | +-----------+ | +-----------+ >>>> Observed | | Selection | | | Exporting | >>>> Packet--->| | Process |--------->| Process |--->Collector >>>> Stream | +-----------+ | +-----------+ >>>> +------------------+ >>>> >>>> This would be consistent with the text in section 3.3.1: >>>> >>>> The Selection Process, which takes an Observed Packet Stream as its >>>> input and produces Packet Reports as its output, is an integral part >>>> of the Metering Process, which by its definition produces Flow >>>> Records as its output. >>>> >>>> Drawing 2: >>>> >>>> +-----------+ +----------+ +-----------+ >>>> Observed | Selection | | Metering | | Exporting | >>>> Packet--->| Process |-->| Process |--->| Process |--->Collector >>>> Stream +-----------+ +----------+ +-----------+ >>>> >>>> Figure B: PSAMP Processes >>>> >>>> This would be consistent with the text in section 3.2.2: >>>> >>>> Selection Process >>>> >>>> A Selection Process takes the Observed Packet Stream as its input and >>>> selects a subset of that stream as its output. >>>> >>>> >>>> >>>> >>>> >>>> However, we quickly realize that we've an inconsistency in the following >>>> definitions; >>>> >>>> Selection Process >>>> >>>> A Selection Process takes the Observed Packet Stream as its input and >>>> selects a subset of that stream as its output. >>>> >>>> Report Stream >>>> >>>> The Report Stream is the output of a Selection Process, comprising >>>> two distinguished types of information: Packet Reports, and Report >>>> Interpretation. >>>> >>>> >>>> One definition says that the selection process doesn't generate the >>>> report stream while another says the reverse. >>>> To solve this issue we've got 2 solutions: >>>> >>>> >>>> Solution 1: >>>> We divide the metering process into a Selection Process (Packet Stream >>>> in, Selected Packets out) and a Reporting Process (Selected Packets In, >>>> Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]: >>>> >>>> * Report Stream: >>>> >>>> The report stream is the output of a reporting process, >>>> comprising two distinguished types of information: packet >>>> reports, and report interpretation. >>>> >>>> As far as I recall, we decided to remove the Reporting Process from >>>> [PSAMP-PROTO]... This rules out solution 1. >>>> >>>> Solution 2: >>>> >>>> +-----------+ +----------+ +-----------+ >>>> Observed | Selection | | Metering | | Exporting | >>>> Packet--->| Process |-->| Process |--->| Process |--->Collector >>>> Stream +-----------+ +----------+ +-----------+ >>>> >>>> Figure B: PSAMP Processes >>>> >>>> So it means that PSAMP = IPFIX + an extra Selection Process. >>>> We must update >>>> >>>> Report Stream >>>> >>>> The Report Stream is the output of a Metering (AND NOT SELECTION) Process, >>>> comprising two distinguished types of information: Packet Reports, and Report >>>> Interpretation >>>> >>>> >>>> Solution 3: >>>> >>>> >>>> +------------------+ >>>> | Metering Process | >>>> | +-----------+ | +-----------+ >>>> Observed | | Selection | | | Exporting | >>>> Packet--->| | Process |--------->| Process |--->Collector >>>> Stream | +-----------+ | +-----------+ >>>> +------------------+ >>>> >>>> So the metering process: Packet Stream in, Packet Reports out. >>>> We must update >>>> >>>> Report Stream >>>> >>>> The Report Stream is the output of a Metering (AND NOT SELECTION) Process, >>>> comprising two distinguished types of information: Packet Reports, and Report >>>> Interpretation >>>> >>>> >>>> What's your preferred solution? >>>> >>>> Regards, Benoit. >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> PSAMP mailing list >>>> PSAMP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/psamp >>>> >>>> >>> _______________________________________________ >>> PSAMP mailing list >>> PSAMP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/psamp >>> >>> > > > ------------------------------------------------------------------------ > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp > --------------010606000702030803080308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Hi Benoit,

Yes, solution 3 is a good start. I see the following possible enhancements:

1) In order to avoid confusion, we should not define processes within
processes
I don't see why!
but find another word for "Selection Process". For example, we
could call it "Packet Selection Function". (If you do not like
"function", you can replace it by something else.)

2) Sampled packets can be either used for PSAMP or IPFIX export. In the
first case, we need a "Packet Reporting Function" to extract the
exported IEs and to generate the report stream. In the second case, we
have a "Flow Metering Function" that generates the flow records.

So the whole picture could look like this:

PSAMP Device:

           +--------------------------+
           | Metering Process         |
           | +---------+  +---------+ |   +-----------+
 Observed  | |Packet   |  |Packet   | |   | Exporting |
 Packet--->| |Selection|->|Reporting|---->| Process   |--->Collector
 Stream    | +---------+  +---------+ |   +-----------+
           +--------------------------+

IPFIX Device:

           +--------------------------+
           | Metering Process         |
           | +---------+  +---------+ |   +-----------+
 Observed  | |Packet   |  |Flow     | |   | Exporting |
 Packet--->| |Selection|->|Metering |---->| Process   |--->Collector
 Stream    | +---------+  +---------+ |   +-----------+
           +--------------------------+
A couple of remarks:
- this is too late to add a "Flow Metering" process into the IPFIX device.
- your "packet reporting" is the "reporting process" as defined initially by [PSAMP-ARCH]. We decided to remove this term in one of the last IETF meeting.

So, this is the reason why I think the best/easier solution is:
Solution 3:

 
           +------------------+
           | Metering Process |
           | +-----------+    |     +-----------+
 Observed  | | Selection |    |     | Exporting |
 Packet--->| | Process   |--------->| Process   |--->Collector
 Stream    | +-----------+    |     +-----------+
           +------------------+

So the metering process: Packet Stream in, Packet Reports out.
We must update

   Report Stream 
         
   The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
   comprising two distinguished types of information: Packet Reports, and Report 
   Interpretation
Regards, Benoit.
Regards,
Gerhard


Benoit Claise wrote:
  
 Hi Gerhard,

Do I understand correctly that you favor solution 3 in my email.
This is also my preferred solution.

Regards, Benoit.
    
Benoit,

In draft-muenz-ipfix-configuration-00, I tried to combine the different
aspects of an IPFIX/PSAMP Metering Process:


4.3.  Metering Process

   Metering Processes perform the data processing within the IPFIX
   Device.  In case that the input of a Metering Process is raw packets
   from Observation Points, the data are processed and transformed into
   exportable records.  If the input is records received from Collecting
   Processes or other Metering Processes, the records are processed and
   transformed into a new stream of records.

   In principle, packet-based and flow-based metering can be
   distinguished.  Various packet-based processing techniques are
   specified in [I-D.ietf-psamp-sample-tech], and their configurable
   parameters are defined in [I-D.ietf-psamp-mib].  [I-D.ietf-psamp-
   framework] divides the packet-based Metering Process into a packet
   selection process and a reporting process.  This is mapped on
   corresponding structures in the configuration data model.

   Flow-based processing techniques are described in [I-D.ietf-ipfix-
   architecture] and [I-D.dressler-ipfix-aggregation].  [RFC3917] gives
   an overview on the configurable parameters.  [I-D.dressler-ipfix-
   aggregation] proposes a description language for flow metering rules
   (therein called aggregation rules) that define the Flow Keys as well
   as the metered and exported flow attributes.  This rule-based
   description of flow metering can also be applied to devices that do
   not support multiple metering rules.  For example, if a device
   performs flow metering with a single set of Flow Keys only, this can
   be mapped to exactly one metering rule.

   All in all, the configurable parameters of a Metering Process can be
   summarized as follows:

   Packet Selection:
      Incoming raw packets can be processed in a sequence of filters and
      sampling algorithms.  The possible filtering and sampling
      parameters are defined in [I-D.ietf-psamp-mib].

   Packet Reporting:
      If the output of the Metering Process are records with packet-
      based monitoring data (or PSAMP data), the packet reporting
      parameters define the Information Elements that are present in the
      records.

   Flow Metering:
      Flow-based metering can be described by one or more metering
      rules.  Each metering rule defines the Information Elements that
      are present in the resulting records.  Two different types of
      Information Elements are distinguished: Information Elements that
      are used as Flow Keys and Information Elements specifying the
      additional information reported for each flow.  The application of
      a metering rule can be restricted to incoming data matching given
      patterns.  Apart from metering rules, the flow-based data
      processing depends on active and inactive flow timeout values that
      control the flow expiration.

   Next Pointer:
      The output of a Metering Process can be passed to Exporting
      Processes and/or to other Metering Processes.


This allows mapping different realizations of the Metering Processes:

PSAMP probe: Packet Selection (optional) + Packet Reporting
IPFIX probe: Packet Selecton (optional) + Flow Metering
Concentrator: Flow Metering (alone)

Note that my considerations were based on the assumption that we combine
the former PSAMP Measurement Process and the IPFIX Metering Process into
a single process. Of course, there are other possibilities, e.g.
defining new types of Processes as you propose.

Regards,
Gerhard


Benoit Claise wrote:
  
      
  Tanja, all,

I want to start a new email thread, discussing one of the point raised
by Tanja in
http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html

    2: Section 3.3.1: As far as I know we agreed that we use the same
    metering process definition for IPFIX and PSAMP. So the only
    difference I see between PSAMP and IPFIX processes are the
    Information elements that are reported. So I found section 3.3.1. a
    bit confusing.

Note: in Dallas, we agreed to replace the "measurement process" by the
"metering process"
While re-reading this section 3.3.1, I agree this is confusing. So we
have to change this text/picture     

   The figure B indicates the sequence of the processes (selection and 
   exporting) within the PSAMP Device. 
          
                  +----------+      +-----------+ 
        Observed  | Metering |      | Exporting | 
        Packet--->| Process  |----->| Process   |--->Collector 
        Stream    +----------+      +-----------+ 
    
       Figure B: PSAMP Processes 
                          
   The Selection Process, which takes an Observed Packet Stream as its 
   input and produces Packet Reports as its output, is an integral part 
   of the Metering Process, which by its definition produces Flow 
   Records as its output. 



I was wondering how to change this: basically, we've got 2 choices!
Drawing 1:
 
           +------------------+
           | Metering Process |
           | +-----------+    |     +-----------+
 Observed  | | Selection |    |     | Exporting |
 Packet--->| | Process   |--------->| Process   |--->Collector
 Stream    | +-----------+    |     +-----------+
           +------------------+

This would be consistent with the text in section 3.3.1:

    The Selection Process, which takes an Observed Packet Stream as its
    input and produces Packet Reports as its output, is an integral part
    of the Metering Process, which by its definition produces Flow
    Records as its output.

Drawing 2:

           +-----------+   +----------+    +-----------+
 Observed  | Selection |   | Metering |    | Exporting |
 Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
 Stream    +-----------+   +----------+    +-----------+
 
    Figure B: PSAMP Processes

This would be consistent with the text in section 3.2.2:

   Selection Process 
         
   A Selection Process takes the Observed Packet Stream as its input and 
   selects a subset of that stream as its output. 





However, we quickly realize that we've an inconsistency in the following
definitions;

   Selection Process 
         
   A Selection Process takes the Observed Packet Stream as its input and 
   selects a subset of that stream as its output. 

   Report Stream 
         
   The Report Stream is the output of a Selection Process, comprising 
   two distinguished types of information: Packet Reports, and Report 
   Interpretation.


One definition says that the selection process doesn't generate the
report stream while another says the reverse.
To solve this issue we've got 2 solutions:


Solution 1:
We divide the metering process into a Selection Process (Packet Stream
in, Selected Packets out) and a Reporting Process (Selected Packets In,
Packet Reports Out). This is the way it's done in [PSAMP-FRAMEWORK]:

      * Report Stream: 
            
           The report stream is the output of a reporting process, 
           comprising two distinguished types of information: packet 
           reports, and report interpretation. 

As far as I recall, we decided to remove the Reporting Process from
[PSAMP-PROTO]... This rules out solution 1.

Solution 2:

           +-----------+   +----------+    +-----------+
 Observed  | Selection |   | Metering |    | Exporting |
 Packet--->| Process   |-->| Process  |--->| Process   |--->Collector
 Stream    +-----------+   +----------+    +-----------+
 
    Figure B: PSAMP Processes

So it means that PSAMP = IPFIX + an extra Selection Process.
We must update

   Report Stream 
         
   The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
   comprising two distinguished types of information: Packet Reports, and Report 
   Interpretation


Solution 3:

 
           +------------------+
           | Metering Process |
           | +-----------+    |     +-----------+
 Observed  | | Selection |    |     | Exporting |
 Packet--->| | Process   |--------->| Process   |--->Collector
 Stream    | +-----------+    |     +-----------+
           +------------------+

So the metering process: Packet Stream in, Packet Reports out.
We must update

   Report Stream 
         
   The Report Stream is the output of a Metering (AND NOT SELECTION) Process, 
   comprising two distinguished types of information: Packet Reports, and Report 
   Interpretation


What's your preferred solution?

Regards, Benoit.



 


------------------------------------------------------------------------

_______________________________________________
PSAMP mailing list
PSAMP@ietf.org <mailto:PSAMP@ietf.org>
https://www1.ietf.org/mailman/listinfo/psamp
    
        
_______________________________________________
PSAMP mailing list
PSAMP@ietf.org <mailto:PSAMP@ietf.org>
https://www1.ietf.org/mailman/listinfo/psamp
  
      

  

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

--------------010606000702030803080308-- --===============0771506020== 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://www1.ietf.org/mailman/listinfo/psamp --===============0771506020==-- From psamp-bounces@ietf.org Mon Oct 16 08:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRYz-00078c-UQ; Mon, 16 Oct 2006 08:27:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRYy-00078P-Sa for psamp@ietf.org; Mon, 16 Oct 2006 08:27:24 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZRYu-0005Sh-9k for psamp@ietf.org; Mon, 16 Oct 2006 08:27:24 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 41628129; Mon, 16 Oct 2006 14:27:19 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14858-01; Mon, 16 Oct 2006 14:27:11 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9849B128; Mon, 16 Oct 2006 14:27:11 +0200 (MST) Message-ID: <45337AE0.2070702@informatik.uni-tuebingen.de> Date: Mon, 16 Oct 2006 14:28:16 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [PSAMP] Metering Process and/or Selection Process References: <452FBF6D.9030309@cisco.com> <452FD2D9.5030507@informatik.uni-tuebingen.de> <45335312.7070501@cisco.com> <45336273.3040704@informatik.uni-tuebingen.de> <4533644B.4040508@cisco.com> In-Reply-To: <4533644B.4040508@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: psamp X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: psamp-bounces@ietf.org Benoit, Benoit Claise wrote: >> So the whole picture could look like this: >> >> PSAMP Device: >> >> +--------------------------+ >> | Metering Process | >> | +---------+ +---------+ | +-----------+ >> Observed | |Packet | |Packet | | | Exporting | >> Packet--->| |Selection|->|Reporting|---->| Process |--->Collector >> Stream | +---------+ +---------+ | +-----------+ >> +--------------------------+ >> >> IPFIX Device: >> >> +--------------------------+ >> | Metering Process | >> | +---------+ +---------+ | +-----------+ >> Observed | |Packet | |Flow | | | Exporting | >> Packet--->| |Selection|->|Metering |---->| Process |--->Collector >> Stream | +---------+ +---------+ | +-----------+ >> +--------------------------+ >> >> > A couple of remarks: > - this is too late to add a "Flow Metering" process into the IPFIX device. It is not a process, but a function(ality) of the Metering Process which is implicitly described in the IPFIX-ARCH. Hence, it is not necessary to change anything in the IPFIX documents. However, I think it is useful to clarify the relationship between sampling and flow metering in the PSAMP-ARCH. > - your "packet reporting" is the "reporting process" as defined > initially by [PSAMP-ARCH]. We decided to remove this term in one of the > last IETF meeting. That is fine, I also would not call it a process. But the function(ality) is still needed, so why not clarifying in PSAMP-ARCH where it is and what it does. Regards, Gerhard > So, this is the reason why I think the best/easier solution is: > > Solution 3: > > > +------------------+ > | Metering Process | > | +-----------+ | +-----------+ > Observed | | Selection | | | Exporting | > Packet--->| | Process |--------->| Process |--->Collector > Stream | +-----------+ | +-----------+ > +------------------+ > > So the metering process: Packet Stream in, Packet Reports out. > We must update > > Report Stream > > The Report Stream is the output of a Metering (AND NOT SELECTION) Process, > comprising two distinguished types of information: Packet Reports, and Report > Interpretation > > Regards, Benoit. _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Thu Oct 26 16:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBNs-00036Y-7R; Thu, 26 Oct 2006 15:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMt-0001ym-PZ; Thu, 26 Oct 2006 15:58:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBFP-0007HJ-4u; Thu, 26 Oct 2006 15:50:39 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdBFO-0005wx-Qh; Thu, 26 Oct 2006 15:50:39 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 744B4175FC; Thu, 26 Oct 2006 19:50:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEu-0005KK-18; Thu, 26 Oct 2006 15:50:08 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:08 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: psamp@ietf.org Subject: [PSAMP] I-D ACTION:draft-ietf-psamp-protocol-07.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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: , 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 : Packet Sampling (PSAMP) Protocol Specifications Author(s) : B. Claise Filename : draft-ietf-psamp-protocol-07.txt Pages : 45 Date : 2006-10-26 This document specifies the export of packet information from a 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-psamp-protocol-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-protocol-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26115500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-protocol-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-protocol-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26115500.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/psamp --NextPart-- From psamp-bounces@ietf.org Thu Oct 26 16:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBOS-0003m6-Ps; Thu, 26 Oct 2006 16:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMs-00020B-9u; Thu, 26 Oct 2006 15:58:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBGM-0007M7-TQ; Thu, 26 Oct 2006 15:51:39 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdBGM-0005yh-KF; Thu, 26 Oct 2006 15:51:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A1AE62AD2D; Thu, 26 Oct 2006 19:50:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEv-0005N4-DL; Thu, 26 Oct 2006 15:50:09 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: psamp@ietf.org Subject: [PSAMP] I-D ACTION:draft-ietf-psamp-info-05.txt X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 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: , 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-05.txt Pages : 38 Date : 2006-10-26 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-psamp-info-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-info-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26144126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-info-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-info-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26144126.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/psamp --NextPart--