From owner-psamp@ops.ietf.org Fri Nov 5 14:46:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10431 for ; Fri, 5 Nov 2004 14:46:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CQ9x9-000Kqy-Og for psamp-data@psg.com; Fri, 05 Nov 2004 19:40:55 +0000 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CQ8qQ-000AxJ-99 for psamp@ops.ietf.org; Fri, 05 Nov 2004 18:29:54 +0000 Received: from [10.1.1.171] (dummy.netlab.nec.de [195.37.70.40]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C40681BACC7; Fri, 5 Nov 2004 19:29:52 +0100 (CET) Date: Fri, 05 Nov 2004 19:29:54 +0100 From: Juergen Quittek To: psamp@ops.ietf.org Cc: Andy Bierman Subject: Re: PSAMP WG agenda for IETF #61 Message-ID: <2147483647.1099682994@[10.1.1.171]> In-Reply-To: <4.3.2.7.2.20041031175318.0238c000@fedex.cisco.com> References: <4.3.2.7.2.20041031175318.0238c000@fedex.cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, Here is an update of the agenda for our session next week. It is not yet visible at the IETF web server. Thanks, Juergen --On 31.10.2004 17:54 h -0700 Andy Bierman wrote: > > Packet Sampling WG (psamp) > IETF #61 > November 12, 2004: 0900-1130 > ============================ > > Chairs: > Andy Bierman > Juergen Quittek > > AGENDA: > > Discussion of open issues in all WG drafts > > 1) Sampling Framework > - A Framework for Passive Packet Measurement > - Draft updated October 2004 > > 2) Packet Selection > - Sampling and Filtering Techniques for IP Packet Selection > - Draft updated October 2004 > > 3) Report Format and Export Protocol > - Packet Sampling (PSAMP) Protocol Specifications > - Draft expired, not available online > > 4) PSAMP Information Model > - Information Model for Packet Sampling Exports > - Draft not updated since July 2004 > > 5) PSAMP MIB > - Definitions of Managed Objects for Packet Sampling > - Draft not updated since July 2004 > > INTERNET DRAFTS: > > A Framework for Passive Packet Measurement > http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-09.txt > > Sampling and Filtering Techniques for IP Packet Selection > http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-05.txt > > Packet Sampling (PSAMP) Protocol Specifications > http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-01.txt > > Information Model for Packet Sampling Exports > http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-02.txt > > Definitions of Managed Objects for Packet Sampling > http://www.ietf.org/internet-drafts/draft-ietf-psamp-mib-03.txt > > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Nov 11 20:22:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22471 for ; Thu, 11 Nov 2004 20:22:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSQ43-000CLX-Q4 for psamp-data@psg.com; Fri, 12 Nov 2004 01:17:23 +0000 Received: from [144.254.15.119] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSQ3t-000CKE-0C for psamp@ops.ietf.org; Fri, 12 Nov 2004 01:17:13 +0000 Received: from [10.67.87.21] (rtp-vpn3-635.cisco.com [10.82.218.126]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAC1H1114417; Fri, 12 Nov 2004 02:17:01 +0100 (CET) Message-ID: <41940F0D.9060806@cisco.com> Date: Fri, 12 Nov 2004 02:17:01 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tanja Zseby CC: Juergen Quittek , psamp@ops.ietf.org Subject: Re: WG last call on Sampling and Filtering Techniques for IP Packet Selection References: <2147483647.1098459162@[192.168.2.3]> <417C1C3F.1030600@fokus.fraunhofer.de> In-Reply-To: <417C1C3F.1030600@fokus.fraunhofer.de> Content-Type: multipart/alternative; boundary="------------040602060403040803070003" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------040602060403040803070003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tanja, I read the draft (sorry, couldn't read earlier), and I have one issue left. In this draft, one of your change is: - Low level filter definition substituted by simple filter definition based on IPFIX flow attributes - No masks and ranges (exept source and dest addresses) - No OR operation, AND realized by concatenating filters This change is welcome. However, I think it should be propagated to the "Router State Filtering", which still allows OR and NOT 6.3 Router State Filtering This class of filters select a packet on the basis of router state conditions. The following list gives examples for such conditions. _Conditions can be combined with AND, OR or NOT operators. _ - Ingress interface at which the packet arrives equals a specified value - Egress interface to which the packet is routed equals a specified value - Packet violated Access Control List (ACL) on the router - Reverse Path Forwarding (RPF) failed for the packet - Resource Reservation is insufficient for the packet - No route found for the packet - Origin BGP AS [RFC1771] equals a specified value or lies within a given range - Destination BGP AS equals a specified value or lies within a given range Regards, Benoit. > Hi all, > > for reviewing the packet selection draft, please use the document > published under: > > http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-05.txt > > > (Please do not use the document that I did send on the list, because I > had to make a few modifications to the IPR and Copyright section to be > conformant to the new IETF format. Therefore the published draft > slightly differs from the document that I did send before.) > > Thanks, > Tanja > > Juergen Quittek wrote: > >> Dear all, >> >> After long discussions, our document on >> >> Sampling and Filtering Techniques for IP Packet Selection >> draft-ietf-psamp-sample-tech-05.txt >> >> is ready for WG last call. >> >> The call will last two weeks and close on Friday, November 5th >> just two days before IETF#61. Then we can discuss raised issues >> at our session and (hopefully) solve them quickly. >> >> Please read the document and send your comments! >> >> Thanks, >> >> Juergen > > > --------------040602060403040803070003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tanja,

I read the draft (sorry, couldn't read earlier), and I have one issue left.

In this draft, one of your change is:
-    Low level filter definition substituted by simple filter definition based on IPFIX flow attributes
       - No masks and ranges (exept source and dest addresses)
       - No OR operation, AND realized by concatenating filters
This change is welcome.
However, I think it should be propagated to the "Router State Filtering", which still allows OR and NOT
 6.3 Router State Filtering 
     
    This class of filters select a packet on the basis of router 
    state conditions. The following list gives examples for such 
    conditions. Conditions can be  combined with AND, OR or NOT 
    operators. 
  
       - Ingress interface at which the packet arrives equals a 
          specified value 
       - Egress interface to which the packet is routed equals a 
          specified value 
       - Packet violated Access Control List (ACL) on the router 
       - Reverse Path Forwarding (RPF) failed for the packet 
       - Resource Reservation is insufficient for the packet 
       - No route found for the packet 
       - Origin BGP AS [RFC1771] equals a specified value or lies 
          within a given  range  
       - Destination BGP AS equals a specified value or lies within 
          a given range
Regards, Benoit.


Hi all,

for reviewing the packet selection draft,  please use the document published under:

http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-05.txt


(Please do not use the document that I did send on the list, because I had to make a few modifications to the IPR and Copyright section to be conformant to the new IETF format. Therefore the published draft slightly differs from the document that I did send before.)

Thanks,
Tanja

Juergen Quittek wrote:

Dear all,

After long discussions, our document on

Sampling and Filtering Techniques for IP Packet Selection
draft-ietf-psamp-sample-tech-05.txt

is ready for WG last call.

The call will last two weeks and close on Friday, November 5th
just two days before IETF#61.  Then we can discuss raised issues
at our session and (hopefully) solve them quickly.

Please read the document and send your comments!

Thanks,

   Juergen



--------------040602060403040803070003-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Nov 11 20:39:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24060 for ; Thu, 11 Nov 2004 20:39:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSQLl-000EAe-Lk for psamp-data@psg.com; Fri, 12 Nov 2004 01:35:41 +0000 Received: from [144.254.15.119] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSQLS-000E9u-Tc for psamp@ops.ietf.org; Fri, 12 Nov 2004 01:35:23 +0000 Received: from [10.67.87.21] (rtp-vpn3-635.cisco.com [10.82.218.126]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAC1ZL124738; Fri, 12 Nov 2004 02:35:21 +0100 (CET) Message-ID: <41941358.3090801@cisco.com> Date: Fri, 12 Nov 2004 02:35:20 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp@ops.ietf.org CC: Tanja Zseby , Juergen Quittek Subject: Re: WG last call on Sampling and Filtering Techniques for IP Packet Selection References: <2147483647.1098459162@[192.168.2.3]> <417C1C3F.1030600@fokus.fraunhofer.de> <41940F0D.9060806@cisco.com> In-Reply-To: <41940F0D.9060806@cisco.com> Content-Type: multipart/alternative; boundary="------------010809030103000305030005" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------010809030103000305030005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit BTW, this concern is also valid for draft-ietf-psamp-framework-09.txt Regards, Benoit. > Tanja, > > I read the draft (sorry, couldn't read earlier), and I have one issue > left. > > In this draft, one of your change is: > > - Low level filter definition substituted by simple filter > definition based on IPFIX flow attributes > - No masks and ranges (exept source and dest addresses) > - No OR operation, AND realized by concatenating filters > > This change is welcome. > However, I think it should be propagated to the "Router State > Filtering", which still allows OR and NOT > > 6.3 Router State Filtering > > This class of filters select a packet on the basis of router > state conditions. The following list gives examples for such > conditions. _Conditions can be combined with AND, OR or NOT > operators. _ > > - Ingress interface at which the packet arrives equals a > specified value > - Egress interface to which the packet is routed equals a > specified value > - Packet violated Access Control List (ACL) on the router > - Reverse Path Forwarding (RPF) failed for the packet > - Resource Reservation is insufficient for the packet > - No route found for the packet > - Origin BGP AS [RFC1771] equals a specified value or lies > within a given range > - Destination BGP AS equals a specified value or lies within > a given range > > Regards, Benoit. > > >> Hi all, >> >> for reviewing the packet selection draft, please use the document >> published under: >> >> http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-05.txt >> >> >> (Please do not use the document that I did send on the list, because >> I had to make a few modifications to the IPR and Copyright section to >> be conformant to the new IETF format. Therefore the published draft >> slightly differs from the document that I did send before.) >> >> Thanks, >> Tanja >> >> Juergen Quittek wrote: >> >>> Dear all, >>> >>> After long discussions, our document on >>> >>> Sampling and Filtering Techniques for IP Packet Selection >>> draft-ietf-psamp-sample-tech-05.txt >>> >>> is ready for WG last call. >>> >>> The call will last two weeks and close on Friday, November 5th >>> just two days before IETF#61. Then we can discuss raised issues >>> at our session and (hopefully) solve them quickly. >>> >>> Please read the document and send your comments! >>> >>> Thanks, >>> >>> Juergen >> >> >> > --------------010809030103000305030005 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit BTW, this concern is also valid for draft-ietf-psamp-framework-09.txt

Regards, Benoit.
Tanja,

I read the draft (sorry, couldn't read earlier), and I have one issue left.

In this draft, one of your change is:
-    Low level filter definition substituted by simple filter definition based on IPFIX flow attributes
       - No masks and ranges (exept source and dest addresses)
       - No OR operation, AND realized by concatenating filters
This change is welcome.
However, I think it should be propagated to the "Router State Filtering", which still allows OR and NOT
 6.3 Router State Filtering 
     
    This class of filters select a packet on the basis of router 
    state conditions. The following list gives examples for such 
    conditions. Conditions can be  combined with AND, OR or NOT 
    operators. 
  
       - Ingress interface at which the packet arrives equals a 
          specified value 
       - Egress interface to which the packet is routed equals a 
          specified value 
       - Packet violated Access Control List (ACL) on the router 
       - Reverse Path Forwarding (RPF) failed for the packet 
       - Resource Reservation is insufficient for the packet 
       - No route found for the packet 
       - Origin BGP AS [RFC1771] equals a specified value or lies 
          within a given  range  
       - Destination BGP AS equals a specified value or lies within 
          a given range
Regards, Benoit.


Hi all,

for reviewing the packet selection draft,  please use the document published under:

http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-05.txt


(Please do not use the document that I did send on the list, because I had to make a few modifications to the IPR and Copyright section to be conformant to the new IETF format. Therefore the published draft slightly differs from the document that I did send before.)

Thanks,
Tanja

Juergen Quittek wrote:

Dear all,

After long discussions, our document on

Sampling and Filtering Techniques for IP Packet Selection
draft-ietf-psamp-sample-tech-05.txt

is ready for WG last call.

The call will last two weeks and close on Friday, November 5th
just two days before IETF#61.  Then we can discuss raised issues
at our session and (hopefully) solve them quickly.

Please read the document and send your comments!

Thanks,

   Juergen




--------------010809030103000305030005-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sat Nov 13 11:40:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16335 for ; Sat, 13 Nov 2004 11:40:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CT0r4-000Cmb-Sr for psamp-data@psg.com; Sat, 13 Nov 2004 16:34:26 +0000 Received: from [192.20.225.112] (helo=mail-yellow.research.att.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CT0qu-000Clt-7D for psamp@ops.ietf.org; Sat, 13 Nov 2004 16:34:16 +0000 Received: from chips.research.att.com (chips.research.att.com [135.207.27.139]) by mail-blue.research.att.com (Postfix) with ESMTP id AF9A81974B8; Sat, 13 Nov 2004 11:24:19 -0500 (EST) Received: from chips.research.att.com (localhost [127.0.0.1]) by chips.research.att.com (SGI-8.12.5/8.12.5) with ESMTP id iADGYFav105645971; Sat, 13 Nov 2004 11:34:15 -0500 (EST) Received: (from jrex@localhost) by chips.research.att.com (SGI-8.12.5/8.12.5/Submit) id iADGYFqt106481629; Sat, 13 Nov 2004 11:34:15 -0500 (EST) Date: Sat, 13 Nov 2004 11:34:15 -0500 (EST) Message-Id: <200411131634.iADGYFqt106481629@chips.research.att.com> From: Jennifer Rexford To: psamp@ops.ietf.org Subject: comments on draft-ietf-psamp-framework-09.txt X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Hi folks, I just read through the latest draft of "A Framework for Packet Selection and Reporting" (draft-ietf-psamp-framework-09.txt) and think the document looks great. I have just a few minor comments, and one suggestion for a few sentences of additional text (on the subject of congestion-aware transport). More below... -- Jen - page 11, Section 4.1: bullet "*" is missing in "Non-Contingency". Also, the term "non-contingency" seems a bit strange. The text for the bullet could add something about why this requirement is included (e.g., "in order to limit the complexity of the selection logic"). - page 12, Section 4.3: in the bullet on "Congestion Avoidance," it would be good to include a forward pointer to Section 8.2 where this issue is discussed further. - page 13-14: Under "content-dependent sampling" or "non-uniform probabilistic sampling," it may be helpful to include "sampling packets in proportion to their length" as an example. - page 15: At the end of Section 5.2, I didn't understand the sentence "However, if selection not based on routing state has reduced down from line rate...." I had trouble parsing it. - page 21: Section 8.2 talks about the need for unreliable, congestion-aware transport, and shifts in the last paragraph to talking about IPFIX rather than PSAMP. I wasn't sure what the the IPFIX paragraph was trying to get at, and if/how it relates to the way PSAMP should achieve congestion-aware transport. Somewhere in the document (either in 8.2, 8.5, or in 10.2), it would be worth commenting on lighweight ways to achieve the goal of congestion-aware transport. Section 8.2 could end by saying something like "Congestion-aware transport of PSAMP records could be achieved in various ways. For example, the PSAMP device could have an export rate limit (as discussed in Section 8.5) that is configured by the controller based on observations of the packet loss rate in delivering PSAMP records. This would ensure that the transport rate adapts in the presence of congestion without requiring the PSAMP device to receive acknowledgment packets or implement the adaptation algorithm directly." I think this is important for conveying how the requirement of congestion-aware transport can be satisfied without introducing a lot of complexity in a PSAMP device that much operate at high speed. - page 32: My room number is A139. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Nov 14 17:53:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18145 for ; Sun, 14 Nov 2004 17:53:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTT9W-0003h6-3j for psamp-data@psg.com; Sun, 14 Nov 2004 22:47:22 +0000 Received: from [208.246.215.5] (helo=mailhost.avici.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTT9V-0003gd-8p for psamp@ops.ietf.org; Sun, 14 Nov 2004 22:47:21 +0000 Received: from avici.com (b2vpnpc24.avici.com [10.2.103.24]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAEMl8ni023884; Sun, 14 Nov 2004 17:47:10 -0500 Message-ID: <4197E075.7090004@avici.com> Date: Sun, 14 Nov 2004 17:47:17 -0500 From: Derek Chiou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jennifer Rexford CC: psamp@ops.ietf.org Subject: Re: comments on draft-ietf-psamp-framework-09.txt References: <200411131634.iADGYFqt106481629@chips.research.att.com> In-Reply-To: <200411131634.iADGYFqt106481629@chips.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some in-lined comments. Jennifer Rexford wrote: >Hi folks, > >I just read through the latest draft of "A Framework for Packet >Selection and Reporting" (draft-ietf-psamp-framework-09.txt) and >think the document looks great. I have just a few minor comments, >and one suggestion for a few sentences of additional text (on the >subject of congestion-aware transport). More below... > >-- Jen > >- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency". >Also, the term "non-contingency" seems a bit strange. The text for > The term is strange to me as well. I'm not sure what would be a good replacement. Perhaps Future-Independent? >the bullet could add something about why this requirement is included >(e.g., "in order to limit the complexity of the selection logic"). > >- page 12, Section 4.3: in the bullet on "Congestion Avoidance," it >would be good to include a forward pointer to Section 8.2 where this >issue is discussed further. > >- page 13-14: Under "content-dependent sampling" or "non-uniform >probabilistic sampling," it may be helpful to include "sampling >packets in proportion to their length" as an example. > Doesn't "sampling packets in proportion to their length" fall into the content _independent_ sampling? If you sample periodically by time, you'll get sampling of packets in proportion to their length. > >- page 15: At the end of Section 5.2, I didn't understand the >sentence "However, if selection not based on routing state has >reduced down from line rate...." I had trouble parsing it. > Is the following more clear? "However, if prior selection not based on routing state has reduced the packet stream to below line rate, subselection based on routing state may be feasible." > >- page 21: Section 8.2 talks about the need for unreliable, >congestion-aware transport, and shifts in the last paragraph to >talking about IPFIX rather than PSAMP. I wasn't sure what the the >IPFIX paragraph was trying to get at, and if/how it relates to the way >PSAMP should achieve congestion-aware transport. Somewhere in the >document (either in 8.2, 8.5, or in 10.2), it would be worth >commenting on lighweight ways to achieve the goal of congestion-aware >transport. Section 8.2 could end by saying something like >"Congestion-aware transport of PSAMP records could be achieved in >various ways. For example, the PSAMP device could have an export rate >limit (as discussed in Section 8.5) that is configured by the >controller based on observations of the packet loss rate in delivering >PSAMP records. This would ensure that the transport rate adapts in >the presence of congestion without requiring the PSAMP device to >receive acknowledgment packets or implement the adaptation algorithm >directly." I think this is important for conveying how the requirement >of congestion-aware transport can be satisfied without introducing >a lot of complexity in a PSAMP device that much operate at high speed. > >- page 32: My room number is A139. > > > > >-- >to unsubscribe send a message to psamp-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Nov 14 18:10:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19627 for ; Sun, 14 Nov 2004 18:10:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTTS7-0005jC-W9 for psamp-data@psg.com; Sun, 14 Nov 2004 23:06:35 +0000 Received: from [208.246.215.5] (helo=mailhost.avici.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTTS6-0005ir-Ik for psamp@ops.ietf.org; Sun, 14 Nov 2004 23:06:35 +0000 Received: from avici.com (b2vpnpc24.avici.com [10.2.103.24]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAEN6Hni026527 for ; Sun, 14 Nov 2004 18:06:19 -0500 Message-ID: <4197E4F3.3030009@avici.com> Date: Sun, 14 Nov 2004 18:06:27 -0500 From: Derek Chiou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: some comments on draft-ietf-psamp-framework-09.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I've reviewed psamp-framework-09. It looks very good overall. I have some (mostly very minor) comments that I've listed below. Thanks. Derek *** draft-ietf-psamp-framework-09.txt Sun Nov 14 17:50:05 2004 --- draft-ietf-psamp-framework-09-derek.txt Sun Nov 14 17:54:11 2004 *************** *** 45,47 **** the components of this architecture, then describes some generic ! requirements, motivated the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed --- 45,47 ---- the components of this architecture, then describes some generic ! requirements AND MOTIVATES the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed *************** *** 174,179 **** across multivendor domains. This requires domain wide consistency in the types of selection schemes available, the manner in which the resulting measurements are presented, and consequently, ! consistency of the interpretation that can be put on them. --- 174,179 ---- across multivendor domains. This requires domain-wide consistency in the types of selection schemes available, the manner in which the resulting measurements are presented, and consequently, ! CONSISTENT INTERPRETATION OF THE MEASUREMENTS. *************** *** 613,615 **** ! * Encrypted Packets: Selectors that interpret of packet fields must be configurable to ignore (i.e. not select) encrypted --- 613,615 ---- ! * Encrypted Packets: Selectors that interpret packet fields must be configurable to ignore (i.e. not select) encrypted *************** *** 778,780 **** ! * Probabilistic n-out-of-N Sampling: form each count-based successive block of N packets, n are selected at random. --- 778,780 ---- ! * Probabilistic n-out-of-N Sampling: from each count-based successive block of N packets, n are selected at random. *************** *** 825,829 **** applied to a subset of packet content, and the packet is ! selected of the resulting hash falls in a specified range. With ! a suitable hash function, hash based selection approximates ! uniform random sampling. Applications of hash-based sampling are described in Section 11. --- 825,829 ---- applied to a subset of packet content, and the packet is ! selected if the resulting hash falls in a specified range. With ! a suitable hash function, hash-based selection approximates ! uniform random sampling (NOT NECESSARILY). Applications of hash-based sampling are described in Section 11. THOUGH IN GENERAL HASH-BASED SELECTION MAY APPROXIMATE UNIFORM RANDOM SAMPLING, PACKETS THAT LOOK THE SAME TO THE HASH ARE ALWAYS GOING TO BE TREATED THE SAME AS THE HASH. THUS, A DOS ATTACK THAT KNOWS THE HASH CAN ESCAPE DETECTION BY A HASH-BASED SELECTOR BUT CANNOT ESCAPE DETECTION BY A UNIFORM RANDOM SAMPLING SELECTOR. I MAY HAVE COMMENTED ON THIS BEFORE, BUT I FIGURE I'LL SAY IT AGAIN. *************** *** 959,962 **** the Attained Selection Fraction ! ! With Composite Selectors, and input sequence number must be reported for each Selector in the composition. --- 959,962 ---- the Attained Selection Fraction ! ! With Composite Selectors, an input sequence number must be reported for each Selector in the composition. *************** *** 1112,1114 **** expected to be relatively static; they could be communicated ! periodically, and upon change. --- 1112,1118 ---- expected to be relatively static; they could be communicated ! periodically, and upon change. ! ! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, MEASUREMENT ! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN EVERY ! PACKET REPORT? *************** *** 1172,1174 **** In order to jointly satisfy the timeliness and congestion ! avoidance requirements of Section 4.3, a congestion aware unreliable transport protocol must be used. IPFIX is compatible --- 1176,1178 ---- In order to jointly satisfy the timeliness and congestion ! avoidance requirements of Section 4.3, a congestion-aware unreliable transport protocol must be used. IPFIX is compatible *************** *** 1178,1180 **** User Datagram Protocol (UDP) [UDP] although it is not a ! congestion aware protocol. However, in this case, the Export Packets must remain wholly within the administrative domains of --- 1182,1184 ---- User Datagram Protocol (UDP) [UDP] although it is not a ! congestion-aware protocol. However, in this case, the Export Packets must remain wholly within the administrative domains of *************** *** 1194,1196 **** category would include: identifying sources associated with ! congestion; tracing denial of service attacks through the network and constructing traffic matrices. Furthermore, keeping dispatch --- 1198,1200 ---- category would include: identifying sources associated with ! congestion, tracing denial of service attacks through the network and constructing traffic matrices. Furthermore, keeping dispatch *************** *** 1239,1240 **** --- 1243,1247 ---- the buffer exceeds a configurable bound. + + COLLECTOR MAY SEE VERY LOW SAMPLED PACKET RATES BECAUSE OF + MISCONFIGURATION HERE. *************** *** 1509,1511 **** sampling if necessary to manage the attained fraction of packets ! selected --- 1517,1519 ---- sampling if necessary to manage the attained fraction of packets ! selected. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Nov 14 19:10:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23539 for ; Sun, 14 Nov 2004 19:10:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTUPF-000B3l-DK for psamp-data@psg.com; Mon, 15 Nov 2004 00:07:41 +0000 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTUPE-000B3V-14 for psamp@ops.ietf.org; Mon, 15 Nov 2004 00:07:40 +0000 Received: from dialin-145-254-223-033.arcor-ip.net (dialin-145-254-223-033.arcor-ip.net [145.254.223.33]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E84611BACA3; Mon, 15 Nov 2004 01:07:31 +0100 (CET) Date: Mon, 15 Nov 2004 01:07:31 +0100 From: Juergen Quittek To: Tanja Zseby , psamp Subject: Re: new version of packet selection draft Message-ID: <2147483647.1100480850@dialin-145-254-223-033.arcor-ip.net> In-Reply-To: <416FE385.9070804@fokus.fraunhofer.de> References: <416FE385.9070804@fokus.fraunhofer.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I reviewed the Packet Selection I-D. It is a very good and clear document. I have just some minor comments. Document header The affiliations of Maurizio, Fredi and Saverio changed recently. Please update them. Abstract Capitalization of "Sampling and Filtering" and "packet Selection" are a bit irritating. I suggest to use small letters, particularly for "packet Selection". Section 2, item [PSAMP-FW] Please delete the last three lines about 'must, 'should', etc. Section 3 Capitalization is not used consistenly, for example Section 3.1, 'Packet Stream', line 1 "packet stream" -> "Packet Stream" Section 3.1, 'Packet Content', line 1 "packet content" -> "Packet Content" Section 3.1, 'Selection Process', line 1 "selection process" -> "Selection Process" Section 3.2, 'Selection State', line 1 "selection process" -> "Selection Process" Section 3.2, 'Selection State', line 2 "selection process" -> "Selection Process" Section 3.2, 'Selection State', line 2 "reporting process" -> "Reporting Process" Section 3.2, 'Selection State', line 3 "selection state" -> "Selection State" Section 3.2, 'Selection State', line 12 "selection state" -> "Selection State" Section 3.2, 'Selection State', line 13 "Selection state" -> "Selection State" Section 3.2, 'Selector', line 1 "selection process" -> "Selection Process" Section 3.2, 'Selector', item (i) "packet's content" -> "Packet Content" Section 3.2, 'Selector', item (iii) "selection process" -> "Selection Process" Section 3.3, 'Reporting Process', line 1 "reporting process" -> "Reporting Process" Section 3.3, 'Reporting Process', item (i) "packet's content" -> "Packet Content" ... and so on. Please use a consistent capitalization scheme. Section 3.1, 'Observation Point', line 2 I would remove the colon after "Examples include" Section 3.2, 'Selection State', line 2 I would remove the colon after "Examples include" Section 3.3, 'Reporting Process' Please remove colon at end of heading Section 5.2.2.3, last paragraph after reference [PSAMP-FW] there should be a closing bracket and a period Section 6.1, first line "IPIFIX" -> "IPFIX" References, [MolFl03] This reference points to an Internet draft and has to be removed. Appendix The Appendix should be between the Acknowledgment Section and the References Sections. References, Authors' addresses and IPR statements should be easy to find at the end of the document. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 15.10.2004 16:49 h +0200 Tanja Zseby wrote: > Hi all, > > I submitted a new version of the packet selection draft. The main changes from the last version are the following : > > - Low level filter definition substituted by simple filter definition based on IPFIX flow attributes > - No masks and ranges (exept source and dest addresses) > - No OR operation, AND realized by concatenating filters > - Hash function description moved to appendix > - Relations to IPFIX removed (instead reference to FW draft) > - Intro on other PSAMP documents added > - Terminology updated (consistent with FW draft), including new terms Configured and Attained Selection Fraction > - Restructuring (now better separation of Sampling and Filtering issues) > - Mentioned that IPSX has only been tested on IPv4 > - AT&T IPR statement added > > Regards > Tanja > > -- > Dipl.-Ing. Tanja Zseby > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) > -------------------------------------------------------------------------------------- > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 15 00:23:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11592 for ; Mon, 15 Nov 2004 00:23:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTZDa-000E8m-W9 for psamp-data@psg.com; Mon, 15 Nov 2004 05:15:58 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTZDZ-000E8X-M3 for psamp@ops.ietf.org; Mon, 15 Nov 2004 05:15:57 +0000 Received: from chips.research.att.com (chips.research.att.com [135.207.27.139]) by mail-blue.research.att.com (Postfix) with ESMTP id 8A47019739A; Mon, 15 Nov 2004 00:05:54 -0500 (EST) Received: from chips.research.att.com (localhost [127.0.0.1]) by chips.research.att.com (SGI-8.12.5/8.12.5) with ESMTP id iAF5Fvav107813620; Mon, 15 Nov 2004 00:15:57 -0500 (EST) Received: (from jrex@localhost) by chips.research.att.com (SGI-8.12.5/8.12.5/Submit) id iAF5FsVr101820069; Mon, 15 Nov 2004 00:15:54 -0500 (EST) Date: Mon, 15 Nov 2004 00:15:54 -0500 (EST) Message-Id: <200411150515.iAF5FsVr101820069@chips.research.att.com> From: Jennifer Rexford To: dchiou@avici.com Cc: psamp@ops.ietf.org In-reply-to: <4197E075.7090004@avici.com> (message from Derek Chiou on Sun, 14 Nov 2004 17:47:17 -0500) Subject: Re: comments on draft-ietf-psamp-framework-09.txt X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk >> - page 13-14: Under "content-dependent sampling" or "non-uniform >> probabilistic sampling," it may be helpful to include "sampling >> packets in proportion to their length" as an example. > > Doesn't "sampling packets in proportion to their length" fall into the > content _independent_ sampling? If you sample periodically by time, > you'll get sampling of packets in proportion to their length. I was trying to think of a meaningful example to make it more clear why content dependent sampling would be useful. The one thing that came to mind was sampling on the packet-length field in the IP header. That said, you are right that there are content-independent ways to sample this way, too, so perhaps it isn't a good choice for an example. In any case, I think including an example might be helpful here. > "However, if prior selection not based on routing state has reduced the > packet stream to below line rate, subselection based on routing state > may be feasible." Easier to parse, though still a little confusing. How could the packet stream on the line be above line rate? (Or, are you talking about the packets before they go into the output queue? Or, is the "line rate" the bandwidth allocated for psamp records? Is the idea that subselecting routing state [such as the prefix entry that matched the packet?] is not reasonable unless the sampled stream is low-rate enough to enable the look-ups to take place? But, isn't the lookup already done as part of regular packet handling? Hmmm, I think I still don't quite understand what the sentence is driving at.) Thanks! -- Jen -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 15 03:35:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07187 for ; Mon, 15 Nov 2004 03:35:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTcEU-000723-Uh for psamp-data@psg.com; Mon, 15 Nov 2004 08:29:06 +0000 Received: from [208.246.215.5] (helo=mailhost.avici.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTcEU-00071p-5M for psamp@ops.ietf.org; Mon, 15 Nov 2004 08:29:06 +0000 Received: from avici.com ([10.2.103.14]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAF8Swnh029179; Mon, 15 Nov 2004 03:28:58 -0500 Message-ID: <419868B6.10906@avici.com> Date: Mon, 15 Nov 2004 03:28:38 -0500 From: Derek Chiou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jennifer Rexford CC: psamp@ops.ietf.org Subject: Re: comments on draft-ietf-psamp-framework-09.txt References: <200411150515.iAF5FsVr101820069@chips.research.att.com> In-Reply-To: <200411150515.iAF5FsVr101820069@chips.research.att.com> Content-Type: multipart/alternative; boundary="------------050207000600070706060101" X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------050207000600070706060101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jennifer, Jennifer Rexford wrote: >>>- page 13-14: Under "content-dependent sampling" or "non-uniform >>>probabilistic sampling," it may be helpful to include "sampling >>>packets in proportion to their length" as an example. >>> >>> >>Doesn't "sampling packets in proportion to their length" fall into the >>content _independent_ sampling? If you sample periodically by time, >>you'll get sampling of packets in proportion to their length. >> >> > >I was trying to think of a meaningful example to make it more clear >why content dependent sampling would be useful. The one thing that >came to mind was sampling on the packet-length field in the IP header. >That said, you are right that there are content-independent ways to >sample this way, too, so perhaps it isn't a good choice for an example. >In any case, I think including an example might be helpful here. > An example is reasonable. A forward pointer to trajectory sampling might work? > > > >>"However, if prior selection not based on routing state has reduced the >>packet stream to below line rate, subselection based on routing state >>may be feasible." >> >> > >Easier to parse, though still a little confusing. How could the packet >stream on the line be above line rate? (Or, are you talking about the >packets before they go into the output queue? Or, is the "line rate" >the bandwidth allocated for psamp records? Is the idea that subselecting >routing state [such as the prefix entry that matched the packet?] is >not reasonable unless the sampled stream is low-rate enough to enable >the look-ups to take place? But, isn't the lookup already done as part >of regular packet handling? Hmmm, I think I still don't quite understand >what the sentence is driving at.) > Yes, if the PSAMP selector is embedded in a router, that router should be able to access routing state at line rate. However, the PSAMP selector may not be implemented in the fast path that is able to access routing state at line rate. It could be implemented as another stage in the fast path that does not have line-rate access to routing state or in the slow path that cannot access routing state at line-rate. However, if there are selectors that first reduce the packet stream to a more manageable rate (somewhere under line rate), it's possible that the slow path selector could select based on routing state. I think that's what this sentence is trying to say. Derek > >Thanks! > >-- Jen > > --------------050207000600070706060101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jennifer,

Jennifer Rexford wrote:
- page 13-14: Under "content-dependent sampling" or "non-uniform
probabilistic sampling," it may be helpful to include "sampling
packets in proportion to their length" as an example.
      
Doesn't "sampling packets in proportion to their length" fall into the
content _independent_ sampling?  If you sample periodically by time,
you'll get sampling of packets in proportion to their length.
    

I was trying to think of a meaningful example to make it more clear
why content dependent sampling would be useful.  The one thing that
came to mind was sampling on the packet-length field in the IP header.
That said, you are right that there are content-independent ways to
sample this way, too, so perhaps it isn't a good choice for an example.
In any case, I think including an example might be helpful here.
An example is reasonable.  A forward pointer to trajectory sampling might work?

  
"However, if prior selection not based on routing state has reduced the
packet stream to below line rate, subselection based on routing state
may be feasible."
    

Easier to parse, though still a little confusing.  How could the packet
stream on the line be above line rate?  (Or, are you talking about the
packets before they go into the output queue?  Or, is the "line rate"
the bandwidth allocated for psamp records?  Is the idea that subselecting
routing state [such as the prefix entry that matched the packet?] is
not reasonable unless the sampled stream is low-rate enough to enable
the look-ups to take place?  But, isn't the lookup already done as part
of regular packet handling?  Hmmm, I think I still don't quite understand
what the sentence is driving at.)
Yes, if the PSAMP selector is embedded in a router, that router should be able to access routing state at line rate.  However, the PSAMP selector may not be implemented in the fast path that is able to access routing state at line rate.  It could be implemented as another stage in the fast path that does not have line-rate access to routing state or in the slow path that cannot access routing state at line-rate.

However, if there are selectors that first reduce the packet stream to a more manageable rate (somewhere under line rate), it's possible that the slow path selector could select based on routing state.

I think that's what this sentence is trying to say.

Derek

Thanks!

-- Jen
--------------050207000600070706060101-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Nov 21 22:03:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23259 for ; Sun, 21 Nov 2004 22:03:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CW4Jr-000CbY-E7 for psamp-data@psg.com; Mon, 22 Nov 2004 02:52:47 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CW4Jn-000Cb1-5K for psamp@ops.ietf.org; Mon, 22 Nov 2004 02:52:43 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-green.research.att.com (Postfix) with ESMTP id B278FA7ADE; Sun, 21 Nov 2004 21:52:42 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: some comments on draft-ietf-psamp-framework-09.txt Date: Sun, 21 Nov 2004 21:52:42 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E10144659A@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: some comments on draft-ietf-psamp-framework-09.txt Thread-Index: AcTKnpwo5PHsU3DxSNePS1op2BV//ACPyRgg From: To: , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_05,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Derek, Thanks for your comments. See inline: > -----Original Message----- > From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On Behalf > Of Derek Chiou > Sent: Sunday, November 14, 2004 6:06 PM > To: psamp@ops.ietf.org > Subject: some comments on draft-ietf-psamp-framework-09.txt >=20 > Hi, >=20 > I've reviewed psamp-framework-09. It looks very good overall. I have > some (mostly very minor) comments that I've listed below. >=20 > Thanks. >=20 > Derek >=20 > *** draft-ietf-psamp-framework-09.txt Sun Nov 14 17:50:05 2004 > --- draft-ietf-psamp-framework-09-derek.txt Sun Nov 14 17:54:11 2004 > *************** > *** 45,47 **** > the components of this architecture, then describes some generic > ! requirements, motivated the dual aims of ubiquitous deployment > and utility of the reports for applications. Detailed > --- 45,47 ---- > the components of this architecture, then describes some generic > ! requirements AND MOTIVATES the dual aims of ubiquitous deployment > and utility of the reports for applications. Detailed > *************** Now reads:=20 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. > *** 174,179 **** >=20 > across multivendor domains. This requires domain wide consistency > in the types of selection schemes available, the manner in which > the resulting measurements are presented, and consequently, > ! consistency of the interpretation that can be put on them. >=20 > --- 174,179 ---- >=20 > across multivendor domains. This requires domain-wide consistency > in the types of selection schemes available, the manner in which > the resulting measurements are presented, and consequently, > ! CONSISTENT INTERPRETATION OF THE MEASUREMENTS. >=20 > *************** Now reads: This requires domain wide consistency in the types of selection schemes available, and the manner in which the resulting measurements are presented and interpreted. > *** 613,615 **** >=20 > ! * Encrypted Packets: Selectors that interpret of packet fields > must be configurable to ignore (i.e. not select) encrypted > --- 613,615 ---- >=20 > ! * Encrypted Packets: Selectors that interpret packet fields > must be configurable to ignore (i.e. not select) encrypted > *************** OK > *** 778,780 **** >=20 > ! * Probabilistic n-out-of-N Sampling: form each count-based > successive block of N packets, n are selected at random. > --- 778,780 ---- >=20 > ! * Probabilistic n-out-of-N Sampling: from each count-based > successive block of N packets, n are selected at random. > *************** OK > *** 825,829 **** > applied to a subset of packet content, and the packet is > ! selected of the resulting hash falls in a specified range. With > ! a suitable hash function, hash based selection approximates > ! uniform random sampling. Applications of hash-based sampling > are described in Section 11. > --- 825,829 ---- > applied to a subset of packet content, and the packet is > ! selected if the resulting hash falls in a specified range. With > ! a suitable hash function, hash-based selection approximates > ! uniform random sampling (NOT NECESSARILY). Applications of > hash-based sampling > are described in Section 11. >=20 > THOUGH IN GENERAL HASH-BASED SELECTION MAY APPROXIMATE UNIFORM RANDOM > SAMPLING, PACKETS THAT LOOK THE SAME TO THE HASH ARE ALWAYS GOING TO BE > TREATED THE SAME AS THE HASH. THUS, A DOS ATTACK THAT KNOWS THE HASH > CAN ESCAPE DETECTION BY A HASH-BASED SELECTOR BUT CANNOT ESCAPE > DETECTION BY A UNIFORM RANDOM SAMPLING SELECTOR. I MAY HAVE COMMENTED > ON THIS BEFORE, BUT I FIGURE I'LL SAY IT AGAIN. >=20 Just knowing the hash is not enough. The attacker has to know the selection range (which could be private) to determine whether the packet is selected. All this is discussed more in the sampling techniques draft. So I propose to Replaced:=20 "With a suitable hash function, hash-based selection approximates uniform random sampling." With: "The stronger the hash function, the more closely hash-based selection approximates uniform random sampling. Robustness and security considerations of hash-based selection are discussed in [PSAMP-TECH]." > *************** > *** 959,962 **** > the Attained Selection Fraction > ! > ! With Composite Selectors, and input sequence number must be > reported for each Selector in the composition. > --- 959,962 ---- > the Attained Selection Fraction > ! > ! With Composite Selectors, an input sequence number must be > reported for each Selector in the composition. OK > *************** > *** 1112,1114 **** > expected to be relatively static; they could be communicated > ! periodically, and upon change. >=20 > --- 1112,1118 ---- > expected to be relatively static; they could be communicated > ! periodically, and upon change. > ! > ! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, MEASUREMENT > ! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN EVERY > ! PACKET REPORT? Since an export packet may contain multiple packet reports, the export process id can be included once per export packet. >=20 > *************** > *** 1172,1174 **** > In order to jointly satisfy the timeliness and congestion > ! avoidance requirements of Section 4.3, a congestion aware > unreliable transport protocol must be used. IPFIX is compatible > --- 1176,1178 ---- > In order to jointly satisfy the timeliness and congestion > ! avoidance requirements of Section 4.3, a congestion-aware > unreliable transport protocol must be used. IPFIX is compatible > *************** > *** 1178,1180 **** > User Datagram Protocol (UDP) [UDP] although it is not a > ! congestion aware protocol. However, in this case, the Export > Packets must remain wholly within the administrative domains of > --- 1182,1184 ---- > User Datagram Protocol (UDP) [UDP] although it is not a > ! congestion-aware protocol. However, in this case, the Export > Packets must remain wholly within the administrative domains of > *************** > *** 1194,1196 **** > category would include: identifying sources associated with > ! congestion; tracing denial of service attacks through the network > and constructing traffic matrices. Furthermore, keeping dispatch > --- 1198,1200 ---- > category would include: identifying sources associated with > ! congestion, tracing denial of service attacks through the network > and constructing traffic matrices. Furthermore, keeping dispatch > *************** OK > *** 1239,1240 **** > --- 1243,1247 ---- > the buffer exceeds a configurable bound. > + > + COLLECTOR MAY SEE VERY LOW SAMPLED PACKET RATES BECAUSE OF > + MISCONFIGURATION HERE. >=20 Can a sensible default value help here? >=20 > *************** > *** 1509,1511 **** > sampling if necessary to manage the attained fraction of packets > ! selected >=20 > --- 1517,1519 ---- > sampling if necessary to manage the attained fraction of packets > ! selected. >=20 >=20 OK >=20 >=20 > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Nov 21 23:57:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01387 for ; Sun, 21 Nov 2004 23:57:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CW6A6-000PbP-C7 for psamp-data@psg.com; Mon, 22 Nov 2004 04:50:50 +0000 Received: from [192.20.225.112] (helo=mail-yellow.research.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CW6A3-000Pb4-C3 for psamp@ops.ietf.org; Mon, 22 Nov 2004 04:50:47 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 7A8FF1974C7; Sun, 21 Nov 2004 23:40:13 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: comments on draft-ietf-psamp-framework-09.txt Date: Sun, 21 Nov 2004 23:50:46 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1014465AA@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: comments on draft-ietf-psamp-framework-09.txt Thread-Index: AcTK7XfaFSvSLmw8QLmzDNEiNsxCKwFW4TegAAAEyNA= From: To: , , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Derek, Jennifer, See comments inline below: > ________________________________________ > From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On = Behalf > Of Derek Chiou > Sent: Monday, November 15, 2004 3:29 AM > To: Rexford,Jennifer L (Jennifer) > Cc: psamp@ops.ietf.org > Subject: Re: comments on draft-ietf-psamp-framework-09.txt >=20 > Hi Jennifer, >=20 > Jennifer Rexford wrote: >=20 > - page 13-14: Under "content-dependent sampling" or "non-uniform > probabilistic sampling," it may be helpful to include "sampling > packets in proportion to their length" as an example. >=20 > Doesn't "sampling packets in proportion to their length" fall into the > content _independent_ sampling? If you sample periodically by time, > you'll get sampling of packets in proportion to their length. >=20 >=20 > I was trying to think of a meaningful example to make it more clear > why content dependent sampling would be useful. The one thing that > came to mind was sampling on the packet-length field in the IP header. > That said, you are right that there are content-independent ways to > sample this way, too, so perhaps it isn't a good choice for an = example. > In any case, I think including an example might be helpful here. > An example is reasonable.=A0 A forward pointer to trajectory sampling = might > work? >=20 Another example is "sampling packets with a probability dependent on = application type as indicated by TCP/UDP port number". I propose to use = this example rather than include a discussion about different ways to do = packet length proportional sampling. Or perhaps people want a discussion = on the shortcomings of using port numbers to attribute applications = type....=20 Trajectory sampling is treated as filter (i.e. deterministic selection = according to packet content) so it not an example here. >=20 >=20 >=20 > "However, if prior selection not based on routing state has reduced = the > packet stream to below line rate, subselection based on routing state > may be feasible." >=20 >=20 > Easier to parse, though still a little confusing. How could the = packet > stream on the line be above line rate? (Or, are you talking about the > packets before they go into the output queue? Or, is the "line rate" > the bandwidth allocated for psamp records? Is the idea that = subselecting > routing state [such as the prefix entry that matched the packet?] is > not reasonable unless the sampled stream is low-rate enough to enable > the look-ups to take place? But, isn't the lookup already done as = part > of regular packet handling? Hmmm, I think I still don't quite = understand > what the sentence is driving at.) > Yes, if the PSAMP selector is embedded in a router, that router should = be > able to access routing state at line rate.=A0 However, the PSAMP = selector > may not be implemented in the fast path that is able to access routing > state at line rate.=A0 It could be implemented as another stage in the = fast > path that does not have line-rate access to routing state or in the = slow > path that cannot access routing state at line-rate. >=20 > However, if there are selectors that first reduce the packet stream to = a > more manageable rate (somewhere under line rate), it's possible that = the > slow path selector could select based on routing state. >=20 > I think that's what this sentence is trying to say. How about: Router architectural considerations may preclude some information = concerning the packet treatment being available at line rate for = selection of packets. For example, the Selection Process may not be = implemented in the fast path that is able to access routing state at = line rate. However, when filtering follows sampling in a Composite = Selector, the rate of the Packet Stream output from the sampler and = input to the filter may be sufficiently slow that the filter could = select based on routing state. >=20 > Derek >=20 >=20 >=20 > Thanks! >=20 > -- Jen >=20 Nick -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 22 01:23:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07068 for ; Mon, 22 Nov 2004 01:23:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CW7V5-0008k9-4R for psamp-data@psg.com; Mon, 22 Nov 2004 06:16:35 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CW7V4-0008jx-8z for psamp@ops.ietf.org; Mon, 22 Nov 2004 06:16:34 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-blue.research.att.com (Postfix) with ESMTP id B95C21974C7 for ; Mon, 22 Nov 2004 01:05:59 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: comments on draft-ietf-psamp-framework-09.txt Date: Mon, 22 Nov 2004 01:16:33 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1014465AC@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: comments on draft-ietf-psamp-framework-09.txt Thread-Index: AcTJnuHLeMVDYEVwRAKbvezL896NwgGtD2Kg From: To: Cc: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >=20 > - page 21: Section 8.2 talks about the need for unreliable, > congestion-aware transport, and shifts in the last paragraph to > talking about IPFIX rather than PSAMP. I wasn't sure what the the > IPFIX paragraph was trying to get at, and if/how it relates to the way > PSAMP should achieve congestion-aware transport. Somewhere in the > document (either in 8.2, 8.5, or in 10.2), it would be worth > commenting on lighweight ways to achieve the goal of congestion-aware > transport. Section 8.2 could end by saying something like > "Congestion-aware transport of PSAMP records could be achieved in > various ways. For example, the PSAMP device could have an export rate > limit (as discussed in Section 8.5) that is configured by the > controller based on observations of the packet loss rate in delivering > PSAMP records. This would ensure that the transport rate adapts in > the presence of congestion without requiring the PSAMP device to > receive acknowledgment packets or implement the adaptation algorithm > directly." I think this is important for conveying how the requirement > of congestion-aware transport can be satisfied without introducing > a lot of complexity in a PSAMP device that much operate at high speed. >=20 This is a good point which has been lost in the recent draft modifications.=20 Lightweight implementations of PSAMP, with e.g. - a relatively dumb device - supports only 1 in N periodic sampling - supports basic packet reports (the first m bytes) - export using UDP (now allowed by IPFIX) do not require all of IPFIX to be implemented for them to function. (Just insert required sequence numbers and identifiers for observation point and PSAMP processes in reports and use UDP export). So we need also to qualify, in Section 8.1. at least, that not all of IPFIX need be supported by a PSAMP device. The details would be pinned down in the PSAMP protocol document. Nick -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 22 04:07:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03804 for ; Mon, 22 Nov 2004 04:07:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWA3r-00013p-2D for psamp-data@psg.com; Mon, 22 Nov 2004 09:00:39 +0000 Received: from [208.246.215.5] (helo=mailhost.avici.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWA3m-000133-1r for psamp@ops.ietf.org; Mon, 22 Nov 2004 09:00:34 +0000 Received: from avici.com ([10.2.104.12]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAM90R4I017042; Mon, 22 Nov 2004 04:00:29 -0500 Message-ID: <41A1AAAB.8070406@avici.com> Date: Mon, 22 Nov 2004 04:00:27 -0500 From: Derek Chiou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: duffield@research.att.com CC: psamp@ops.ietf.org Subject: Re: some comments on draft-ietf-psamp-framework-09.txt References: <387B5A9BF31B5D43A2B18DD9F326B8E10144659A@NJFPSRVEXG2KCL.research.att.com> In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E10144659A@NJFPSRVEXG2KCL.research.att.com> Content-Type: multipart/alternative; boundary="------------020503020208030508070702" X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,HTML_40_50, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------020503020208030508070702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Nick, A couple of in-lined comments. duffield@research.att.com wrote: >Derek, > >Thanks for your comments. See inline: > > > >>-----Original Message----- >>From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On >> >> >Behalf > > >>Of Derek Chiou >>Sent: Sunday, November 14, 2004 6:06 PM >>To: psamp@ops.ietf.org >>Subject: some comments on draft-ietf-psamp-framework-09.txt >> >>Hi, >> >>I've reviewed psamp-framework-09. It looks very good overall. I have >>some (mostly very minor) comments that I've listed below. >> >>Thanks. >> >>Derek >> >>*** draft-ietf-psamp-framework-09.txt Sun Nov 14 17:50:05 2004 >>--- draft-ietf-psamp-framework-09-derek.txt Sun Nov 14 17:54:11 >> >> >2004 > > >>*************** >>*** 45,47 **** >> the components of this architecture, then describes some >> >> >generic > > >>! requirements, motivated the dual aims of ubiquitous deployment >> and utility of the reports for applications. Detailed >>--- 45,47 ---- >> the components of this architecture, then describes some >> >> >generic > > >>! requirements AND MOTIVATES the dual aims of ubiquitous >> >> >deployment > > >> and utility of the reports for applications. Detailed >>*************** >> >> > >Now reads: > >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. > > > > >>*** 174,179 **** >> >> across multivendor domains. This requires domain wide >> >> >consistency > > >> in the types of selection schemes available, the manner in >> >> >which > > >> the resulting measurements are presented, and consequently, >>! consistency of the interpretation that can be put on them. >> >>--- 174,179 ---- >> >> across multivendor domains. This requires domain-wide >> >> >consistency > > >> in the types of selection schemes available, the manner in >> >> >which > > >> the resulting measurements are presented, and consequently, >>! CONSISTENT INTERPRETATION OF THE MEASUREMENTS. >> >>*************** >> >> > >Now reads: > >This requires domain wide consistency in the types of selection schemes >available, and the manner in which the resulting measurements are >presented and interpreted. > domain-wide > > > >>*** 613,615 **** >> >>! * Encrypted Packets: Selectors that interpret of packet fields >> must be configurable to ignore (i.e. not select) encrypted >>--- 613,615 ---- >> >>! * Encrypted Packets: Selectors that interpret packet fields >> must be configurable to ignore (i.e. not select) encrypted >>*************** >> >> > > >OK > > > >>*** 778,780 **** >> >>! * Probabilistic n-out-of-N Sampling: form each count-based >> successive block of N packets, n are selected at random. >>--- 778,780 ---- >> >>! * Probabilistic n-out-of-N Sampling: from each count-based >> successive block of N packets, n are selected at random. >>*************** >> >> > >OK > > > >>*** 825,829 **** >> applied to a subset of packet content, and the packet is >>! selected of the resulting hash falls in a specified range. >> >> >With > > >>! a suitable hash function, hash based selection approximates >>! uniform random sampling. Applications of hash-based sampling >> are described in Section 11. >>--- 825,829 ---- >> applied to a subset of packet content, and the packet is >>! selected if the resulting hash falls in a specified range. >> >> >With > > >>! a suitable hash function, hash-based selection approximates >>! uniform random sampling (NOT NECESSARILY). Applications of >>hash-based sampling >> are described in Section 11. >> >>THOUGH IN GENERAL HASH-BASED SELECTION MAY APPROXIMATE UNIFORM RANDOM >>SAMPLING, PACKETS THAT LOOK THE SAME TO THE HASH ARE ALWAYS GOING TO >> >> >BE > > >>TREATED THE SAME AS THE HASH. THUS, A DOS ATTACK THAT KNOWS THE HASH >>CAN ESCAPE DETECTION BY A HASH-BASED SELECTOR BUT CANNOT ESCAPE >>DETECTION BY A UNIFORM RANDOM SAMPLING SELECTOR. I MAY HAVE COMMENTED >>ON THIS BEFORE, BUT I FIGURE I'LL SAY IT AGAIN. >> >> >> >Just knowing the hash is not enough. The attacker has to know the >selection range (which could be private) to determine whether the packet >is selected. All this is discussed more in the sampling techniques >draft. So I propose to > >Replaced: > >"With a suitable hash function, hash-based selection approximates >uniform random sampling." > >With: > >"The stronger the hash function, the more closely hash-based selection >approximates uniform random sampling. Robustness and security >considerations of hash-based selection are discussed in [PSAMP-TECH]." > Do we have to say that a hash approximates uniform random sampling? It does, most of the time, but it's tough to beat uniform random sampling and with insider information one could defeat a hash. > > > >>*************** >>*** 959,962 **** >> the Attained Selection Fraction >>! >>! With Composite Selectors, and input sequence number must be >> reported for each Selector in the composition. >>--- 959,962 ---- >> the Attained Selection Fraction >>! >>! With Composite Selectors, an input sequence number must be >> reported for each Selector in the composition. >> >> > >OK > > > >>*************** >>*** 1112,1114 **** >> expected to be relatively static; they could be communicated >>! periodically, and upon change. >> >>--- 1112,1118 ---- >> expected to be relatively static; they could be communicated >>! periodically, and upon change. >>! >>! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, MEASUREMENT >>! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN EVERY >>! PACKET REPORT? >> >> > > >Since an export packet may contain multiple packet reports, the export >process id can be included once per export packet. > > > >>*************** >>*** 1172,1174 **** >> In order to jointly satisfy the timeliness and congestion >>! avoidance requirements of Section 4.3, a congestion aware >> unreliable transport protocol must be used. IPFIX is >> >> >compatible > > >>--- 1176,1178 ---- >> In order to jointly satisfy the timeliness and congestion >>! avoidance requirements of Section 4.3, a congestion-aware >> unreliable transport protocol must be used. IPFIX is >> >> >compatible > > >>*************** >>*** 1178,1180 **** >> User Datagram Protocol (UDP) [UDP] although it is not a >>! congestion aware protocol. However, in this case, the Export >> Packets must remain wholly within the administrative domains >> >> >of > > >>--- 1182,1184 ---- >> User Datagram Protocol (UDP) [UDP] although it is not a >>! congestion-aware protocol. However, in this case, the Export >> Packets must remain wholly within the administrative domains >> >> >of > > >>*************** >>*** 1194,1196 **** >> category would include: identifying sources associated with >>! congestion; tracing denial of service attacks through the >> >> >network > > >> and constructing traffic matrices. Furthermore, keeping >> >> >dispatch > > >>--- 1198,1200 ---- >> category would include: identifying sources associated with >>! congestion, tracing denial of service attacks through the >> >> >network > > >> and constructing traffic matrices. Furthermore, keeping >> >> >dispatch > > >>*************** >> >> > > >OK > > > >>*** 1239,1240 **** >>--- 1243,1247 ---- >> the buffer exceeds a configurable bound. >>+ >>+ COLLECTOR MAY SEE VERY LOW SAMPLED PACKET RATES BECAUSE OF >>+ MISCONFIGURATION HERE. >> >> >> > >Can a sensible default value help here? > Yes. > > > >>*************** >>*** 1509,1511 **** >> sampling if necessary to manage the attained fraction of >> >> >packets > > >>! selected >> >>--- 1517,1519 ---- >> sampling if necessary to manage the attained fraction of >> >> >packets > > >>! selected. >> >> >> >> > >OK > > >>-- >>to unsubscribe send a message to psamp-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> > > > --------------020503020208030508070702 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Nick,

A couple of in-lined comments.

duffield@research.att.com wrote:
Derek,

Thanks for your comments. See inline:

  
-----Original Message-----
From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
    
Behalf
  
Of Derek Chiou
Sent: Sunday, November 14, 2004 6:06 PM
To: psamp@ops.ietf.org
Subject: some comments on draft-ietf-psamp-framework-09.txt

Hi,

I've reviewed psamp-framework-09.  It looks very good overall.  I have
some (mostly very minor) comments that I've listed below.

Thanks.

Derek

*** draft-ietf-psamp-framework-09.txt    Sun Nov 14 17:50:05 2004
--- draft-ietf-psamp-framework-09-derek.txt    Sun Nov 14 17:54:11
    
2004
  
***************
*** 45,47 ****
        the components of this architecture, then describes some
    
generic
  
!       requirements, motivated the dual aims of ubiquitous deployment
        and utility of the reports for applications. Detailed
--- 45,47 ----
        the components of this architecture, then describes some
    
generic
  
!       requirements AND MOTIVATES the dual aims of ubiquitous
    
deployment
  
        and utility of the reports for applications. Detailed
***************
    

Now reads: 

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.


  
*** 174,179 ****

        across multivendor domains. This requires domain wide
    
consistency
  
        in the types of selection schemes available, the manner in
    
which
  
        the resulting measurements are presented, and consequently,
!       consistency of the interpretation that can be put on them.

--- 174,179 ----

        across multivendor domains. This requires domain-wide
    
consistency
  
        in the types of selection schemes available, the manner in
    
which
  
        the resulting measurements are presented, and consequently,
!       CONSISTENT INTERPRETATION OF THE MEASUREMENTS.

***************
    

Now reads:

This requires domain wide consistency in the types of selection schemes
available, and the manner in which the resulting measurements are
presented and interpreted.
domain-wide

  
*** 613,615 ****

!       * Encrypted Packets: Selectors that interpret of packet fields
          must be configurable to ignore (i.e. not select) encrypted
--- 613,615 ----

!       * Encrypted Packets: Selectors that interpret packet fields
          must be configurable to ignore (i.e. not select) encrypted
***************
    


OK

  
*** 778,780 ****

!       * Probabilistic n-out-of-N Sampling: form each count-based
          successive block of N packets, n are selected at random.
--- 778,780 ----

!       * Probabilistic n-out-of-N Sampling: from each count-based
          successive block of N packets, n are selected at random.
***************
    

OK

  
*** 825,829 ****
          applied to a subset of packet content, and the packet is
!         selected of the resulting hash falls in a specified range.
    
With
  
!         a suitable hash function, hash based selection approximates
!         uniform random sampling. Applications of hash-based sampling
          are described in Section 11.
--- 825,829 ----
          applied to a subset of packet content, and the packet is
!         selected if the resulting hash falls in a specified range.
    
With
  
!         a suitable hash function, hash-based selection approximates
!         uniform random sampling (NOT NECESSARILY). Applications of
hash-based sampling
          are described in Section 11.

THOUGH IN GENERAL HASH-BASED SELECTION MAY APPROXIMATE UNIFORM RANDOM
SAMPLING, PACKETS THAT LOOK THE SAME TO THE HASH ARE ALWAYS GOING TO
    
BE
  
TREATED THE SAME AS THE HASH.  THUS, A DOS ATTACK THAT KNOWS THE HASH
CAN ESCAPE DETECTION BY A HASH-BASED SELECTOR BUT CANNOT ESCAPE
DETECTION BY A UNIFORM RANDOM SAMPLING SELECTOR.  I MAY HAVE COMMENTED
ON THIS BEFORE, BUT I FIGURE I'LL SAY IT AGAIN.

    
Just knowing the hash is not enough. The attacker has to know the
selection range (which could be private) to determine whether the packet
is selected. All this is discussed more in the sampling techniques
draft. So I propose to

Replaced: 

"With a suitable hash function, hash-based selection approximates
uniform random sampling."

With:

"The stronger the hash function, the more closely hash-based selection
approximates uniform random sampling. Robustness and security
considerations of hash-based selection are discussed in [PSAMP-TECH]."

Do we have to say that a hash approximates uniform random sampling?  It does, most of the time, but it's tough to beat uniform random sampling and with insider information one could defeat a hash.  


  
***************
*** 959,962 ****
        the Attained Selection Fraction
!
!       With Composite Selectors, and input sequence number must be
        reported for each Selector in the composition.
--- 959,962 ----
        the Attained Selection Fraction
!
!       With Composite Selectors, an input sequence number must be
        reported for each Selector in the composition.
    

OK

  
***************
*** 1112,1114 ****
        expected to be relatively static; they could be communicated
!       periodically, and upon change.

--- 1112,1118 ----
        expected to be relatively static; they could be communicated
!       periodically, and upon change.
!
!       SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, MEASUREMENT
!       PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN EVERY
!       PACKET REPORT?
    


Since an export packet may contain multiple packet reports, the export
process id can be included once per export packet.

  
***************
*** 1172,1174 ****
        In order to jointly satisfy the timeliness and congestion
!       avoidance requirements of Section 4.3, a congestion aware
        unreliable transport protocol must be used. IPFIX is
    
compatible
  
--- 1176,1178 ----
        In order to jointly satisfy the timeliness and congestion
!       avoidance requirements of Section 4.3, a congestion-aware
        unreliable transport protocol must be used. IPFIX is
    
compatible
  
***************
*** 1178,1180 ****
        User Datagram Protocol (UDP) [UDP] although it is not a
!       congestion aware protocol. However, in this case, the Export
        Packets must remain wholly within the administrative domains
    
of
  
--- 1182,1184 ----
        User Datagram Protocol (UDP) [UDP] although it is not a
!       congestion-aware protocol. However, in this case, the Export
        Packets must remain wholly within the administrative domains
    
of
  
***************
*** 1194,1196 ****
        category would include: identifying sources associated with
!       congestion; tracing denial of service attacks through the
    
network
  
        and constructing traffic matrices. Furthermore, keeping
    
dispatch
  
--- 1198,1200 ----
        category would include: identifying sources associated with
!       congestion, tracing denial of service attacks through the
    
network
  
        and constructing traffic matrices. Furthermore, keeping
    
dispatch
  
***************
    


OK

  
*** 1239,1240 ****
--- 1243,1247 ----
        the buffer exceeds a configurable bound.
+
+       COLLECTOR MAY SEE VERY LOW SAMPLED PACKET RATES BECAUSE OF
+       MISCONFIGURATION HERE.

    

Can a sensible default value help here?
Yes.

  
***************
*** 1509,1511 ****
        sampling if necessary to manage the attained fraction of
    
packets
  
!       selected

--- 1517,1519 ----
        sampling if necessary to manage the attained fraction of
    
packets
  
!       selected.


    

OK
  
--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>
--------------020503020208030508070702-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 22 04:11:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04164 for ; Mon, 22 Nov 2004 04:11:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWA6l-0001Vv-S5 for psamp-data@psg.com; Mon, 22 Nov 2004 09:03:39 +0000 Received: from [208.246.215.5] (helo=mailhost.avici.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWA6k-0001VY-J9 for psamp@ops.ietf.org; Mon, 22 Nov 2004 09:03:38 +0000 Received: from avici.com ([10.2.104.12]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAM9384I017956; Mon, 22 Nov 2004 04:03:09 -0500 Message-ID: <41A1AB4C.6090202@avici.com> Date: Mon, 22 Nov 2004 04:03:08 -0500 From: Derek Chiou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: duffield@research.att.com CC: jrex@att.com, psamp@ops.ietf.org Subject: Re: comments on draft-ietf-psamp-framework-09.txt References: <387B5A9BF31B5D43A2B18DD9F326B8E1014465AA@NJFPSRVEXG2KCL.research.att.com> In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E1014465AA@NJFPSRVEXG2KCL.research.att.com> Content-Type: multipart/alternative; boundary="------------000308090503020202040402" X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000308090503020202040402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit duffield@research.att.com wrote: >Derek, Jennifer, > >See comments inline below: > > > >>________________________________________ >>From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On Behalf >>Of Derek Chiou >>Sent: Monday, November 15, 2004 3:29 AM >>To: Rexford,Jennifer L (Jennifer) >>Cc: psamp@ops.ietf.org >>Subject: Re: comments on draft-ietf-psamp-framework-09.txt >> >>Hi Jennifer, >> >>Jennifer Rexford wrote: >> >>- page 13-14: Under "content-dependent sampling" or "non-uniform >>probabilistic sampling," it may be helpful to include "sampling >>packets in proportion to their length" as an example. >> >>Doesn't "sampling packets in proportion to their length" fall into the >>content _independent_ sampling? If you sample periodically by time, >>you'll get sampling of packets in proportion to their length. >> >> >>I was trying to think of a meaningful example to make it more clear >>why content dependent sampling would be useful. The one thing that >>came to mind was sampling on the packet-length field in the IP header. >>That said, you are right that there are content-independent ways to >>sample this way, too, so perhaps it isn't a good choice for an example. >>In any case, I think including an example might be helpful here. >>An example is reasonable. A forward pointer to trajectory sampling might >>work? >> >> >> > >Another example is "sampling packets with a probability dependent on application type as indicated by TCP/UDP port number". I propose to use this example rather than include a discussion about different ways to do packet length proportional sampling. Or perhaps people want a discussion on the shortcomings of using port numbers to attribute applications type.... > You could say "sampling packets with a probability dependent on a TCP/UDP port number" and not mention the mapping to application. > >Trajectory sampling is treated as filter (i.e. deterministic selection according to packet content) so it not an example here. > > > >> >>"However, if prior selection not based on routing state has reduced the >>packet stream to below line rate, subselection based on routing state >>may be feasible." >> >> >>Easier to parse, though still a little confusing. How could the packet >>stream on the line be above line rate? (Or, are you talking about the >>packets before they go into the output queue? Or, is the "line rate" >>the bandwidth allocated for psamp records? Is the idea that subselecting >>routing state [such as the prefix entry that matched the packet?] is >>not reasonable unless the sampled stream is low-rate enough to enable >>the look-ups to take place? But, isn't the lookup already done as part >>of regular packet handling? Hmmm, I think I still don't quite understand >>what the sentence is driving at.) >>Yes, if the PSAMP selector is embedded in a router, that router should be >>able to access routing state at line rate. However, the PSAMP selector >>may not be implemented in the fast path that is able to access routing >>state at line rate. It could be implemented as another stage in the fast >>path that does not have line-rate access to routing state or in the slow >>path that cannot access routing state at line-rate. >> >>However, if there are selectors that first reduce the packet stream to a >>more manageable rate (somewhere under line rate), it's possible that the >>slow path selector could select based on routing state. >> >>I think that's what this sentence is trying to say. >> >> > > >How about: > >Router architectural considerations may preclude some information concerning the packet treatment being available at line rate for selection of packets. For example, the Selection Process may not be implemented in the fast path that is able to access routing state at line rate. However, when filtering follows sampling in a Composite Selector, the rate of the Packet Stream output from the sampler and input to the filter may be sufficiently slow that the filter could select based on routing state. > Looks good to me. > > > > >>Derek >> >> >> >>Thanks! >> >>-- Jen >> >> >> > >Nick > > > --------------000308090503020202040402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

duffield@research.att.com wrote:
Derek, Jennifer,

See comments inline below:

  
________________________________________
From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On Behalf
Of Derek Chiou
Sent: Monday, November 15, 2004 3:29 AM
To: Rexford,Jennifer L (Jennifer)
Cc: psamp@ops.ietf.org
Subject: Re: comments on draft-ietf-psamp-framework-09.txt

Hi Jennifer,

Jennifer Rexford wrote:

- page 13-14: Under "content-dependent sampling" or "non-uniform
probabilistic sampling," it may be helpful to include "sampling
packets in proportion to their length" as an example.

Doesn't "sampling packets in proportion to their length" fall into the
content _independent_ sampling?  If you sample periodically by time,
you'll get sampling of packets in proportion to their length.


I was trying to think of a meaningful example to make it more clear
why content dependent sampling would be useful.  The one thing that
came to mind was sampling on the packet-length field in the IP header.
That said, you are right that there are content-independent ways to
sample this way, too, so perhaps it isn't a good choice for an example.
In any case, I think including an example might be helpful here.
An example is reasonable.  A forward pointer to trajectory sampling might
work?

    

Another example is "sampling packets with a probability dependent on application type as indicated by TCP/UDP port number". I propose to use this example rather than include a discussion about different ways to do packet length proportional sampling. Or perhaps people want a discussion on the shortcomings of using port numbers to attribute applications type....
You could say "sampling packets with a probability dependent on a TCP/UDP port number" and not mention the mapping to application.  

Trajectory sampling is treated as filter (i.e. deterministic selection according to packet content) so it not an example here.

  

"However, if prior selection not based on routing state has reduced the
packet stream to below line rate, subselection based on routing state
may be feasible."


Easier to parse, though still a little confusing.  How could the packet
stream on the line be above line rate?  (Or, are you talking about the
packets before they go into the output queue?  Or, is the "line rate"
the bandwidth allocated for psamp records?  Is the idea that subselecting
routing state [such as the prefix entry that matched the packet?] is
not reasonable unless the sampled stream is low-rate enough to enable
the look-ups to take place?  But, isn't the lookup already done as part
of regular packet handling?  Hmmm, I think I still don't quite understand
what the sentence is driving at.)
Yes, if the PSAMP selector is embedded in a router, that router should be
able to access routing state at line rate.  However, the PSAMP selector
may not be implemented in the fast path that is able to access routing
state at line rate.  It could be implemented as another stage in the fast
path that does not have line-rate access to routing state or in the slow
path that cannot access routing state at line-rate.

However, if there are selectors that first reduce the packet stream to a
more manageable rate (somewhere under line rate), it's possible that the
slow path selector could select based on routing state.

I think that's what this sentence is trying to say.
    


How about:

Router architectural considerations may preclude some information concerning the packet treatment being available at line rate for selection of packets. For example, the Selection Process may not be implemented in the fast path that is able to access routing state at line rate. However, when filtering follows sampling in a Composite Selector, the rate of the Packet Stream output from the sampler and input to the filter may be sufficiently slow that the filter could select based on routing state.
Looks good to me.


  
Derek



Thanks!

-- Jen

    

Nick
--------------000308090503020202040402-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 22 07:22:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23837 for ; Mon, 22 Nov 2004 07:22:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWD6R-000N3b-IE for psamp-data@psg.com; Mon, 22 Nov 2004 12:15:31 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWD6F-000N1g-OD for psamp@ops.ietf.org; Mon, 22 Nov 2004 12:15:19 +0000 Received: from chips.research.att.com (chips.research.att.com [135.207.27.139]) by mail-green.research.att.com (Postfix) with ESMTP id 28591A7B07; Mon, 22 Nov 2004 07:15:19 -0500 (EST) Received: from chips.research.att.com (localhost [127.0.0.1]) by chips.research.att.com (SGI-8.12.5/8.12.5) with ESMTP id iAMCFIav111083436; Mon, 22 Nov 2004 07:15:18 -0500 (EST) Received: (from jrex@localhost) by chips.research.att.com (SGI-8.12.5/8.12.5/Submit) id iAMCFILB110153626; Mon, 22 Nov 2004 07:15:18 -0500 (EST) Date: Mon, 22 Nov 2004 07:15:18 -0500 (EST) Message-Id: <200411221215.iAMCFILB110153626@chips.research.att.com> From: Jennifer Rexford To: duffield@research.att.com Cc: dchiou@avici.com, psamp@ops.ietf.org In-reply-to: <387B5A9BF31B5D43A2B18DD9F326B8E1014465AA@NJFPSRVEXG2KCL.research.att.com> (message from Nick Duffield on Sun, 21 Nov 2004 23:50:46 -0500) Subject: Re: comments on draft-ietf-psamp-framework-09.txt References: <387B5A9BF31B5D43A2B18DD9F326B8E1014465AA@NJFPSRVEXG2KCL.research.att.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk > Router architectural considerations may preclude some information > concerning the packet treatment being available at line rate for > selection of packets. For example, the Selection Process may not be > implemented in the fast path that is able to access routing state at > line rate. However, when filtering follows sampling in a Composite > Selector, the rate of the Packet Stream output from the sampler and > input to the filter may be sufficiently slow that the filter could > select based on routing state. That's great, thanks! -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 22 13:14:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28452 for ; Mon, 22 Nov 2004 13:14:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWIae-000CL4-Hm for psamp-data@psg.com; Mon, 22 Nov 2004 18:07:04 +0000 Received: from [128.178.156.22] (helo=lca2pc10.epfl.ch) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWIaT-000CJ2-A0 for psamp@ops.ietf.org; Mon, 22 Nov 2004 18:06:54 +0000 Received: from epfl.ch (localhost [127.0.0.1]) by lca2pc10.epfl.ch (Postfix) with ESMTP id 3B5F85082D for ; Mon, 22 Nov 2004 19:06:51 +0100 (CET) Message-ID: <41A22ABB.2080103@epfl.ch> Date: Mon, 22 Nov 2004 19:06:51 +0100 From: Matthias Grossglauser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: Re: some comments on draft-ietf-psamp-framework-09.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I think the document is in very good shape. A few comments below. I will send a list of minor typos directly to the editor. Matt >- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency". >Also, the term "non-contingency" seems a bit strange. > > A good term might be "causality". >>> Regarding the discussion of "attacks" against hash-based PSAMP by crafting packets, let me refer back to a comment a made a while ago: https://www.psg.com/lists/psamp/psamp.2002/msg00170.html Basically, if the attacker does not know which hash function in the family is active, then this provides *stronger* protection than if the attacker knows the hash function, but not the range it has to fall into to get sampled. This might be worth pointing out. It is alluded to the in draft by saying that there can be a family of hash functions, but it could perhaps be strengthened by pointing out that this provides additional robustness against crafted packets. >*************** >> *** 1112,1114 **** >> expected to be relatively static; they could be communicated >> ! periodically, and upon change. >> >> --- 1112,1118 ---- >> expected to be relatively static; they could be communicated >> ! periodically, and upon change. >> ! >> ! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, MEASUREMENT >> ! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN EVERY >> ! PACKET REPORT? > > > > >Since an export packet may contain multiple packet reports, the export >process id can be included once per export packet. > > > Did we say anywhere that exporting process IDs are included? Note that this is important to enable the collector to estimate the Export Packet drop rate under unreliable transport to drive a congestion-control algorithm; the finer per-report IDs are not necessarily sufficient for this, I think. Of course, in most situations the underlying unreliable transport protocol would have sequence numbers already, but it might be desirable to have a transport-independent EP numbering for layer independence. >How about: > >Router architectural considerations may preclude some information concerning the packet treatment being available at line rate for selection of packets. For example, the Selection Process may not be implemented in the fast path that is able to access routing state at line rate. However, when filtering follows sampling in a Composite Selector, the rate of the Packet Stream output from the sampler and input to the filter may be sufficiently slow that the filter could select based on routing state. > The thinning could have happened through another filter also (e.g., based on a packet field), couldn't it? So perhaps we should not limit it to sampling. How about "However, if in a Composite Selector, filtering based on routing state is preceded by at least one other Selector, the rate of the input to that filter may be...". >In order to limit delay in the formation of Export Packets, the > Exporting Process must provide the ability to close out and > enqueue for transmission any Export Packet during formation as > soon as it includes one Packet Report. > It may make sense to allow for an Export Packet to be generated even if there are ZERO Packet Reports pending, for this EP to act as a heartbeat packet to signal to the collector that connectivity is ok. This would allow the collector to distinguish between an absence of traffic at the PSAMP device and loss of connectivity. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 29 12:08:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09331 for ; Mon, 29 Nov 2004 12:08:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CYovB-0008hZ-AX for psamp-data@psg.com; Mon, 29 Nov 2004 17:02:41 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CYov4-0008gm-Ge for psamp@ops.ietf.org; Mon, 29 Nov 2004 17:02:34 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-green.research.att.com (Postfix) with ESMTP id D4F0DA7B07; Mon, 29 Nov 2004 12:02:33 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: some comments on draft-ietf-psamp-framework-09.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 29 Nov 2004 12:02:33 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1915418@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: some comments on draft-ietf-psamp-framework-09.txt Thread-Index: AcTQcb2eGmaQ5hbLQUG1pN4McX32ZQFwcEWw From: To: Cc: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Do we have to say that a hash approximates uniform random sampling?=A0 = It does, most of the time, but it's tough to beat uniform random > = sampling and with insider information one could defeat a hash.=A0=20 I think approximation is a reasonable term, since an approximation can = be close or not. The security and robustness issues are discussed more = fully in the sampling techniques draft. But to give a flavor of what is = needed to avoid the problem you mention, I propose adding a sentence to = the framework draft" "Privacy of hash selection range and hash function parameters (although = not the hash function itself) obstruct subversion of the selector by = packets that are crafted either to avoid selection or to be selected" -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 29 14:28:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21982 for ; Mon, 29 Nov 2004 14:28:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CYr7e-000LXK-Uz for psamp-data@psg.com; Mon, 29 Nov 2004 19:23:42 +0000 Received: from [192.20.225.112] (helo=mail-yellow.research.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CYr7A-000LHn-5U for psamp@ops.ietf.org; Mon, 29 Nov 2004 19:23:12 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 0FAD019736B for ; Mon, 29 Nov 2004 14:12:05 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: psamp filtering X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 29 Nov 2004 14:23:11 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E191541A@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: psamp filtering Thread-Index: AcTWSN13zzCCp6l6SJywTGAEaeAtNQ== From: To: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In the sampling techniques draft:=20 6.1 Field Match Filtering=20 =20 We here define a basic Filtering schemes based on the IPIFIX=20 flow definition. With this method a packet is selected if a=20 specific field in the packet equals a predefined value. Possible filter fields are all IPFIX flow attributes specified in [IPFIX- INFO]. Further fields can be defined by vendor specific=20 extensions.=20 A packet is selected if Field=3DValue. Masks and ranges are only=20 supported to the extend to which [IPFIX-INFO] allows them e.g.=20 by providing explicit fields like the netmasks for source and=20 destination addresses. AND operations are possible by=20 concatenating filters. OR operations are not supported with this basic model. More sophisticated filters (e.g. supporting=20 bitmasks, ranges or OR operations etc.) can be realized as=20 vendor specific schemes. As it stands now, this text might give the impression that AND operations are accomplished by composing a number of PSAMP selectors, each being primitive and corresponding to filtering on a single field. I don't think this is what is intended. (In any case, PSAMP can currently only combine one filter with one sampling operation at present).=20 Also, "concatenation" implies that an order amongst the basic filters is to be specified. As Matt Grossglauser has pointed out, this might be useful if one wants to put a "quick" filter (e.g. on port number) first, to reduce the packet rate down for a "slow" filter (e.g. on routing state) following. So do we want to require ordering of filters within the combination? Or would some implementors want to implement some or all combinations as a single composite mask/match across fields, without ordering....? If order is not specified, we might want to replace "AND operations are possible by concatenating filters"=20 with=20 "AND operations are possible by specifying multiple basic field match Filters, the packet being selected if would be selected by all the specified filters. The resulting combination is viewed as a primitive PSAMP Selector." Finally, it was suggested to me at IETF 61 that the current text in the framework draft (it speaks of match/mask operations) should be replaced with the text from the sampling draft. I can do this once the latter is finalized. Comments? Nick -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Nov 29 14:30:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22139 for ; Mon, 29 Nov 2004 14:30:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CYr9W-000M5D-0Q for psamp-data@psg.com; Mon, 29 Nov 2004 19:25:38 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CYr98-000Ltc-TF for psamp@ops.ietf.org; Mon, 29 Nov 2004 19:25:15 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-green.research.att.com (Postfix) with ESMTP id 945CEA7B07; Mon, 29 Nov 2004 14:25:14 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: some comments on draft-ietf-psamp-framework-09.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 29 Nov 2004 14:25:14 -0500 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E18BF226@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: some comments on draft-ietf-psamp-framework-09.txt Thread-Index: AcTQvjYIn5VirdxNRpWtlsNMWPXAlQFdxf9Q From: To: , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Matt, > -----Original Message----- > From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On Behalf > Of Matthias Grossglauser > Sent: Monday, November 22, 2004 1:07 PM > To: psamp@ops.ietf.org > Subject: Re: some comments on draft-ietf-psamp-framework-09.txt >=20 >=20 > Folks, >=20 > I think the document is in very good shape. A few comments below. I will > send a list of minor typos directly to the editor. >=20 > Matt >=20 >=20 > >- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency". > >Also, the term "non-contingency" seems a bit strange. > > > > > A good term might be "causality". Or "adapted": borrowing from the terminology of stochastic processes we could say that selection is adapted to the packet stream, in the sense that selection of a given packet depends only on previous packets, if at all.=20 I wonder now if this is too strong: it's conceivable one might, in some future selector not yet standardized, want to buffer a few packets before deciding which one of them to select, as long as resources are available to buffer. The strict adaptiveness might have been a good thing were psamp to have some mandatory selectors, but now it doesn't. Comments? >=20 > >>> >=20 > Regarding the discussion of "attacks" against hash-based PSAMP by > crafting packets, let me refer back to a comment a made a while ago: >=20 > https://www.psg.com/lists/psamp/psamp.2002/msg00170.html >=20 > Basically, if the attacker does not know which hash function in the > family is active, then this provides *stronger* protection than if the > attacker knows the hash function, but not the range it has to fall into > to get sampled. This might be worth pointing out. It is alluded to the > in draft by saying that there can be a family of hash functions, but it > could perhaps be strengthened by pointing out that this provides > additional robustness against crafted packets. >=20 See the proposed additional sentence from my response to Derek Chiou, i.e.,=20 "Privacy of hash selection range and hash function parameters (although not the hash function itself) obstruct subversion of the selector by packets that are crafted either to avoid selection or to be selected" > >*************** > >> *** 1112,1114 **** > >> expected to be relatively static; they could be communicated > >> ! periodically, and upon change. > >> > >> --- 1112,1118 ---- > >> expected to be relatively static; they could be communicated > >> ! periodically, and upon change. > >> ! > >> ! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, MEASUREMENT > >> ! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN EVERY > >> ! PACKET REPORT? > > > > > > > > > >Since an export packet may contain multiple packet reports, the export > >process id can be included once per export packet. > > > > > > > Did we say anywhere that exporting process IDs are included? Note that > this is important to enable the collector to estimate the Export Packet > drop rate under unreliable transport to drive a congestion-control > algorithm; the finer per-report IDs are not necessarily sufficient for > this, I think. Of course, in most situations the underlying unreliable > transport protocol would have sequence numbers already, but it might be > desirable to have a transport-independent EP numbering for layer > independence. >=20 I agree it would be good to make this explicit, and not assume export sequence numbers are provided by the transport layer. > >How about: > > > >Router architectural considerations may preclude some information > concerning the packet treatment being available at line rate for selection > of packets. For example, the Selection Process may not be implemented in > the fast path that is able to access routing state at line rate. However, > when filtering follows sampling in a Composite Selector, the rate of the > Packet Stream output from the sampler and input to the filter may be > sufficiently slow that the filter could select based on routing state. > > > The thinning could have happened through another filter also (e.g., > based on a packet field), couldn't it? So perhaps we should not limit it > to sampling. How about "However, if in a Composite Selector, filtering > based on routing state is preceded by at least one other Selector, the > rate of the input to that filter may be...". See separate message on filtering >=20 > >In order to limit delay in the formation of Export Packets, the > > Exporting Process must provide the ability to close out and > > enqueue for transmission any Export Packet during formation as > > soon as it includes one Packet Report. > > > It may make sense to allow for an Export Packet to be generated even if > there are ZERO Packet Reports pending, for this EP to act as a heartbeat > packet to signal to the collector that connectivity is ok. This would > allow the collector to distinguish between an absence of traffic at the > PSAMP device and loss of connectivity. Some transport protocols do this already, e.g. SCTP manages interface failover using heartbeats. But we can't assume transport provides it (e.g. if UDP is used), in which case PSAMP should. I can add a sentence on this. Nick =20 >=20 >=20 >=20 >=20 > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Nov 30 00:43:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24503 for ; Tue, 30 Nov 2004 00:43:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZ0ik-000Kjz-57 for psamp-data@psg.com; Tue, 30 Nov 2004 05:38:38 +0000 Received: from [208.246.215.5] (helo=mailhost.avici.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZ0ij-000Kjn-EJ for psamp@ops.ietf.org; Tue, 30 Nov 2004 05:38:37 +0000 Received: from avici.com ([10.2.103.177]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAU5ca4H014528; Tue, 30 Nov 2004 00:38:36 -0500 Message-ID: <41AC0746.8040208@avici.com> Date: Tue, 30 Nov 2004 00:38:14 -0500 From: Derek Chiou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: duffield@research.att.com CC: psamp@ops.ietf.org Subject: Re: some comments on draft-ietf-psamp-framework-09.txt References: <387B5A9BF31B5D43A2B18DD9F326B8E1915418@NJFPSRVEXG2KCL.research.att.com> In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E1915418@NJFPSRVEXG2KCL.research.att.com> Content-Type: multipart/alternative; boundary="------------000009060302080503010703" X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000009060302080503010703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Nick, Your additional sentence looks good. Thanks. Derek duffield@research.att.com wrote: >>Do we have to say that a hash approximates uniform random sampling? It does, most of the time, but it's tough to beat uniform random > sampling and with insider information one could defeat a hash. >> >> > >I think approximation is a reasonable term, since an approximation can be close or not. The security and robustness issues are discussed more fully in the sampling techniques draft. But to give a flavor of what is needed to avoid the problem you mention, I propose adding a sentence to the framework draft" > >"Privacy of hash selection range and hash function parameters (although not the hash function itself) obstruct subversion of the selector by packets that are crafted either to avoid selection or to be selected" > > > --------------000009060302080503010703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Nick,

Your additional sentence looks good.

Thanks.

Derek

duffield@research.att.com wrote:
Do we have to say that a hash approximates uniform random sampling?  It does, most of the time, but it's tough to beat uniform random > sampling and with insider information one could defeat a hash.  
    

I think approximation is a reasonable term, since an approximation can be close or not. The security and robustness issues are discussed more fully in the sampling techniques draft. But to give a flavor of what is needed to avoid the problem you mention, I propose adding a sentence to the framework draft"

"Privacy of hash selection range and hash function parameters (although not the hash function itself) obstruct subversion of the selector by packets that are crafted either to avoid selection or to be selected"
--------------000009060302080503010703-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Nov 30 00:54:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25684 for ; Tue, 30 Nov 2004 00:54:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZ0uL-000PQ5-UY for psamp-data@psg.com; Tue, 30 Nov 2004 05:50:37 +0000 Received: from [208.246.215.5] (helo=mailhost.avici.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZ0uJ-000PJU-V0 for psamp@ops.ietf.org; Tue, 30 Nov 2004 05:50:36 +0000 Received: from avici.com ([10.2.103.177]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAU5oW4H015626; Tue, 30 Nov 2004 00:50:32 -0500 Message-ID: <41AC0A12.50307@avici.com> Date: Tue, 30 Nov 2004 00:50:10 -0500 From: Derek Chiou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: duffield@research.att.com CC: matthias.grossglauser@epfl.ch, psamp@ops.ietf.org Subject: Re: some comments on draft-ietf-psamp-framework-09.txt References: <387B5A9BF31B5D43A2B18DD9F326B8E18BF226@NJFPSRVEXG2KCL.research.att.com> In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E18BF226@NJFPSRVEXG2KCL.research.att.com> Content-Type: multipart/alternative; boundary="------------060201050607000309000506" X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------060201050607000309000506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Nick, One point in-line. duffield@research.att.com wrote: >Matt, > > > >>-----Original Message----- >>From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On >> >> >Behalf > > >>Of Matthias Grossglauser >>Sent: Monday, November 22, 2004 1:07 PM >>To: psamp@ops.ietf.org >>Subject: Re: some comments on draft-ietf-psamp-framework-09.txt >> >> >>Folks, >> >>I think the document is in very good shape. A few comments below. I >> >> >will > > >>send a list of minor typos directly to the editor. >> >>Matt >> >> >> >> >>>- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency". >>>Also, the term "non-contingency" seems a bit strange. >>> >>> >>> >>> >>A good term might be "causality". >> >> > >Or "adapted": borrowing from the terminology of stochastic processes we >could say that selection is adapted to the packet stream, in the sense >that selection of a given packet depends only on previous packets, if at >all. > >I wonder now if this is too strong: it's conceivable one might, in some >future selector not yet standardized, want to buffer a few packets >before deciding which one of them to select, as long as resources are >available to buffer. The strict adaptiveness might have been a good >thing were psamp to have some mandatory selectors, but now it doesn't. > >Comments? > > That's a good point. Selecting one of a small group of buffered packets seems like an interesting possibility. We should not disallow this within PSAMP, thus perhaps we should remove the Non-Contingency requirement. > > > > >> >>> >> >>Regarding the discussion of "attacks" against hash-based PSAMP by >>crafting packets, let me refer back to a comment a made a while ago: >> >>https://www.psg.com/lists/psamp/psamp.2002/msg00170.html >> >>Basically, if the attacker does not know which hash function in the >>family is active, then this provides *stronger* protection than if the >>attacker knows the hash function, but not the range it has to fall >> >> >into > > >>to get sampled. This might be worth pointing out. It is alluded to the >>in draft by saying that there can be a family of hash functions, but >> >> >it > > >>could perhaps be strengthened by pointing out that this provides >>additional robustness against crafted packets. >> >> >> > >See the proposed additional sentence from my response to Derek Chiou, >i.e., > >"Privacy of hash selection range and hash function parameters (although >not the hash function itself) obstruct subversion of the selector by >packets that are crafted either to avoid selection or to be selected" > > > > > >>>*************** >>> >>> >>>>*** 1112,1114 **** >>>> expected to be relatively static; they could be >>>> >>>> >communicated > > >>>>! periodically, and upon change. >>>> >>>>--- 1112,1118 ---- >>>> expected to be relatively static; they could be >>>> >>>> >communicated > > >>>>! periodically, and upon change. >>>>! >>>>! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT, >>>> >>>> >MEASUREMENT > > >>>>! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN >>>> >>>> >EVERY > > >>>>! PACKET REPORT? >>>> >>>> >>> >>> >>>Since an export packet may contain multiple packet reports, the >>> >>> >export > > >>>process id can be included once per export packet. >>> >>> >>> >>> >>> >>Did we say anywhere that exporting process IDs are included? Note that >>this is important to enable the collector to estimate the Export >> >> >Packet > > >>drop rate under unreliable transport to drive a congestion-control >>algorithm; the finer per-report IDs are not necessarily sufficient for >>this, I think. Of course, in most situations the underlying unreliable >>transport protocol would have sequence numbers already, but it might >> >> >be > > >>desirable to have a transport-independent EP numbering for layer >>independence. >> >> >> > >I agree it would be good to make this explicit, and not assume export >sequence numbers are provided by the transport layer. > > > >>>How about: >>> >>>Router architectural considerations may preclude some information >>> >>> >>concerning the packet treatment being available at line rate for >> >> >selection > > >>of packets. For example, the Selection Process may not be implemented >> >> >in > > >>the fast path that is able to access routing state at line rate. >> >> >However, > > >>when filtering follows sampling in a Composite Selector, the rate of >> >> >the > > >>Packet Stream output from the sampler and input to the filter may be >>sufficiently slow that the filter could select based on routing state. >> >> >>The thinning could have happened through another filter also (e.g., >>based on a packet field), couldn't it? So perhaps we should not limit >> >> >it > > >>to sampling. How about "However, if in a Composite Selector, filtering >>based on routing state is preceded by at least one other Selector, the >>rate of the input to that filter may be...". >> >> > > >See separate message on filtering > > > >>>In order to limit delay in the formation of Export Packets, the >>> Exporting Process must provide the ability to close out and >>> enqueue for transmission any Export Packet during formation as >>> soon as it includes one Packet Report. >>> >>> >>> >>It may make sense to allow for an Export Packet to be generated even >> >> >if > > >>there are ZERO Packet Reports pending, for this EP to act as a >> >> >heartbeat > > >>packet to signal to the collector that connectivity is ok. This would >>allow the collector to distinguish between an absence of traffic at >> >> >the > > >>PSAMP device and loss of connectivity. >> >> > >Some transport protocols do this already, e.g. SCTP manages interface >failover using heartbeats. But we can't assume transport provides it >(e.g. if UDP is used), in which case PSAMP should. I can add a sentence >on this. > >Nick > > > >> >> >>-- >>to unsubscribe send a message to psamp-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> > > > >-- >to unsubscribe send a message to psamp-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > --------------060201050607000309000506 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Nick,

One point in-line.


duffield@research.att.com wrote:
Matt,

  
-----Original Message-----
From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
    
Behalf
  
Of Matthias Grossglauser
Sent: Monday, November 22, 2004 1:07 PM
To: psamp@ops.ietf.org
Subject: Re: some comments on draft-ietf-psamp-framework-09.txt


Folks,

I think the document is in very good shape. A few comments below. I
    
will
  
send a list of minor typos directly to the editor.

Matt


    
- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency".
Also, the term "non-contingency" seems a bit strange.


      
A good term might be "causality".
    

Or "adapted": borrowing from the terminology of stochastic processes we
could say that selection is adapted to the packet stream, in the sense
that selection of a given packet depends only on previous packets, if at
all. 

I wonder now if this is too strong: it's conceivable one might, in some
future selector not yet standardized, want to buffer a few packets
before deciding which one of them to select, as long as resources are
available to buffer. The strict adaptiveness might have been a good
thing were psamp to have some mandatory selectors, but now it doesn't.

Comments?
That's a good point.  Selecting one of a small group of buffered packets seems like an interesting possibility.  We should not disallow this within PSAMP, thus perhaps we should remove the Non-Contingency requirement.


  
 >>>

Regarding the discussion of "attacks" against hash-based PSAMP by
crafting packets, let me refer back to a comment a made a while ago:

https://www.psg.com/lists/psamp/psamp.2002/msg00170.html

Basically, if the attacker does not know which hash function in the
family is active, then this provides *stronger* protection than if the
attacker knows the hash function, but not the range it has to fall
    
into
  
to get sampled. This might be worth pointing out. It is alluded to the
in draft by saying that there can be a family of hash functions, but
    
it
  
could perhaps be strengthened by pointing out that this provides
additional robustness against crafted packets.

    

See the proposed additional sentence from my response to Derek Chiou,
i.e., 

"Privacy of hash selection range and hash function parameters (although
not the hash function itself) obstruct subversion of the selector by
packets that are crafted either to avoid selection or to be selected"



  
***************
      
*** 1112,1114 ****
        expected to be relatively static; they could be
        
communicated
  
!       periodically, and upon change.

--- 1112,1118 ----
        expected to be relatively static; they could be
        
communicated
  
!       periodically, and upon change.
!
!       SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT,
        
MEASUREMENT
  
!       PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN
        
EVERY
  
!       PACKET REPORT?
        


Since an export packet may contain multiple packet reports, the
      
export
  
process id can be included once per export packet.



      
Did we say anywhere that exporting process IDs are included? Note that
this is important to enable the collector to estimate the Export
    
Packet
  
drop rate under unreliable transport to drive a congestion-control
algorithm; the finer per-report IDs are not necessarily sufficient for
this, I think. Of course, in most situations the underlying unreliable
transport protocol would have sequence numbers already, but it might
    
be
  
desirable to have a transport-independent EP numbering for layer
independence.

    

I agree it would be good to make this explicit, and not assume export
sequence numbers are provided by the transport layer.

  
How about:

Router architectural considerations may preclude some information
      
concerning the packet treatment being available at line rate for
    
selection
  
of packets. For example, the Selection Process may not be implemented
    
in
  
the fast path that is able to access routing state at line rate.
    
However,
  
when filtering follows sampling in a Composite Selector, the rate of
    
the
  
Packet Stream output from the sampler and input to the filter may be
sufficiently slow that the filter could select based on routing state.
    
The thinning could have happened through another filter also (e.g.,
based on a packet field), couldn't it? So perhaps we should not limit
    
it
  
to sampling. How about "However, if in a Composite Selector, filtering
based on routing state is preceded by at least one other Selector, the
rate of the input to that filter may be...".
    


See separate message on filtering

  
In order to limit delay in the formation of Export Packets, the
     Exporting Process must provide the ability to close out and
     enqueue for transmission any Export Packet during formation as
     soon as it includes one Packet Report.

      
It may make sense to allow for an Export Packet to be generated even
    
if
  
there are ZERO Packet Reports pending, for this EP to act as a
    
heartbeat
  
packet to signal to the collector that connectivity is ok. This would
allow the collector to distinguish between an absence of traffic at
    
the
  
PSAMP device and loss of connectivity.
    

Some transport protocols do this already, e.g. SCTP manages interface
failover using heartbeats. But we can't assume transport provides it
(e.g. if UDP is used), in which case PSAMP should. I can add a sentence
on this.

Nick
 
  


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>
    



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>
--------------060201050607000309000506-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Nov 30 05:40:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03148 for ; Tue, 30 Nov 2004 05:40:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZ5LB-000P48-BN for psamp-data@psg.com; Tue, 30 Nov 2004 10:34:37 +0000 Received: from [193.63.211.19] (helo=mail.dante.org.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZ5L7-000P3R-3p for psamp@ops.ietf.org; Tue, 30 Nov 2004 10:34:33 +0000 Received: from [127.0.0.1] (helo=localhost) by mail.dante.org.uk with esmtp (Exim 4.43) id 1CZ5L1-00068O-OM; Tue, 30 Nov 2004 10:34:27 +0000 Received: from mail.dante.org.uk ([127.0.0.1]) by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23380-09; Tue, 30 Nov 2004 10:34:13 +0000 (GMT) Received: from [193.63.211.62] (helo=[193.63.211.62]) by mail.dante.org.uk with esmtp (Exim 4.43) id 1CZ5Km-00068F-Uq; Tue, 30 Nov 2004 10:34:13 +0000 Message-ID: <41AC4CA4.7050704@dante.org.uk> Date: Tue, 30 Nov 2004 10:34:12 +0000 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: duffield@research.att.com CC: psamp@ops.ietf.org Subject: Re: psamp filtering References: <387B5A9BF31B5D43A2B18DD9F326B8E191541A@NJFPSRVEXG2KCL.research.att.com> In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E191541A@NJFPSRVEXG2KCL.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at dante.org.uk X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit duffield@research.att.com wrote: >In the sampling techniques draft: > > 6.1 Field Match Filtering > > We here define a basic Filtering schemes based on the IPIFIX > flow definition. With this method a packet is selected if a > specific field in the packet equals a predefined value. Possible > > filter fields are all IPFIX flow attributes specified in [IPFIX- > INFO]. Further fields can be defined by vendor specific > extensions. > A packet is selected if Field=Value. Masks and ranges are only > supported to the extend to which [IPFIX-INFO] allows them e.g. > by providing explicit fields like the netmasks for source and > destination addresses. AND operations are possible by > concatenating filters. OR operations are not supported with this > > basic model. More sophisticated filters (e.g. supporting > bitmasks, ranges or OR operations etc.) can be realized as > vendor specific schemes. > >As it stands now, this text might give the impression that AND >operations are accomplished by composing a number of PSAMP selectors, >each being primitive and corresponding to filtering on a single field. I >don't think this is what is intended. (In any case, PSAMP can currently >only combine one filter with one sampling operation at present). > My understanding is that through the STREAM ID you can have multiple concatenation, and even a filter + filter concatenation (and in this case the order is intrinsically specified). However, I admit that from the TOC only it looks like that the only possible composition is Cascaded Filtering->Sampling or Sampling->Filtering (se. 8.1). But if you read the text before, it states that it is just an example. > > >Also, "concatenation" implies that an order amongst the basic filters is >to be specified. > Correct, but the result will then be independent of the order. > As Matt Grossglauser has pointed out, this might be >useful if one wants to put a "quick" filter (e.g. on port number) first, >to reduce the packet rate down for a "slow" filter (e.g. on routing >state) following. So do we want to require ordering of filters within >the combination? > See above: I think that if you specify a cascaded filter via the STREAM ID, ordering is implicitly defined, but the result will then be independent of the order. > Or would some implementors want to implement some or >all combinations as a single composite mask/match across fields, without >ordering....? > >If order is not specified, we might want to replace > >"AND operations are possible by concatenating filters" > >with > >"AND operations are possible by specifying multiple basic field match >Filters, the packet being selected if would be selected by all the >specified filters. The resulting combination is viewed as a primitive >PSAMP Selector." > > I think that if we go for your proposal, we have to ensure that IPFIX-INFO supports it. I'd rather stick to the old text for SPECIFYING a filter. Then I'd add part of your text to leave the door open to implementation of composite filters in "one step". My proposal: AND operations are possible by concatenating filters through the use of the STREAM ID (see sec. 7.1 and 8). In this case, the ordering in which the filtering happens is implicitly defined (outer filters come after inner filters). However, as long as the concatenation is on filters only, the result of the cascaded filter is independent from the order, but the order MAY be important for implementation purposes, as the first filter will have to work at a higher rate. In any case, an implementation is not constrained to respect the filter ordering, as long as the result is the same, and it MAY even implement the composite filtering in filtering in one single step. Maurizio >Finally, it was suggested to me at IETF 61 that the current text in the >framework draft (it speaks of match/mask operations) should be replaced >with the text from the sampling draft. I can do this once the latter is >finalized. > >Comments? > >Nick > > > >-- >to unsubscribe send a message to psamp-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: