From majordomo@mil.doit.wisc.edu Fri Jan 3 11:18:25 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12150 for ; Fri, 3 Jan 2003 11:18:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18UUE2-0002YL-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Jan 2003 09:59:10 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18UUE0-0002XW-00 for ipfix-req@net.doit.wisc.edu; Fri, 03 Jan 2003 09:59:08 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h03FwXb89255 for ; Fri, 3 Jan 2003 16:58:34 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 47AAD818ED for ; Fri, 3 Jan 2003 17:58:50 +0100 (CET) Date: Fri, 03 Jan 2003 17:11:27 +0100 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] proposed changes for requirements document Message-ID: <22047953.1041613887@[10.1.1.128]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Here is a list of suggestions for changes to the requirements document. They are based on our discussion in Atlanta and on a comment by Benoit. I would like to achieve rough consensus on this list of changes in order to enter working group last call for the requirements document. Juergen 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: "RTP header fields" by "RTP header fields [RFC1889]" 2. Append to Section "2.1. IP Traffic Flow": "Also, please note that although packet properties may depend on application headers, there is no requirement defined in this document related to applicaton headers." 3. Move in section 6.1 "Information Model" item "7. if protocol type is ICMP: ICMP type and code" from the list of MUST attributes to the list of SHOULD attributes. Now it is item 17. 4. Replace the first paragraph in section "6.3.2. Reliability": "Absence of reliability of the data transfer, for example caused by loss or reordering of packets containing flow information, MUST be indicated." by "Different levels of reliability of the data transfer MAY be supported. The collecting process MUST have sufficient information for making a conservative assumption about the applied reliability level. This means that the applied level of reliability MUST be as high as or higher than indicated to the collecting process." 5. Add new paragraph after second paragraph in section "6.3.2": "The chosen method of data transfer MUST be extensible concerning reliability. It MUST be possible to increase reliability by extensions." 6. Add to References: "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996." -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jan 7 16:34:33 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29482 for ; Tue, 7 Jan 2003 16:34:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18W11y-0002gV-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Jan 2003 15:13:02 -0600 Received: from f74.pav1.hotmail.com ([64.4.31.74] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18W11w-0002gL-00 for ipfix@net.doit.wisc.edu; Tue, 07 Jan 2003 15:13:00 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 Jan 2003 13:12:09 -0800 Received: from 57.250.229.136 by pv1fd.pav1.hotmail.msn.com with HTTP; Tue, 07 Jan 2003 21:12:09 GMT X-Originating-IP: [57.250.229.136] From: "M. ELK" To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX Requirement & Netflow evaluation Date: Tue, 07 Jan 2003 21:12:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jan 2003 21:12:09.0787 (UTC) FILETIME=[70BEF0B0:01C2B691] Precedence: bulk Sender: majordomo listserver Hi Just few comments from average knowledge user Note : reference to draft-claise-ipfix-eval-netflow-03.txt is between ( ) , reference to draft-ietf-ipfix-reqs-07-txt is between [ ] XXX- IPFIX Requirement 1- Obesrvation point : need to specify the direction ie: is it a for input or output or both . certain manufaturer box is not able to do flow capturig on the output and this is a LIMITATION . 2- Metering Process requirement A- not clear why such requirement is part of a specific protocol (crane ,netflow ..etc) , my understanding it is a requirement on the box implementation whatever the protocol selected . As such when evaluating protocol all metering process requirement should be marked as "N/A" . B- Reliability [5.1] For the ATM/FR switch world collecting statistics is a MANDATORY/MUST requirement ,never seen a switch advertising XX throughput in pps/cps with statistics collection turned off . Unfortunatly this is not true in the router world . If the router is not able to collect statistics at line rate so this is a LIMITATION and if sampling is proposed so by all mean it should not be advertised/characterised as a FEATURE (sampling is a feature if and only if it is provided in addition to line rate capabilities) i suggest to remove the word "either" so " The metering process MUST be reliable ,missing reliability must be known and indicated by the manufacturer implementing the IPFIX protocol " The IPFIX WG should emphasis those points so : 1- could be taken seriously by the router manufacturer . 2- Educate the users/customer to consider such capabilities when selecting a box . while browsing the mailing list i could see no voice from the main network providers ,suggest to try to reach the participation of this group . This will help to set/clarify what is the "MUST" ,"Should", "Optional" requirement . The discusion is mainly dominated by manufacturer and application_provider , Some application_provider tried to raise the issue of what the customers are expecting still some other simply need a "simple" protocol ( a certain post indicated " i like XX protocl because it is simple to implement and take less memory" irespective if this "simple" starpped version is good enough for the customers . This "simple" proposal is good for a customer with couple of routers but not at all adecate for a provider have 100+ on the backbone and 1000's as a CE ) . C- sampling [5.2] Need to indicate that sampling feature is provided above and over line rate capabilities and not as a replacement . At least to indicate that using sampling could reduce the scope of "application requiring IP flow info export " . ( is it exist in real word any provider charging customer based on sampling data ? . as an anology imagine a restaurant charging the customer based on sampling ) D- Overload behavior [5.3] Need to indicate that whatever reaction is selected is based on user selection (configuration) . Also to indicate that the manufacturer should publish when such condition could arise (CPU load , memory size, throughput in pps ) . 3- Information model [6.1] Could we add "Average Packet size" as item nbr "27" which MAY be collected. reg Mpls , their is some view within the WG that Mpls need to be eliminated . By doing this the WG is eliminated a fast majority of customer who need to collect flow information from P router . Collecting the top label and FEC is basic requirement ,we need to get more info . In order to keep the IPFIX requirement doc stable may be issue a seperate draft reg optional Mpls requirement . I could thinck of the following : A- Owner of the top label ( LDP, RSVP-TE,Static,......other) B- In case of LDP top label : The FEC . C- In case of RSVP-TE top label : Tunnel end points (Head and tail) and optionally session name D-extract N'th nbr of label under the top label ( N is user configurable) E- depth of stack . F- action taken on recieved top label (pop ,swap ..etc) G- output top label 4- Data Transfer A- for Congestion Awarness [6.3.1] and reliability [6.3.2] may be it worth to highlight explicitly : IPFIX protocl could have both properties as : i- Built-in as part of IPFIX . wher the IPFIX protocol will be carried directly over IP . ii- inherited from any L4 protocol where IPFIX will be running on top . IPFIX WG should make a statement on which approach is preferable , guess from other experience (LDP,BGP ...etc) the 2nd approach is encouraged . B- Do we have to separate "Congestion Awarness" and "Reliability" . did it exist any protocol which is "congestion aware" but not reliable !!! or vice versa . C- Not clear the drivers to have "congestion aware" as a "MUST" but reliability as "option" . to me either both are "MUST" or both are "optional" . D- Reg reliability . How the IPFIX WG consider the importance of collecting flow stat . is it an optional thing/"Nice To have" ? (just as an anolaogy consider the BGP or LDP group considering unreliable exchange of update ,after all it is "simpler" to implement and take less memory and cpu cycle ) . It is indicated as "loss or reordering of packets MUST be indicated" : fair enough but what is the usefullness of such indication (packet loss) beside knowing that the IPFIX protocol is not working correctly and we have to look for other alternative (something is known from the day of deploying IPFIX ) . i guess reliability requirement should be considered as "MUST" , For Netflow cisco already stated that SCTP will be used (in order to satisy "congestion awarness" requirement [6.3.1] (3.5.3.1) ) . YYY- For netflow evaluation 1- IP Traffic flow (3.1.1) [2.1] not clear how it is Total Compliance . in netflow the flow definition is fixed . Their is no possibility to have function "F" to define a flow . agregation schema is not user configurable (may be it is possible in V9 but no documentation ) . In draft-ietf-ipfix-architecture-02.txt it list 3 examples in section 3 , it is not clear/documented how netflow could implement example 2 and 3 . 2- Metering procces (3.1.3) [2.3] in [2.3] their is a requirement to apply sampling and classification more than once . netflow metering process is not able to do this ( it could be seen that the agregation feature could achieve the same outcome but this is only true if the user is able to define his own agregation schema and option to include function "F" in the agregation definition ) 3- Application requiring IP flow information [3] (3.2) For "usage based accounting" ,is it assumed that netflow running on top of SCTP or it will remain over UDP . If the later : so Netflow can not staisfy the need/requirement for "usage based accounting " application . 4-Distinguishing Flow A-by interfaces (3.3.1) [4.1] the requirement call to distinguish packet by "output interface " . "egress Netflow" is only applicable if the packet arrive from MPLS enabled interface ,if the packet arrive from an IP interface it will not be counted in the flow so this is a LIMITATION . also ,say we are interseted to meter flow going out of interface ifindex=3 : not clear how we could config netflow to do this . B- by IP header fields [4.2] (3.3.2) in [4.2] separation is MUST by prefix match . (3.3.2) did not addressed this point . Netflow could agregate by prefix match (from the routing table ) and some granuality using "minimum prefix" cmmands but still their is no way a user could specify a flow based on say 10.1/16 . C- by Mpls (3.3.4) [4.4] Unable to find a single cisco documentation describing this fearure so how it is Total compliance . if it is supported by cisco so they need to release the documentation even a draft version . 5- Information Model [6.1] (3.5.1) A- For "if protocol type is ICMP: ICMP type and code" , it is not addressed in (3.5.1) B- For "packet counter" ,it is defined in [6.1] as " if a packet is fragmented ,each fragment is counted as an individual packet" in (3.5.1) it is indicated as Total compliance , unable to find a cisco doc which describe/state that fragmented packet is counted in the flow . C- for MPLS , unable to locate field type defined for MPLS label or FEC in "Cisco IOS NetFlow V9 Flow record Format White paper" neither in draft-bclaise-netflow-9-00.txt nor in draft-gsadasiv-ipfix-proposal-00.txt . again ,cisco need to open it's hand/disclose ongoing extention to netflow . 6- Configuration for metering process [7.1] (3.6.1) [7.1] call for "specification of flows to be metered" . (3.6.1) claim Total compliance despite unable to locate cisco doc which specify how a user ( in term of ios cmds ) could specify a flow . Brgds _________________________________________________________________ MSN 8: advanced junk mail protection and 2 months FREE*. http://join.msn.com/?page=features/junkmail -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jan 7 18:40:44 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03666 for ; Tue, 7 Jan 2003 18:40:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18W35c-0005Kd-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Jan 2003 17:24:56 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18W35a-0005KW-00 for ipfix@net.doit.wisc.edu; Tue, 07 Jan 2003 17:24:54 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h07NOpR08012; Wed, 8 Jan 2003 00:24:51 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.27] (dial03.office [10.1.1.27]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1589F8207B; Wed, 8 Jan 2003 01:24:26 +0100 (CET) Date: Wed, 08 Jan 2003 00:37:51 +0100 From: Juergen Quittek To: "M. ELK" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX Requirement & Netflow evaluation Message-ID: <8991559.1041986270@[10.1.1.27]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Thanks for the detailed comments. Here is just a quick reply to your second comment. Replying to the others needs more time. Juergen -- M. ELK wrote on 07 January 2003 21:12 +0000: > > 2- Metering Process requirement > > A- not clear why such requirement is part of a specific protocol (crane ,netflow ..etc) , my understanding it is a requirement on the box implementation > whatever the protocol selected . > As such when evaluating protocol all metering process requirement should be marked as "N/A" . > There is a good reason, why some of the metering process requirements are part of the evaluation: They imply communication with the collecting process. For example: missing reliability must be indicated, or (as you discuss later in your message) the applied sampling method mut be clearly indicated. These indicators must be carried by the export protocol. Therefore, the evaluation team considered these requirements to be relevant for the protocol evaluation. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 8 12:58:42 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29502 for ; Wed, 8 Jan 2003 12:58:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18WKCR-0006II-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Jan 2003 11:41:07 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18WKCP-0006IA-00 for ipfix-req@net.doit.wisc.edu; Wed, 08 Jan 2003 11:41:06 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h08Hf5R21996 for ; Wed, 8 Jan 2003 18:41:05 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4D2AB75565 for ; Wed, 8 Jan 2003 19:40:33 +0100 (CET) Date: Wed, 08 Jan 2003 18:54:06 +0100 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] proposed changes for requirements document Message-ID: <32289329.1042052046@[10.1.1.128]> In-Reply-To: <22047953.1041613887@[10.1.1.128]> References: <22047953.1041613887@[10.1.1.128]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, If there are no comments on this suggestion until Wednesday next week, I will prepare and submit a new version of the requirements document at then end of next week. Hopefully, this will be the version that enters WG last call. Juergen -- Juergen Quittek wrote on 03 January 2003 17:11 +0100: > Dear all, > > Here is a list of suggestions for changes to the requirements document. > They are based on our discussion in Atlanta and on a comment by Benoit. > > I would like to achieve rough consensus on this list of changes > in order to enter working group last call for the requirements document. > > Juergen > > > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: > > "RTP header fields" by "RTP header fields [RFC1889]" > > 2. Append to Section "2.1. IP Traffic Flow": > > "Also, please note that although packet properties may depend on > application headers, there is no requirement defined in this document > related to applicaton headers." > > 3. Move in section 6.1 "Information Model" item "7. if protocol > type is ICMP: ICMP type and code" from the list of MUST > attributes to the list of SHOULD attributes. Now it is item 17. > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > "Absence of reliability of the data transfer, for example caused by > loss or reordering of packets containing flow information, MUST be > indicated." > > by > > "Different levels of reliability of the data transfer MAY be > supported. The collecting process MUST have sufficient information > for making a conservative assumption about the applied reliability > level. This means that the applied level of reliability MUST be as > high as or higher than indicated to the collecting process." > > 5. Add new paragraph after second paragraph in section "6.3.2": > > "The chosen method of data transfer MUST be extensible concerning > reliability. It MUST be possible to increase reliability by > extensions." > > 6. Add to References: > > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: > A Transport Protocol for Real-Time Applications", RFC 1889, > January 1996." > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jan 13 04:42:10 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05884 for ; Mon, 13 Jan 2003 04:42:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18Y0ne-0007hQ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jan 2003 03:22:30 -0600 Received: from f108.pav1.hotmail.com ([64.4.31.108] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18Y0nc-0007hJ-00 for ipfix@net.doit.wisc.edu; Mon, 13 Jan 2003 03:22:28 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Jan 2003 01:15:05 -0800 Received: from 57.250.229.136 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 13 Jan 2003 09:15:05 GMT X-Originating-IP: [57.250.229.136] From: "M. ELK" To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX protocol and SNMP Date: Mon, 13 Jan 2003 09:15:05 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jan 2003 09:15:05.0769 (UTC) FILETIME=[42E94990:01C2BAE4] Precedence: bulk Sender: majordomo listserver Hi Just an idea IFPFIX will report some fileds which it require that the collector have an SNMP access to decode it . As an example is the ifIndex where the collector need to access the box to get the interface description Just as an OPTIONAL could IPFIX protocol be extended to report such info eleviating the collector to have a built-in SNMP module . For netflow case : This is could be easily transported in V9 option template format (Another example is the Next-Hop-Ip-Addr field reported , normally for a user it is easier to see "Next_Hop_Router_Name" so the collector will either access the box with snmp or have a static file (say File1)listing interface Ip_Addr to "Router_name" mapping . Alternatively , the IPFIX could report Router_ID_IP_Addr (extracted from the IGP DataBase) in V9 option template format . The collector with the help of small file (Say file2) could drive the "Router_Name" . "File2" is easy to maintain manually than "File1" as "File1" keep changing (adding hardware ,new sub-interface config ..etc ) . N.B: For sure that having a built-in SNMP module or access to SNMP libraries is not an issue for Commercial/professional collector but the above option could be convenienet for "building U Own collector" style user . Or it could be seen to limit the SNMP query to the routers . Brgds _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jan 14 13:51:25 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06747 for ; Tue, 14 Jan 2003 13:51:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18YVrE-0002LX-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Jan 2003 12:32:16 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18YVrD-0002LR-00 for ipfix-req@net.doit.wisc.edu; Tue, 14 Jan 2003 12:32:15 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0EIarq03614; Tue, 14 Jan 2003 10:36:54 -0800 From: "Tal Givoly" To: "Juergen Quittek" Cc: Subject: RE: [ipfix-req] proposed changes for requirements document Date: Tue, 14 Jan 2003 10:32:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <22047953.1041613887@[10.1.1.128]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, Some recommendation of modification to the proposed changes: 4. Replace the first paragraph in section "6.3.2. Reliability": "Absence of reliability of the data transfer, for example caused by loss or reordering of packets containing flow information, MUST be indicated." by "Different levels of reliability of the data transfer MAY be supported. The collecting process MUST have sufficient information for making a conservative assumption about the applied reliability level. This means that the applied level of reliability MUST be as high as or higher than indicated to the collecting process." Regarding item 4, there seem to be a few concerns regarding the proposed wording: - It implies that the collecting process must indicate the level of reliability it is interested in, hence, there must be a mechanism to indicate this. - The words "conservative assumptions" are ambiguous. - It implies the level of reliability may be higher than required by collecting process - it is unclear to me why this is implied by the consensus to allow the protocol to "MAY" support higher levels of reliability. Therefore, may I propose the following alternative as a replacement for the first paragraph in "6.3.2 Reliability": "The data exchange between the exporter and the collector MAY support different levels of reliability. For the most basic level of reliability, the following should be maintained: - The collecting process MUST be able to detect the level of reliability. - The collection process MUST be able to detect any loss of data. For higher levels of reliability, the following should be maintained: - All reliability properties requirements of lower levels of reliability MUST be maintained. - The exporter process SHOULD be able to communicate with more than one collection process. - In case of failure the collection process, or in the connectivity between the exporter process and one collection process, transmission of data SHOULD be redirected, in a fail-over fashion, to a secondary collection process. - In case of failover, data that has not been acknowledged SHOULD be retransmitted to the secondary collection process. - The collection process MUST be able to eliminate duplicate reporting of the same records emanating from the fail over mechanism." 5. Add new paragraph after second paragraph in section "6.3.2": "The chosen method of data transfer MUST be extensible concerning reliability. It MUST be possible to increase reliability by extensions." Regarding item 5, I agree that a paragraph should be added after the second paragraph in 6.3.2. The main point on which I differ is that your proposed wording implies that there must be an "ability to ... by extensions" whereas I don't believe that is mandatory to meet the essence of the requirements. If a protocol supports adequate levels of reliability, as several of the currently evaluated protocols do, there may not be a need for an extension model. If, on the other hand, the protocol selected does not have a reliable delivery mechanism, then a well-defined means to extend it must be present. Therefore, may I suggest a slightly different wording than the version you proposed: "If higher levels of reliability are not supported, there must be a well-defined mechanism to extend the protocol to allow for increasing the reliability to support higher degrees of reliability." I believe that even though the wording above may seem to hint at an implementation, in fact, it merely may state some lowest common denominator features recurring in practically all existing reliable delivery protocols. Best regards, Tal -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jan 14 18:49:29 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16374 for ; Tue, 14 Jan 2003 18:49:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18YaQz-00018v-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Jan 2003 17:25:29 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18YaQx-00018l-00 for ipfix-req@net.doit.wisc.edu; Tue, 14 Jan 2003 17:25:27 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0ENPQR97183; Wed, 15 Jan 2003 00:25:26 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 070218362A; Wed, 15 Jan 2003 01:33:48 +0100 (CET) Date: Wed, 15 Jan 2003 00:26:21 +0100 From: Juergen Quittek To: Tal Givoly Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document Message-ID: <6601792.1042590381@[10.1.1.26]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Tal, Thank you for the comments. See my replies inline. Juergen -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > Juergen, > > Some recommendation of modification to the proposed changes: > > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > "Absence of reliability of the data transfer, for example caused by > loss or reordering of packets containing flow information, MUST be > indicated." > > by > > "Different levels of reliability of the data transfer MAY be > supported. The collecting process MUST have sufficient information > for making a conservative assumption about the applied reliability > level. This means that the applied level of reliability MUST be as > high as or higher than indicated to the collecting process." > > > > > Regarding item 4, there seem to be a few concerns regarding the proposed > wording: > > - It implies that the collecting process must indicate the level > of reliability it is interested in, hence, there must be a > mechanism to indicate this. No. It does not. At least, I cannot see this. Why do you think so? > - The words "conservative assumptions" are ambiguous. I agree. They should be changed. > - It implies the level of reliability may be higher than required by > collecting process - it is unclear to me why this is implied by > the consensus to allow the protocol to "MAY" support higher > levels of reliability. Of course the level may be higher or lower than required by the collecting process. It just says that the collecting process needs sufficient information on the reliability in order to find out whether or not the level is sufficient. > > > Therefore, may I propose the following alternative as a replacement for the > first paragraph in "6.3.2 Reliability": > > "The data exchange between the exporter and the collector MAY I'd suggest "data transfer from the exporting process to the collecting process". > support different levels of reliability. > > For the most basic level of reliability, the following should > be maintained: > - The collecting process MUST be able to detect the level of > reliability. > - The collection process MUST be able to detect any loss of data. > > For higher levels of reliability, the following should be Are these several higher levels or is it a single higher level including everything below? > maintained: > - All reliability properties requirements of lower levels of > reliability MUST be maintained. Above you say "the following should b maintained", within the following you say "MUST". Is should x MUST = should? > - The exporter process SHOULD be able to communicate with more > than one collection process. This is already covered as MAY requirement by section 8.3. > - In case of failure the collection process, or in the > connectivity between the exporter process and one collection > process, transmission of data SHOULD be redirected, in a > fail-over fashion, to a secondary collection process. This is already covered by the last paragraph of section 6.3.2 > - In case of failover, data that has not been acknowledged > SHOULD be retransmitted to the secondary collection process. Isn't this a solution rather than a requirement? > - The collection process MUST be able to eliminate duplicate > reporting of the same records emanating from the fail over > mechanism." This is already covered as MAY requirement by section 8.3. > > > > > 5. Add new paragraph after second paragraph in section "6.3.2": > > "The chosen method of data transfer MUST be extensible concerning > reliability. It MUST be possible to increase reliability by > extensions." > > > > Regarding item 5, I agree that a paragraph should be added after the second > paragraph in 6.3.2. The main point on which I differ is that your proposed > wording implies that there must be an "ability to ... by extensions" whereas > I don't believe that is mandatory to meet the essence of the requirements. > If a protocol supports adequate levels of reliability, as several of the > currently evaluated protocols do, there may not be a need for an extension Weren't among the people teaching us that there cannot be sufficient reliability? What is sufficient depends on the requirements of the collecting process or the application processing the transfered data. > model. If, on the other hand, the protocol selected does not have a reliable > delivery mechanism, then a well-defined means to extend it must be present. Some people said that without application level ACKs there is no real reliability. Consequently, all you ask for above is not reliable and would need to be extensible. The main lesson I learned is that there are several levels of reliability and that you cannot say something is reliable or not without specifying what you mean with "reliable". The only consequence is that you have to ask for every level, that it still is open for further increasing reliability. > Therefore, may I suggest a slightly different wording than the version you > proposed: > > "If higher levels of reliability are not supported, there must be The term "higher levels" is only implicitly defined by your text above and still ambiguous. How many levels need to be supported such that you need not to be extensible anymore? > a well-defined mechanism to extend the protocol to allow for > increasing the reliability to support higher degrees of Is "degree" equivqalent to "level"? > reliability." > > > > I believe that even though the wording above may seem to hint at an > implementation, in fact, it merely may state some lowest common denominator > features recurring in practically all existing reliable delivery protocols. > > Best regards, > > Tal > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 15 15:33:37 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09340 for ; Wed, 15 Jan 2003 15:33:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18Ytt5-0000dU-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jan 2003 14:11:47 -0600 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18Ytt3-0000dN-00 for ipfix-req@net.doit.wisc.edu; Wed, 15 Jan 2003 14:11:45 -0600 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id 9A402A01317; Wed, 15 Jan 2003 15:11:44 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 576FB1C0008D; Wed, 15 Jan 2003 15:11:44 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 15 Jan 2003 15:11:44 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F212D24B13@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Juergen Quittek'" , Tal Givoly Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 15 Jan 2003 15:11:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Hi, There seems to be agreement that losing flow information implies a lack of reliability. I think understanding where this information loss might occur and what steps are taken to "recover" the lost information is the essence of the different "levels of reliability". Today the requirements draft has the following statement in section 6.3.2: "Possible reasons for flow information loss include resource shortage at the exporter, loss of packets between the exporting process and collecting process, etc." Rather than ending with "etc." it would be nice to try to enumerate all the basic loss scenarios. I don't think there are that many in the model defined: ObsPt -> Metering Proc -> Exporter -> Collector Moving from left to right across the model, I see the following "failures" impacting reliability: 1. A metering process may somehow fail to "keep up" with the packets going past the ObsPt. This lack of reliability is not recoverable by the exporter (i.e. The same box won't be able to "see" these flows again). It should be reported as covered in section 5.1. 2. The exporter may be experiencing congestion and not be able to buffer new flows recorded by the metering process. This lack of reliability will again be unrecoverable from the perspective of the exporting system. Either old flows or newly reported flows need to be dropped. Such loss should be reported. 3. A packet carrying a flow sent by the Exporter to the Collector is dropped by the network. This is an issue for unreliable transports such as UDP. For reliable transports, these drops are recovered by the transport itself. This lack of reliability is only an issue for UDP based protocols and MAY be addressed through some means, such as buffering on the Exporter and an acknowledgement/ timeout scheme. Having a "failover Collector" greatly increases the likelihood that the Exporter will not exhaust buffering before successfully retransmitting flow information. 4. The network connection between the Exporter and the Collector is lost due to a failure (either in the network or on the collector). The disposition of some flow information in transit may be unknown to the Exporter. In addition subsequent flow information is also at risk of being lost. This lack of reliability MAY be addressed by some means such as buffering on the Exporter and having a failover Collector(s) available. An application layer acknowledgement scheme aids the exporter in identifying what information sent has actually been received by the Collector. 5. The network connection between the Exporter and the Collector is taken down for maintenance or other administrative purposes. In this case it is desireable to gracefully transition the delivery of flows from one Collector to an auxilliary. Procedures for graceful handoff MAY be refined from those for a simple failure (#4), to increase efficiency. 6. Congestion is detected between the Exporter and the Collector, which jeopardizes the delivery of flow information. The slow receiver/link problem. This may be considered either a basic failure of the collector as in #4 above, or unavoidable as in #2 above. So to me, it seems like reliability boils down to whether or not the protocol addresses 3, 4 and 5. I think the protocol MUST address 3, 4 and 5. However in a deployment, there MAY only be one Collector set up. In this case the reliable delivery is likely to be impacted by failures 4 and 5 from time to time. That said, I don't see this as an extension, but really a capability of the protocol. Or perhaps it is a property of the exporter, i.e. are any flows ever buffered for retransmission in the event of loss of the communication channel between the exporter and collector. Perhaps an indication on the part of the exporter as to whether it makes any attempt to retransmit to a secondary should be called out. However I don't see lots of "levels" of reliability. Regards, Jeff Meyer > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Tuesday, January 14, 2003 3:26 PM > To: Tal Givoly > Cc: ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hi Tal, > > Thank you for the comments. See my replies inline. > > Juergen > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > Juergen, > > > > Some recommendation of modification to the proposed changes: > > > > > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > > > "Absence of reliability of the data transfer, for > example caused by > > loss or reordering of packets containing flow > information, MUST be > > indicated." > > > > by > > > > "Different levels of reliability of the data transfer MAY be > > supported. The collecting process MUST have sufficient > information > > for making a conservative assumption about the applied > reliability > > level. This means that the applied level of reliability > MUST be as > > high as or higher than indicated to the collecting process." > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > the proposed > > wording: > > > > - It implies that the collecting process must indicate the level > > of reliability it is interested in, hence, there must be a > > mechanism to indicate this. > > No. It does not. At least, I cannot see this. Why do you think so? > > > - The words "conservative assumptions" are ambiguous. > > I agree. They should be changed. > > > - It implies the level of reliability may be higher than > required by > > collecting process - it is unclear to me why this is implied by > > the consensus to allow the protocol to "MAY" support higher > > levels of reliability. > > Of course the level may be higher or lower than required by > the collecting > process. It just says that the collecting process needs sufficient > information on the reliability in order to find out whether or not the > level is sufficient. > > > > > > > Therefore, may I propose the following alternative as a > replacement for the > > first paragraph in "6.3.2 Reliability": > > > > "The data exchange between the exporter and the collector MAY > > I'd suggest "data transfer from the exporting process to the > collecting process". > > > support different levels of reliability. > > > > For the most basic level of reliability, the following should > > be maintained: > > - The collecting process MUST be able to detect the level of > > reliability. > > - The collection process MUST be able to detect any > loss of data. > > > > For higher levels of reliability, the following should be > > Are these several higher levels or is it a single higher level > including everything below? > > > maintained: > > - All reliability properties requirements of lower levels of > > reliability MUST be maintained. > > Above you say "the following should b maintained", within the > following you say "MUST". Is should x MUST = should? > > > - The exporter process SHOULD be able to communicate with more > > than one collection process. > > This is already covered as MAY requirement by section 8.3. > > > - In case of failure the collection process, or in the > > connectivity between the exporter process and one collection > > process, transmission of data SHOULD be redirected, in a > > fail-over fashion, to a secondary collection process. > > This is already covered by the last paragraph of section 6.3.2 > > > - In case of failover, data that has not been acknowledged > > SHOULD be retransmitted to the secondary collection process. > > Isn't this a solution rather than a requirement? > > > - The collection process MUST be able to eliminate duplicate > > reporting of the same records emanating from the fail over > > mechanism." > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > 5. Add new paragraph after second paragraph in section "6.3.2": > > > > "The chosen method of data transfer MUST be extensible concerning > > reliability. It MUST be possible to increase reliability by > > extensions." > > > > > > > > Regarding item 5, I agree that a paragraph should be added > after the second > > paragraph in 6.3.2. The main point on which I differ is > that your proposed > > wording implies that there must be an "ability to ... by > extensions" whereas > > I don't believe that is mandatory to meet the essence of > the requirements. > > If a protocol supports adequate levels of reliability, as > several of the > > currently evaluated protocols do, there may not be a need > for an extension > > Weren't among the people teaching us that there cannot be sufficient > reliability? What is sufficient depends on the requirements of the > collecting process or the application processing the transfered data. > > > model. If, on the other hand, the protocol selected does > not have a reliable > > delivery mechanism, then a well-defined means to extend it > must be present. > > Some people said that without application level ACKs there is > no real reliability. > Consequently, all you ask for above is not reliable and would > need to be > extensible. > > The main lesson I learned is that there are several levels of > reliability > and that you cannot say something is reliable or not without > specifying > what you mean with "reliable". The only consequence is that > you have to > ask for every level, that it still is open for further > increasing reliability. > > > Therefore, may I suggest a slightly different wording than > the version you > > proposed: > > > > "If higher levels of reliability are not supported, there must be > > The term "higher levels" is only implicitly defined by your text above > and still ambiguous. How many levels need to be supported > such that you > need not to be extensible anymore? > > > a well-defined mechanism to extend the protocol to allow for > > increasing the reliability to support higher degrees of > > Is "degree" equivqalent to "level"? > > > reliability." > > > > > > > > I believe that even though the wording above may seem to hint at an > > implementation, in fact, it merely may state some lowest > common denominator > > features recurring in practically all existing reliable > delivery protocols. > > > > Best regards, > > > > Tal > > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 15 16:15:21 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10281 for ; Wed, 15 Jan 2003 16:15:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18Yulz-0001rF-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jan 2003 15:08:31 -0600 Received: from pool-151-202-13-76.ny5030.east.verizon.net ([151.202.13.76] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18Yulx-0001qi-00 for ipfix-req@net.doit.wisc.edu; Wed, 15 Jan 2003 15:08:29 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0FL7dO07906; Wed, 15 Jan 2003 16:07:39 -0500 From: "Carter Bullard" To: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" , "'Tal Givoly'" Cc: Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 15 Jan 2003 16:07:30 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A50A@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FBFDD@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Jeff, I agree that enumerating the various conditions is the correct thing, so I say great! On a different note, there is a huge difference between detecting/indicating loss of reliability and assuring a level of reliability. I am of the school that assuring reliability should be outside the scope of IPFIX. Even simple retransmission capabilities are not a potential solution as the principal target device for IPFIX is not going to be able to support the feature. But by providing the information needed to detect loss, such as through per record sequence numbering in conjunction with timestamping, an application will have all the info needed to enable out-of-band recovery. IPFIX could support recovery itself if it could handle selective record transfer requests. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > MEYER,JEFFREY D (HP-Cupertino,ex1) > Sent: Wednesday, January 15, 2003 3:12 PM > To: 'Juergen Quittek'; Tal Givoly > Cc: ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hi, > > There seems to be agreement that losing flow information > implies a lack of reliability. I think understanding where > this information loss might occur and what steps are taken to > "recover" the lost information is the essence of the > different "levels of reliability". > > > Today the requirements draft has the following statement in > section 6.3.2: > > > "Possible reasons for flow information loss include resource > shortage at the exporter, loss of packets between the > exporting process and collecting process, etc." > > > Rather than ending with "etc." it would be nice to try to > enumerate all the basic loss scenarios. I don't think there > are that many in the model defined: > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > Moving from left to right across the model, I see > the following "failures" impacting reliability: > > 1. A metering process may somehow fail to "keep up" with > the packets going past the ObsPt. > > This lack of reliability is not recoverable by the > exporter (i.e. The same box won't be able to "see" > these flows again). It should be reported as covered > in section 5.1. > > 2. The exporter may be experiencing congestion and > not be able to buffer new flows recorded by the metering > process. > > This lack of reliability will again be unrecoverable > from the perspective of the exporting system. Either > old flows or newly reported flows need to be dropped. > Such loss should be reported. > > 3. A packet carrying a flow sent by the Exporter to the Collector > is dropped by the network. This is an issue for unreliable > transports such as UDP. For reliable transports, these > drops are recovered by the transport itself. > > This lack of reliability is only an issue for UDP based > protocols and MAY be addressed through some means, > such as buffering on the Exporter and an acknowledgement/ > timeout scheme. > > Having a "failover Collector" greatly increases the > likelihood that the Exporter will not exhaust buffering > before successfully retransmitting flow information. > > 4. The network connection between the Exporter and the > Collector is lost due to a failure (either in the network > or on the collector). > > The disposition of some flow information in transit may be > unknown to the Exporter. In addition subsequent flow > information is also at risk of being lost. > > This lack of reliability MAY be addressed by some > means such as buffering on the Exporter and having > a failover Collector(s) available. > > An application layer acknowledgement scheme aids > the exporter in identifying what information sent > has actually been received by the Collector. > > 5. The network connection between the Exporter and > the Collector is taken down for maintenance or other > administrative purposes. > > In this case it is desireable to gracefully transition > the delivery of flows from one Collector to an > auxilliary. > > Procedures for graceful handoff MAY be refined from > those for a simple failure (#4), to increase efficiency. > > 6. Congestion is detected between the Exporter and the > Collector, which jeopardizes the delivery of flow > information. The slow receiver/link problem. > > This may be considered either a basic failure of > the collector as in #4 above, or unavoidable as in > #2 above. > > > So to me, it seems like reliability boils down to whether > or not the protocol addresses 3, 4 and 5. > > I think the protocol MUST address 3, 4 and 5. However in > a deployment, there MAY only be one Collector set up. In > this case the reliable delivery is likely to be impacted > by failures 4 and 5 from time to time. > > That said, I don't see this as an extension, but really > a capability of the protocol. Or perhaps it is a property of > the exporter, i.e. are any flows ever buffered for > retransmission in the event of loss of the communication > channel between the exporter and collector. > > Perhaps an indication on the part of the exporter as to > whether it makes any attempt to retransmit to a secondary > should be called out. However I don't see lots of "levels" > of reliability. > > > Regards, > > Jeff Meyer > > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > Sent: Tuesday, January 14, 2003 3:26 PM > > To: Tal Givoly > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hi Tal, > > > > Thank you for the comments. See my replies inline. > > > > Juergen > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > Juergen, > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > > > > > "Absence of reliability of the data transfer, for > > example caused by > > > loss or reordering of packets containing flow > > information, MUST be > > > indicated." > > > > > > by > > > > > > "Different levels of reliability of the data transfer MAY be > > > supported. The collecting process MUST have sufficient > > information > > > for making a conservative assumption about the applied > > reliability > > > level. This means that the applied level of reliability > > MUST be as > > > high as or higher than indicated to the collecting process." > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > the proposed > > > wording: > > > > > > - It implies that the collecting process must indicate the level > > > of reliability it is interested in, hence, there must be a > > > mechanism to indicate this. > > > > No. It does not. At least, I cannot see this. Why do you think so? > > > > > - The words "conservative assumptions" are ambiguous. > > > > I agree. They should be changed. > > > > > - It implies the level of reliability may be higher than > > required by > > > collecting process - it is unclear to me why this is implied by > > > the consensus to allow the protocol to "MAY" support higher > > > levels of reliability. > > > > Of course the level may be higher or lower than required by > > the collecting > > process. It just says that the collecting process needs sufficient > > information on the reliability in order to find out whether > or not the > > level is sufficient. > > > > > > > > > > > Therefore, may I propose the following alternative as a > > replacement for the > > > first paragraph in "6.3.2 Reliability": > > > > > > "The data exchange between the exporter and the collector MAY > > > > I'd suggest "data transfer from the exporting process to the > > collecting process". > > > > > support different levels of reliability. > > > > > > For the most basic level of reliability, the following should > > > be maintained: > > > - The collecting process MUST be able to detect the level of > > > reliability. > > > - The collection process MUST be able to detect any > > loss of data. > > > > > > For higher levels of reliability, the following should be > > > > Are these several higher levels or is it a single higher level > > including everything below? > > > > > maintained: > > > - All reliability properties requirements of lower levels of > > > reliability MUST be maintained. > > > > Above you say "the following should b maintained", within the > > following you say "MUST". Is should x MUST = should? > > > > > - The exporter process SHOULD be able to communicate > with more > > > than one collection process. > > > > This is already covered as MAY requirement by section 8.3. > > > > > - In case of failure the collection process, or in the > > > connectivity between the exporter process and one > collection > > > process, transmission of data SHOULD be redirected, in a > > > fail-over fashion, to a secondary collection process. > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > - In case of failover, data that has not been acknowledged > > > SHOULD be retransmitted to the secondary > collection process. > > > > Isn't this a solution rather than a requirement? > > > > > - The collection process MUST be able to eliminate duplicate > > > reporting of the same records emanating from the fail over > > > mechanism." > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in section "6.3.2": > > > > > > "The chosen method of data transfer MUST be extensible > concerning > > > reliability. It MUST be possible to increase reliability by > > > extensions." > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > after the second > > > paragraph in 6.3.2. The main point on which I differ is > > that your proposed > > > wording implies that there must be an "ability to ... by > > extensions" whereas > > > I don't believe that is mandatory to meet the essence of > > the requirements. > > > If a protocol supports adequate levels of reliability, as > > several of the > > > currently evaluated protocols do, there may not be a need > > for an extension > > > > Weren't among the people teaching us that there cannot be > sufficient > > reliability? What is sufficient depends on the requirements of the > > collecting process or the application processing the > transfered data. > > > > > model. If, on the other hand, the protocol selected does > > not have a reliable > > > delivery mechanism, then a well-defined means to extend it > > must be present. > > > > Some people said that without application level ACKs there is > > no real reliability. > > Consequently, all you ask for above is not reliable and would > > need to be > > extensible. > > > > The main lesson I learned is that there are several levels of > > reliability > > and that you cannot say something is reliable or not without > > specifying > > what you mean with "reliable". The only consequence is that > > you have to > > ask for every level, that it still is open for further > > increasing reliability. > > > > > Therefore, may I suggest a slightly different wording than > > the version you > > > proposed: > > > > > > "If higher levels of reliability are not supported, > there must be > > > > The term "higher levels" is only implicitly defined by your > text above > > and still ambiguous. How many levels need to be supported such that > > you need not to be extensible anymore? > > > > > a well-defined mechanism to extend the protocol to allow for > > > increasing the reliability to support higher degrees of > > > > Is "degree" equivqalent to "level"? > > > > > reliability." > > > > > > > > > > > > I believe that even though the wording above may seem to > hint at an > > > implementation, in fact, it merely may state some lowest > > common denominator > > > features recurring in practically all existing reliable > > delivery protocols. > > > > > > Best regards, > > > > > > Tal > > > > > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 15 20:02:43 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16713 for ; Wed, 15 Jan 2003 20:02:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18YyA0-0006ey-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jan 2003 18:45:32 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18Yy9y-0006en-00 for ipfix-req@net.doit.wisc.edu; Wed, 15 Jan 2003 18:45:30 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0G0oBq27408; Wed, 15 Jan 2003 16:50:12 -0800 From: "Tal Givoly" To: "Carter Bullard" Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 15 Jan 2003 16:45:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A50A@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter, Haven't we agreed that the protocol MAY support more reliable transports than merely being able to identify the fact that loss has occurred? If that is the case, then we must allow for mechanisms by which the protocol can support them. Merely sequencing the records and allowing identification of the amount of records lost supports the "must" requirements, but leaves no ability to support the "may" requirement in a cost-effective manner (e.g. out of band recovery). The minimum must requirements of being able to identify how much data has been lost in a potentially unreliable delivery mechanism or for any other cause of loss will still be there, but for those applications requiring higher reliability, I believe it is required to provide some additional description as part of the requirements. Tal -----Original Message----- From: Carter Bullard [mailto:carter@qosient.com] Sent: Wednesday, January 15, 2003 1:08 PM To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek'; 'Tal Givoly' Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document Hey Jeff, I agree that enumerating the various conditions is the correct thing, so I say great! On a different note, there is a huge difference between detecting/indicating loss of reliability and assuring a level of reliability. I am of the school that assuring reliability should be outside the scope of IPFIX. Even simple retransmission capabilities are not a potential solution as the principal target device for IPFIX is not going to be able to support the feature. But by providing the information needed to detect loss, such as through per record sequence numbering in conjunction with timestamping, an application will have all the info needed to enable out-of-band recovery. IPFIX could support recovery itself if it could handle selective record transfer requests. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > MEYER,JEFFREY D (HP-Cupertino,ex1) > Sent: Wednesday, January 15, 2003 3:12 PM > To: 'Juergen Quittek'; Tal Givoly > Cc: ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hi, > > There seems to be agreement that losing flow information > implies a lack of reliability. I think understanding where > this information loss might occur and what steps are taken to > "recover" the lost information is the essence of the > different "levels of reliability". > > > Today the requirements draft has the following statement in > section 6.3.2: > > > "Possible reasons for flow information loss include resource > shortage at the exporter, loss of packets between the > exporting process and collecting process, etc." > > > Rather than ending with "etc." it would be nice to try to > enumerate all the basic loss scenarios. I don't think there > are that many in the model defined: > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > Moving from left to right across the model, I see > the following "failures" impacting reliability: > > 1. A metering process may somehow fail to "keep up" with > the packets going past the ObsPt. > > This lack of reliability is not recoverable by the > exporter (i.e. The same box won't be able to "see" > these flows again). It should be reported as covered > in section 5.1. > > 2. The exporter may be experiencing congestion and > not be able to buffer new flows recorded by the metering > process. > > This lack of reliability will again be unrecoverable > from the perspective of the exporting system. Either > old flows or newly reported flows need to be dropped. > Such loss should be reported. > > 3. A packet carrying a flow sent by the Exporter to the Collector > is dropped by the network. This is an issue for unreliable > transports such as UDP. For reliable transports, these > drops are recovered by the transport itself. > > This lack of reliability is only an issue for UDP based > protocols and MAY be addressed through some means, > such as buffering on the Exporter and an acknowledgement/ > timeout scheme. > > Having a "failover Collector" greatly increases the > likelihood that the Exporter will not exhaust buffering > before successfully retransmitting flow information. > > 4. The network connection between the Exporter and the > Collector is lost due to a failure (either in the network > or on the collector). > > The disposition of some flow information in transit may be > unknown to the Exporter. In addition subsequent flow > information is also at risk of being lost. > > This lack of reliability MAY be addressed by some > means such as buffering on the Exporter and having > a failover Collector(s) available. > > An application layer acknowledgement scheme aids > the exporter in identifying what information sent > has actually been received by the Collector. > > 5. The network connection between the Exporter and > the Collector is taken down for maintenance or other > administrative purposes. > > In this case it is desireable to gracefully transition > the delivery of flows from one Collector to an > auxilliary. > > Procedures for graceful handoff MAY be refined from > those for a simple failure (#4), to increase efficiency. > > 6. Congestion is detected between the Exporter and the > Collector, which jeopardizes the delivery of flow > information. The slow receiver/link problem. > > This may be considered either a basic failure of > the collector as in #4 above, or unavoidable as in > #2 above. > > > So to me, it seems like reliability boils down to whether > or not the protocol addresses 3, 4 and 5. > > I think the protocol MUST address 3, 4 and 5. However in > a deployment, there MAY only be one Collector set up. In > this case the reliable delivery is likely to be impacted > by failures 4 and 5 from time to time. > > That said, I don't see this as an extension, but really > a capability of the protocol. Or perhaps it is a property of > the exporter, i.e. are any flows ever buffered for > retransmission in the event of loss of the communication > channel between the exporter and collector. > > Perhaps an indication on the part of the exporter as to > whether it makes any attempt to retransmit to a secondary > should be called out. However I don't see lots of "levels" > of reliability. > > > Regards, > > Jeff Meyer > > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > Sent: Tuesday, January 14, 2003 3:26 PM > > To: Tal Givoly > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hi Tal, > > > > Thank you for the comments. See my replies inline. > > > > Juergen > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > Juergen, > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > > > > > "Absence of reliability of the data transfer, for > > example caused by > > > loss or reordering of packets containing flow > > information, MUST be > > > indicated." > > > > > > by > > > > > > "Different levels of reliability of the data transfer MAY be > > > supported. The collecting process MUST have sufficient > > information > > > for making a conservative assumption about the applied > > reliability > > > level. This means that the applied level of reliability > > MUST be as > > > high as or higher than indicated to the collecting process." > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > the proposed > > > wording: > > > > > > - It implies that the collecting process must indicate the level > > > of reliability it is interested in, hence, there must be a > > > mechanism to indicate this. > > > > No. It does not. At least, I cannot see this. Why do you think so? > > > > > - The words "conservative assumptions" are ambiguous. > > > > I agree. They should be changed. > > > > > - It implies the level of reliability may be higher than > > required by > > > collecting process - it is unclear to me why this is implied by > > > the consensus to allow the protocol to "MAY" support higher > > > levels of reliability. > > > > Of course the level may be higher or lower than required by > > the collecting > > process. It just says that the collecting process needs sufficient > > information on the reliability in order to find out whether > or not the > > level is sufficient. > > > > > > > > > > > Therefore, may I propose the following alternative as a > > replacement for the > > > first paragraph in "6.3.2 Reliability": > > > > > > "The data exchange between the exporter and the collector MAY > > > > I'd suggest "data transfer from the exporting process to the > > collecting process". > > > > > support different levels of reliability. > > > > > > For the most basic level of reliability, the following should > > > be maintained: > > > - The collecting process MUST be able to detect the level of > > > reliability. > > > - The collection process MUST be able to detect any > > loss of data. > > > > > > For higher levels of reliability, the following should be > > > > Are these several higher levels or is it a single higher level > > including everything below? > > > > > maintained: > > > - All reliability properties requirements of lower levels of > > > reliability MUST be maintained. > > > > Above you say "the following should b maintained", within the > > following you say "MUST". Is should x MUST = should? > > > > > - The exporter process SHOULD be able to communicate > with more > > > than one collection process. > > > > This is already covered as MAY requirement by section 8.3. > > > > > - In case of failure the collection process, or in the > > > connectivity between the exporter process and one > collection > > > process, transmission of data SHOULD be redirected, in a > > > fail-over fashion, to a secondary collection process. > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > - In case of failover, data that has not been acknowledged > > > SHOULD be retransmitted to the secondary > collection process. > > > > Isn't this a solution rather than a requirement? > > > > > - The collection process MUST be able to eliminate duplicate > > > reporting of the same records emanating from the fail over > > > mechanism." > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in section "6.3.2": > > > > > > "The chosen method of data transfer MUST be extensible > concerning > > > reliability. It MUST be possible to increase reliability by > > > extensions." > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > after the second > > > paragraph in 6.3.2. The main point on which I differ is > > that your proposed > > > wording implies that there must be an "ability to ... by > > extensions" whereas > > > I don't believe that is mandatory to meet the essence of > > the requirements. > > > If a protocol supports adequate levels of reliability, as > > several of the > > > currently evaluated protocols do, there may not be a need > > for an extension > > > > Weren't among the people teaching us that there cannot be > sufficient > > reliability? What is sufficient depends on the requirements of the > > collecting process or the application processing the > transfered data. > > > > > model. If, on the other hand, the protocol selected does > > not have a reliable > > > delivery mechanism, then a well-defined means to extend it > > must be present. > > > > Some people said that without application level ACKs there is > > no real reliability. > > Consequently, all you ask for above is not reliable and would > > need to be > > extensible. > > > > The main lesson I learned is that there are several levels of > > reliability > > and that you cannot say something is reliable or not without > > specifying > > what you mean with "reliable". The only consequence is that > > you have to > > ask for every level, that it still is open for further > > increasing reliability. > > > > > Therefore, may I suggest a slightly different wording than > > the version you > > > proposed: > > > > > > "If higher levels of reliability are not supported, > there must be > > > > The term "higher levels" is only implicitly defined by your > text above > > and still ambiguous. How many levels need to be supported such that > > you need not to be extensible anymore? > > > > > a well-defined mechanism to extend the protocol to allow for > > > increasing the reliability to support higher degrees of > > > > Is "degree" equivqalent to "level"? > > > > > reliability." > > > > > > > > > > > > I believe that even though the wording above may seem to > hint at an > > > implementation, in fact, it merely may state some lowest > > common denominator > > > features recurring in practically all existing reliable > > delivery protocols. > > > > > > Best regards, > > > > > > Tal > > > > > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 15 20:05:35 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16793 for ; Wed, 15 Jan 2003 20:05:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18YyFr-0006mi-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jan 2003 18:51:35 -0600 Received: from pool-151-202-13-76.ny5030.east.verizon.net ([151.202.13.76] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18YyFn-0006ma-00 for ipfix-req@net.doit.wisc.edu; Wed, 15 Jan 2003 18:51:32 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0G0pTO08273; Wed, 15 Jan 2003 19:51:29 -0500 From: "Carter Bullard" To: "'Tal Givoly'" Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 15 Jan 2003 19:51:20 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E7E2@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC0F0@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Tal, Could that mean TCP vs UDP vs RTP vs multicast, or do you mean IPFIX level reliability? If its IPFIX level, then you're going to have to negotiate the optional reliability features, and I thought that negotiation had been tossed out? Carter > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Wednesday, January 15, 2003 7:45 PM > To: Carter Bullard > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Carter, > > Haven't we agreed that the protocol MAY support more reliable > transports than merely being able to identify the fact that > loss has occurred? If that is the case, then we must allow > for mechanisms by which the protocol can support them. Merely > sequencing the records and allowing identification of the > amount of records lost supports the "must" requirements, but > leaves no ability to support the "may" requirement in a > cost-effective manner (e.g. out of band recovery). > > The minimum must requirements of being able to identify how > much data has been lost in a potentially unreliable delivery > mechanism or for any other cause of loss will still be there, > but for those applications requiring higher reliability, I > believe it is required to provide some additional description > as part of the requirements. > > Tal > > -----Original Message----- > From: Carter Bullard [mailto:carter@qosient.com] > Sent: Wednesday, January 15, 2003 1:08 PM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek'; > 'Tal Givoly' > Cc: ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hey Jeff, > I agree that enumerating the various conditions is > the correct thing, so I say great! > > On a different note, there is a huge difference > between detecting/indicating loss of reliability > and assuring a level of reliability. I am of the > school that assuring reliability should be outside the > scope of IPFIX. Even simple retransmission capabilities > are not a potential solution as the principal target > device for IPFIX is not going to be able to support > the feature. > > But by providing the information needed to detect > loss, such as through per record sequence numbering in > conjunction with timestamping, an application will have all > the info needed to enable out-of-band recovery. IPFIX could > support recovery itself if it could handle selective record > transfer requests. > > Carter > > > > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On > > Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) > > Sent: Wednesday, January 15, 2003 3:12 PM > > To: 'Juergen Quittek'; Tal Givoly > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hi, > > > > There seems to be agreement that losing flow information > implies a > > lack of reliability. I think understanding where this information > > loss might occur and what steps are taken to "recover" the lost > > information is the essence of the different "levels of reliability". > > > > > > Today the requirements draft has the following statement > in section > > 6.3.2: > > > > > > "Possible reasons for flow information loss include resource > > shortage at the exporter, loss of packets between the > > exporting process and collecting process, etc." > > > > > > Rather than ending with "etc." it would be nice to try to > enumerate > > all the basic loss scenarios. I don't think there are that many in > > the model defined: > > > > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > > > > Moving from left to right across the model, I see > > the following "failures" impacting reliability: > > > > 1. A metering process may somehow fail to "keep up" with > > the packets going past the ObsPt. > > > > This lack of reliability is not recoverable by the > > exporter (i.e. The same box won't be able to "see" > > these flows again). It should be reported as covered > > in section 5.1. > > > > 2. The exporter may be experiencing congestion and > > not be able to buffer new flows recorded by the metering > > process. > > > > This lack of reliability will again be unrecoverable > > from the perspective of the exporting system. Either > > old flows or newly reported flows need to be dropped. > > Such loss should be reported. > > > > 3. A packet carrying a flow sent by the Exporter to the > Collector > > is dropped by the network. This is an issue for unreliable > > transports such as UDP. For reliable transports, these > > drops are recovered by the transport itself. > > > > This lack of reliability is only an issue for UDP based > > protocols and MAY be addressed through some means, > > such as buffering on the Exporter and an acknowledgement/ > > timeout scheme. > > > > Having a "failover Collector" greatly increases the > > likelihood that the Exporter will not exhaust buffering > > before successfully retransmitting flow information. > > > > 4. The network connection between the Exporter and the > > Collector is lost due to a failure (either in the network > > or on the collector). > > > > The disposition of some flow information in transit may be > > unknown to the Exporter. In addition subsequent flow > > information is also at risk of being lost. > > > > This lack of reliability MAY be addressed by some > > means such as buffering on the Exporter and having > > a failover Collector(s) available. > > > > An application layer acknowledgement scheme aids > > the exporter in identifying what information sent > > has actually been received by the Collector. > > > > 5. The network connection between the Exporter and > > the Collector is taken down for maintenance or other > > administrative purposes. > > > > In this case it is desireable to gracefully transition > > the delivery of flows from one Collector to an > > auxilliary. > > > > Procedures for graceful handoff MAY be refined from > > those for a simple failure (#4), to increase efficiency. > > > > 6. Congestion is detected between the Exporter and the > > Collector, which jeopardizes the delivery of flow > > information. The slow receiver/link problem. > > > > This may be considered either a basic failure of > > the collector as in #4 above, or unavoidable as in > > #2 above. > > > > > > So to me, it seems like reliability boils down to whether > > or not the protocol addresses 3, 4 and 5. > > > > I think the protocol MUST address 3, 4 and 5. However in > > a deployment, there MAY only be one Collector set up. In > > this case the reliable delivery is likely to be impacted > > by failures 4 and 5 from time to time. > > > > That said, I don't see this as an extension, but really > > a capability of the protocol. Or perhaps it is a property of > > the exporter, i.e. are any flows ever buffered for > > retransmission in the event of loss of the communication > > channel between the exporter and collector. > > > > Perhaps an indication on the part of the exporter as to > > whether it makes any attempt to retransmit to a secondary > > should be called out. However I don't see lots of "levels" > > of reliability. > > > > > > Regards, > > > > Jeff Meyer > > > > > > > -----Original Message----- > > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > To: Tal Givoly > > > Cc: ipfix-req@net.doit.wisc.edu > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Hi Tal, > > > > > > Thank you for the comments. See my replies inline. > > > > > > Juergen > > > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > > > Juergen, > > > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > > > > > > > "Absence of reliability of the data transfer, for > > > example caused by > > > > loss or reordering of packets containing flow > > > information, MUST be > > > > indicated." > > > > > > > > by > > > > > > > > "Different levels of reliability of the data transfer MAY be > > > > supported. The collecting process MUST have sufficient > > > information > > > > for making a conservative assumption about the applied > > > reliability > > > > level. This means that the applied level of reliability > > > MUST be as > > > > high as or higher than indicated to the collecting > process." > > > > > > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > > the proposed > > > > wording: > > > > > > > > - It implies that the collecting process must indicate > the level > > > > of reliability it is interested in, hence, there must be a > > > > mechanism to indicate this. > > > > > > No. It does not. At least, I cannot see this. Why do you think so? > > > > > > > - The words "conservative assumptions" are ambiguous. > > > > > > I agree. They should be changed. > > > > > > > - It implies the level of reliability may be higher than > > > required by > > > > collecting process - it is unclear to me why this is > implied by > > > > the consensus to allow the protocol to "MAY" support higher > > > > levels of reliability. > > > > > > Of course the level may be higher or lower than required by the > > > collecting process. It just says that the collecting > process needs > > > sufficient information on the reliability in order to find out > > > whether > > or not the > > > level is sufficient. > > > > > > > > > > > > > > > Therefore, may I propose the following alternative as a > > > replacement for the > > > > first paragraph in "6.3.2 Reliability": > > > > > > > > "The data exchange between the exporter and the collector MAY > > > > > > I'd suggest "data transfer from the exporting process to the > > > collecting process". > > > > > > > support different levels of reliability. > > > > > > > > For the most basic level of reliability, the > following should > > > > be maintained: > > > > - The collecting process MUST be able to detect > the level of > > > > reliability. > > > > - The collection process MUST be able to detect any > > > loss of data. > > > > > > > > For higher levels of reliability, the following should be > > > > > > Are these several higher levels or is it a single higher level > > > including everything below? > > > > > > > maintained: > > > > - All reliability properties requirements of lower > levels of > > > > reliability MUST be maintained. > > > > > > Above you say "the following should b maintained", within the > > > following you say "MUST". Is should x MUST = should? > > > > > > > - The exporter process SHOULD be able to communicate > > with more > > > > than one collection process. > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > - In case of failure the collection process, or in the > > > > connectivity between the exporter process and one > > collection > > > > process, transmission of data SHOULD be redirected, in a > > > > fail-over fashion, to a secondary collection process. > > > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > > > - In case of failover, data that has not been acknowledged > > > > SHOULD be retransmitted to the secondary > > collection process. > > > > > > Isn't this a solution rather than a requirement? > > > > > > > - The collection process MUST be able to eliminate > duplicate > > > > reporting of the same records emanating from the > fail over > > > > mechanism." > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in section "6.3.2": > > > > > > > > "The chosen method of data transfer MUST be extensible > > concerning > > > > reliability. It MUST be possible to increase reliability by > > > > extensions." > > > > > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > > after the second > > > > paragraph in 6.3.2. The main point on which I differ is > > > that your proposed > > > > wording implies that there must be an "ability to ... by > > > extensions" whereas > > > > I don't believe that is mandatory to meet the essence of > > > the requirements. > > > > If a protocol supports adequate levels of reliability, as > > > several of the > > > > currently evaluated protocols do, there may not be a need > > > for an extension > > > > > > Weren't among the people teaching us that there cannot be > > sufficient > > > reliability? What is sufficient depends on the > requirements of the > > > collecting process or the application processing the > > transfered data. > > > > > > > model. If, on the other hand, the protocol selected does > > > not have a reliable > > > > delivery mechanism, then a well-defined means to extend it > > > must be present. > > > > > > Some people said that without application level ACKs there is no > > > real reliability. Consequently, all you ask for above is not > > > reliable and would need to be > > > extensible. > > > > > > The main lesson I learned is that there are several levels of > > > reliability and that you cannot say something is reliable or not > > > without specifying > > > what you mean with "reliable". The only consequence is that > > > you have to > > > ask for every level, that it still is open for further > > > increasing reliability. > > > > > > > Therefore, may I suggest a slightly different wording than > > > the version you > > > > proposed: > > > > > > > > "If higher levels of reliability are not supported, > > there must be > > > > > > The term "higher levels" is only implicitly defined by your > > text above > > > and still ambiguous. How many levels need to be supported > such that > > > you need not to be extensible anymore? > > > > > > > a well-defined mechanism to extend the protocol to allow for > > > > increasing the reliability to support higher degrees of > > > > > > Is "degree" equivqalent to "level"? > > > > > > > reliability." > > > > > > > > > > > > > > > > I believe that even though the wording above may seem to > > hint at an > > > > implementation, in fact, it merely may state some lowest > > > common denominator > > > > features recurring in practically all existing reliable > > > delivery protocols. > > > > > > > > Best regards, > > > > > > > > Tal > > > > > > > > > > > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > > > ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 15 21:00:35 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17881 for ; Wed, 15 Jan 2003 21:00:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18YzBj-0000IR-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jan 2003 19:51:23 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18YzBh-0000IM-00 for ipfix-req@net.doit.wisc.edu; Wed, 15 Jan 2003 19:51:21 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0G1u8q28398; Wed, 15 Jan 2003 17:56:08 -0800 From: "Tal Givoly" To: "Carter Bullard" Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 15 Jan 2003 17:51:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607E7E2@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter, Quoting from the meeting minutes of the previous meeting: -- Dave Plonka wrote on 25 November 2002 10:30 -0600: > The issue of reliability was discussed. Juergen proposed, and it was > agreed to by a hum, that the requirements document should specify > that the IPFIX protocol MAY have "aditional reliability" and that > it MUST be open to reliability extensions. Tal Givoly will supply > clarifying text about this higher level of reliability, describing > it in an implementation independent way. Therefore, I do not imply TCP vs. UDP but rather the "additional reliability" that we agreed the IPFIX protocol MAY have and MUST be extensible enough to support. Therefore, my understanding was that it was not tossed out - but rather classified as MAY support but MUST be extensible enough to support. In order to demonstrate that it can be supported, I am proposing the wording to qualify what that means from a requirement standpoint. If you are referring to "negotiation" - that indeed is not currently a requirement, nor have I claimed it should be in any of these recent postings. I hope this helps clarify. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard Sent: Wednesday, January 15, 2003 4:51 PM To: 'Tal Givoly' Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek' Subject: RE: [ipfix-req] proposed changes for requirements document Hey Tal, Could that mean TCP vs UDP vs RTP vs multicast, or do you mean IPFIX level reliability? If its IPFIX level, then you're going to have to negotiate the optional reliability features, and I thought that negotiation had been tossed out? Carter > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Wednesday, January 15, 2003 7:45 PM > To: Carter Bullard > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Carter, > > Haven't we agreed that the protocol MAY support more reliable > transports than merely being able to identify the fact that > loss has occurred? If that is the case, then we must allow > for mechanisms by which the protocol can support them. Merely > sequencing the records and allowing identification of the > amount of records lost supports the "must" requirements, but > leaves no ability to support the "may" requirement in a > cost-effective manner (e.g. out of band recovery). > > The minimum must requirements of being able to identify how > much data has been lost in a potentially unreliable delivery > mechanism or for any other cause of loss will still be there, > but for those applications requiring higher reliability, I > believe it is required to provide some additional description > as part of the requirements. > > Tal > > -----Original Message----- > From: Carter Bullard [mailto:carter@qosient.com] > Sent: Wednesday, January 15, 2003 1:08 PM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek'; > 'Tal Givoly' > Cc: ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hey Jeff, > I agree that enumerating the various conditions is > the correct thing, so I say great! > > On a different note, there is a huge difference > between detecting/indicating loss of reliability > and assuring a level of reliability. I am of the > school that assuring reliability should be outside the > scope of IPFIX. Even simple retransmission capabilities > are not a potential solution as the principal target > device for IPFIX is not going to be able to support > the feature. > > But by providing the information needed to detect > loss, such as through per record sequence numbering in > conjunction with timestamping, an application will have all > the info needed to enable out-of-band recovery. IPFIX could > support recovery itself if it could handle selective record > transfer requests. > > Carter > > > > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On > > Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) > > Sent: Wednesday, January 15, 2003 3:12 PM > > To: 'Juergen Quittek'; Tal Givoly > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hi, > > > > There seems to be agreement that losing flow information > implies a > > lack of reliability. I think understanding where this information > > loss might occur and what steps are taken to "recover" the lost > > information is the essence of the different "levels of reliability". > > > > > > Today the requirements draft has the following statement > in section > > 6.3.2: > > > > > > "Possible reasons for flow information loss include resource > > shortage at the exporter, loss of packets between the > > exporting process and collecting process, etc." > > > > > > Rather than ending with "etc." it would be nice to try to > enumerate > > all the basic loss scenarios. I don't think there are that many in > > the model defined: > > > > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > > > > Moving from left to right across the model, I see > > the following "failures" impacting reliability: > > > > 1. A metering process may somehow fail to "keep up" with > > the packets going past the ObsPt. > > > > This lack of reliability is not recoverable by the > > exporter (i.e. The same box won't be able to "see" > > these flows again). It should be reported as covered > > in section 5.1. > > > > 2. The exporter may be experiencing congestion and > > not be able to buffer new flows recorded by the metering > > process. > > > > This lack of reliability will again be unrecoverable > > from the perspective of the exporting system. Either > > old flows or newly reported flows need to be dropped. > > Such loss should be reported. > > > > 3. A packet carrying a flow sent by the Exporter to the > Collector > > is dropped by the network. This is an issue for unreliable > > transports such as UDP. For reliable transports, these > > drops are recovered by the transport itself. > > > > This lack of reliability is only an issue for UDP based > > protocols and MAY be addressed through some means, > > such as buffering on the Exporter and an acknowledgement/ > > timeout scheme. > > > > Having a "failover Collector" greatly increases the > > likelihood that the Exporter will not exhaust buffering > > before successfully retransmitting flow information. > > > > 4. The network connection between the Exporter and the > > Collector is lost due to a failure (either in the network > > or on the collector). > > > > The disposition of some flow information in transit may be > > unknown to the Exporter. In addition subsequent flow > > information is also at risk of being lost. > > > > This lack of reliability MAY be addressed by some > > means such as buffering on the Exporter and having > > a failover Collector(s) available. > > > > An application layer acknowledgement scheme aids > > the exporter in identifying what information sent > > has actually been received by the Collector. > > > > 5. The network connection between the Exporter and > > the Collector is taken down for maintenance or other > > administrative purposes. > > > > In this case it is desireable to gracefully transition > > the delivery of flows from one Collector to an > > auxilliary. > > > > Procedures for graceful handoff MAY be refined from > > those for a simple failure (#4), to increase efficiency. > > > > 6. Congestion is detected between the Exporter and the > > Collector, which jeopardizes the delivery of flow > > information. The slow receiver/link problem. > > > > This may be considered either a basic failure of > > the collector as in #4 above, or unavoidable as in > > #2 above. > > > > > > So to me, it seems like reliability boils down to whether > > or not the protocol addresses 3, 4 and 5. > > > > I think the protocol MUST address 3, 4 and 5. However in > > a deployment, there MAY only be one Collector set up. In > > this case the reliable delivery is likely to be impacted > > by failures 4 and 5 from time to time. > > > > That said, I don't see this as an extension, but really > > a capability of the protocol. Or perhaps it is a property of > > the exporter, i.e. are any flows ever buffered for > > retransmission in the event of loss of the communication > > channel between the exporter and collector. > > > > Perhaps an indication on the part of the exporter as to > > whether it makes any attempt to retransmit to a secondary > > should be called out. However I don't see lots of "levels" > > of reliability. > > > > > > Regards, > > > > Jeff Meyer > > > > > > > -----Original Message----- > > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > To: Tal Givoly > > > Cc: ipfix-req@net.doit.wisc.edu > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Hi Tal, > > > > > > Thank you for the comments. See my replies inline. > > > > > > Juergen > > > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > > > Juergen, > > > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > > > > > > > "Absence of reliability of the data transfer, for > > > example caused by > > > > loss or reordering of packets containing flow > > > information, MUST be > > > > indicated." > > > > > > > > by > > > > > > > > "Different levels of reliability of the data transfer MAY be > > > > supported. The collecting process MUST have sufficient > > > information > > > > for making a conservative assumption about the applied > > > reliability > > > > level. This means that the applied level of reliability > > > MUST be as > > > > high as or higher than indicated to the collecting > process." > > > > > > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > > the proposed > > > > wording: > > > > > > > > - It implies that the collecting process must indicate > the level > > > > of reliability it is interested in, hence, there must be a > > > > mechanism to indicate this. > > > > > > No. It does not. At least, I cannot see this. Why do you think so? > > > > > > > - The words "conservative assumptions" are ambiguous. > > > > > > I agree. They should be changed. > > > > > > > - It implies the level of reliability may be higher than > > > required by > > > > collecting process - it is unclear to me why this is > implied by > > > > the consensus to allow the protocol to "MAY" support higher > > > > levels of reliability. > > > > > > Of course the level may be higher or lower than required by the > > > collecting process. It just says that the collecting > process needs > > > sufficient information on the reliability in order to find out > > > whether > > or not the > > > level is sufficient. > > > > > > > > > > > > > > > Therefore, may I propose the following alternative as a > > > replacement for the > > > > first paragraph in "6.3.2 Reliability": > > > > > > > > "The data exchange between the exporter and the collector MAY > > > > > > I'd suggest "data transfer from the exporting process to the > > > collecting process". > > > > > > > support different levels of reliability. > > > > > > > > For the most basic level of reliability, the > following should > > > > be maintained: > > > > - The collecting process MUST be able to detect > the level of > > > > reliability. > > > > - The collection process MUST be able to detect any > > > loss of data. > > > > > > > > For higher levels of reliability, the following should be > > > > > > Are these several higher levels or is it a single higher level > > > including everything below? > > > > > > > maintained: > > > > - All reliability properties requirements of lower > levels of > > > > reliability MUST be maintained. > > > > > > Above you say "the following should b maintained", within the > > > following you say "MUST". Is should x MUST = should? > > > > > > > - The exporter process SHOULD be able to communicate > > with more > > > > than one collection process. > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > - In case of failure the collection process, or in the > > > > connectivity between the exporter process and one > > collection > > > > process, transmission of data SHOULD be redirected, in a > > > > fail-over fashion, to a secondary collection process. > > > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > > > - In case of failover, data that has not been acknowledged > > > > SHOULD be retransmitted to the secondary > > collection process. > > > > > > Isn't this a solution rather than a requirement? > > > > > > > - The collection process MUST be able to eliminate > duplicate > > > > reporting of the same records emanating from the > fail over > > > > mechanism." > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in section "6.3.2": > > > > > > > > "The chosen method of data transfer MUST be extensible > > concerning > > > > reliability. It MUST be possible to increase reliability by > > > > extensions." > > > > > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > > after the second > > > > paragraph in 6.3.2. The main point on which I differ is > > > that your proposed > > > > wording implies that there must be an "ability to ... by > > > extensions" whereas > > > > I don't believe that is mandatory to meet the essence of > > > the requirements. > > > > If a protocol supports adequate levels of reliability, as > > > several of the > > > > currently evaluated protocols do, there may not be a need > > > for an extension > > > > > > Weren't among the people teaching us that there cannot be > > sufficient > > > reliability? What is sufficient depends on the > requirements of the > > > collecting process or the application processing the > > transfered data. > > > > > > > model. If, on the other hand, the protocol selected does > > > not have a reliable > > > > delivery mechanism, then a well-defined means to extend it > > > must be present. > > > > > > Some people said that without application level ACKs there is no > > > real reliability. Consequently, all you ask for above is not > > > reliable and would need to be > > > extensible. > > > > > > The main lesson I learned is that there are several levels of > > > reliability and that you cannot say something is reliable or not > > > without specifying > > > what you mean with "reliable". The only consequence is that > > > you have to > > > ask for every level, that it still is open for further > > > increasing reliability. > > > > > > > Therefore, may I suggest a slightly different wording than > > > the version you > > > > proposed: > > > > > > > > "If higher levels of reliability are not supported, > > there must be > > > > > > The term "higher levels" is only implicitly defined by your > > text above > > > and still ambiguous. How many levels need to be supported > such that > > > you need not to be extensible anymore? > > > > > > > a well-defined mechanism to extend the protocol to allow for > > > > increasing the reliability to support higher degrees of > > > > > > Is "degree" equivqalent to "level"? > > > > > > > reliability." > > > > > > > > > > > > > > > > I believe that even though the wording above may seem to > > hint at an > > > > implementation, in fact, it merely may state some lowest > > > common denominator > > > > features recurring in practically all existing reliable > > > delivery protocols. > > > > > > > > Best regards, > > > > > > > > Tal > > > > > > > > > > > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > > > ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 15 21:45:38 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18869 for ; Wed, 15 Jan 2003 21:45:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18Yzsz-0001IS-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jan 2003 20:36:05 -0600 Received: from pool-151-202-13-76.ny5030.east.verizon.net ([151.202.13.76] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18Yzsw-0001I6-00 for ipfix-req@net.doit.wisc.edu; Wed, 15 Jan 2003 20:36:02 -0600 Received: from SET (set [192.168.0.161]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0G2ZvO08625; Wed, 15 Jan 2003 21:35:57 -0500 Reply-To: From: "Carter Bullard" To: "'Tal Givoly'" Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 15 Jan 2003 21:35:34 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A50B@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC115@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Tal, My original mail was a reaction to Jeff suggesting that IPFIX would have retransmission capabilities to address some of his scenarios, which IMHO is not a given. The point I was making in my last email was that if you don't have negotiation, then you won't be able to turn on any type of extension, assuming of course that all versions of IPFIX are interoperable, which, IMHO, is a requirement. The complexity of supporting more than two levels of reliability without some form of negotiation seems to me to be a challenge. I would love to read about your approach!!!!!! Carter > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Wednesday, January 15, 2003 8:51 PM > To: Carter Bullard > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Carter, > > Quoting from the meeting minutes of the previous meeting: > > -- Dave Plonka wrote on 25 November 2002 10:30 -0600: > > The issue of reliability was discussed. Juergen proposed, > and it was > > agreed to by a hum, that the requirements document should > specify that > > the IPFIX protocol MAY have "aditional reliability" and > that it MUST > > be open to reliability extensions. Tal Givoly will supply > clarifying > > text about this higher level of reliability, describing it in an > > implementation independent way. > > Therefore, I do not imply TCP vs. UDP but rather the > "additional reliability" that we agreed the IPFIX protocol > MAY have and MUST be extensible enough to support. Therefore, > my understanding was that it was not tossed out - but rather > classified as MAY support but MUST be extensible enough to support. > > In order to demonstrate that it can be supported, I am > proposing the wording to qualify what that means from a > requirement standpoint. > > If you are referring to "negotiation" - that indeed is not > currently a requirement, nor have I claimed it should be in > any of these recent postings. > > I hope this helps clarify. > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard > Sent: Wednesday, January 15, 2003 4:51 PM > To: 'Tal Givoly' > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hey Tal, > Could that mean TCP vs UDP vs RTP vs multicast, or do you > mean IPFIX level reliability? If its IPFIX level, then > you're going to have to negotiate the optional reliability > features, and I thought that negotiation had been tossed out? > > Carter > > > > > -----Original Message----- > > From: Tal Givoly [mailto:givoly@xacct.com] > > Sent: Wednesday, January 15, 2003 7:45 PM > > To: Carter Bullard > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; > > 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Carter, > > > > Haven't we agreed that the protocol MAY support more reliable > > transports than merely being able to identify the fact that > loss has > > occurred? If that is the case, then we must allow for mechanisms by > > which the protocol can support them. Merely sequencing the > records and > > allowing identification of the amount of records lost supports the > > "must" requirements, but leaves no ability to support the "may" > > requirement in a cost-effective manner (e.g. out of band recovery). > > > > The minimum must requirements of being able to identify how > much data > > has been lost in a potentially unreliable delivery mechanism or for > > any other cause of loss will still be there, but for those > > applications requiring higher reliability, I believe it is > required to > > provide some additional description as part of the requirements. > > > > Tal > > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Wednesday, January 15, 2003 1:08 PM > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek'; 'Tal > > Givoly' > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hey Jeff, > > I agree that enumerating the various conditions is > > the correct thing, so I say great! > > > > On a different note, there is a huge difference > > between detecting/indicating loss of reliability > > and assuring a level of reliability. I am of the > > school that assuring reliability should be outside the > > scope of IPFIX. Even simple retransmission capabilities > > are not a potential solution as the principal target > > device for IPFIX is not going to be able to support > > the feature. > > > > But by providing the information needed to detect > > loss, such as through per record sequence numbering in conjunction > > with timestamping, an application will have all the info needed to > > enable out-of-band recovery. IPFIX could support recovery > itself if it > > could handle selective record transfer requests. > > > > Carter > > > > > > > > > > > -----Original Message----- > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On > > > Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) > > > Sent: Wednesday, January 15, 2003 3:12 PM > > > To: 'Juergen Quittek'; Tal Givoly > > > Cc: ipfix-req@net.doit.wisc.edu > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Hi, > > > > > > There seems to be agreement that losing flow information > > implies a > > > lack of reliability. I think understanding where this > information > > > loss might occur and what steps are taken to "recover" the lost > > > information is the essence of the different "levels of > reliability". > > > > > > > > > Today the requirements draft has the following statement > > in section > > > 6.3.2: > > > > > > > > > "Possible reasons for flow information loss include resource > > > shortage at the exporter, loss of packets between the > > > exporting process and collecting process, etc." > > > > > > > > > Rather than ending with "etc." it would be nice to try to > > enumerate > > > all the basic loss scenarios. I don't think there are > that many in > > > the model defined: > > > > > > > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > > > > > > > Moving from left to right across the model, I see > > > the following "failures" impacting reliability: > > > > > > 1. A metering process may somehow fail to "keep up" with > > > the packets going past the ObsPt. > > > > > > This lack of reliability is not recoverable by the > > > exporter (i.e. The same box won't be able to "see" > > > these flows again). It should be reported as covered > > > in section 5.1. > > > > > > 2. The exporter may be experiencing congestion and > > > not be able to buffer new flows recorded by the metering > > > process. > > > > > > This lack of reliability will again be unrecoverable > > > from the perspective of the exporting system. Either > > > old flows or newly reported flows need to be dropped. > > > Such loss should be reported. > > > > > > 3. A packet carrying a flow sent by the Exporter to the > > Collector > > > is dropped by the network. This is an issue for unreliable > > > transports such as UDP. For reliable transports, these > > > drops are recovered by the transport itself. > > > > > > This lack of reliability is only an issue for UDP based > > > protocols and MAY be addressed through some means, > > > such as buffering on the Exporter and an acknowledgement/ > > > timeout scheme. > > > > > > Having a "failover Collector" greatly increases the > > > likelihood that the Exporter will not exhaust buffering > > > before successfully retransmitting flow information. > > > > > > 4. The network connection between the Exporter and the > > > Collector is lost due to a failure (either in the network > > > or on the collector). > > > > > > The disposition of some flow information in transit may be > > > unknown to the Exporter. In addition subsequent flow > > > information is also at risk of being lost. > > > > > > This lack of reliability MAY be addressed by some > > > means such as buffering on the Exporter and having > > > a failover Collector(s) available. > > > > > > An application layer acknowledgement scheme aids > > > the exporter in identifying what information sent > > > has actually been received by the Collector. > > > > > > 5. The network connection between the Exporter and > > > the Collector is taken down for maintenance or other > > > administrative purposes. > > > > > > In this case it is desireable to gracefully transition > > > the delivery of flows from one Collector to an > > > auxilliary. > > > > > > Procedures for graceful handoff MAY be refined from > > > those for a simple failure (#4), to increase efficiency. > > > > > > 6. Congestion is detected between the Exporter and the > > > Collector, which jeopardizes the delivery of flow > > > information. The slow receiver/link problem. > > > > > > This may be considered either a basic failure of > > > the collector as in #4 above, or unavoidable as in > > > #2 above. > > > > > > > > > So to me, it seems like reliability boils down to whether > > > or not the protocol addresses 3, 4 and 5. > > > > > > I think the protocol MUST address 3, 4 and 5. However in > > > a deployment, there MAY only be one Collector set up. In > > > this case the reliable delivery is likely to be impacted > > > by failures 4 and 5 from time to time. > > > > > > That said, I don't see this as an extension, but really > > > a capability of the protocol. Or perhaps it is a property of > > > the exporter, i.e. are any flows ever buffered for > > > retransmission in the event of loss of the communication > > > channel between the exporter and collector. > > > > > > Perhaps an indication on the part of the exporter as to > > > whether it makes any attempt to retransmit to a secondary > > > should be called out. However I don't see lots of "levels" > > > of reliability. > > > > > > > > > Regards, > > > > > > Jeff Meyer > > > > > > > > > > -----Original Message----- > > > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > > To: Tal Givoly > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > Subject: RE: [ipfix-req] proposed changes for > > requirements document > > > > > > > > > > > > Hi Tal, > > > > > > > > Thank you for the comments. See my replies inline. > > > > > > > > Juergen > > > > > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > > > > > Juergen, > > > > > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. > Reliability": > > > > > > > > > > "Absence of reliability of the data transfer, for > > > > example caused by > > > > > loss or reordering of packets containing flow > > > > information, MUST be > > > > > indicated." > > > > > > > > > > by > > > > > > > > > > "Different levels of reliability of the data > transfer MAY be > > > > > supported. The collecting process MUST have sufficient > > > > information > > > > > for making a conservative assumption about the applied > > > > reliability > > > > > level. This means that the applied level of reliability > > > > MUST be as > > > > > high as or higher than indicated to the collecting > > process." > > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > > > the proposed > > > > > wording: > > > > > > > > > > - It implies that the collecting process must indicate > > the level > > > > > of reliability it is interested in, hence, there must be a > > > > > mechanism to indicate this. > > > > > > > > No. It does not. At least, I cannot see this. Why do > you think so? > > > > > > > > > - The words "conservative assumptions" are ambiguous. > > > > > > > > I agree. They should be changed. > > > > > > > > > - It implies the level of reliability may be higher than > > > > required by > > > > > collecting process - it is unclear to me why this is > > implied by > > > > > the consensus to allow the protocol to "MAY" support higher > > > > > levels of reliability. > > > > > > > > Of course the level may be higher or lower than required by the > > > > collecting process. It just says that the collecting > > process needs > > > > sufficient information on the reliability in order to find out > > > > whether > > > or not the > > > > level is sufficient. > > > > > > > > > > > > > > > > > > > Therefore, may I propose the following alternative as a > > > > replacement for the > > > > > first paragraph in "6.3.2 Reliability": > > > > > > > > > > "The data exchange between the exporter and the > collector MAY > > > > > > > > I'd suggest "data transfer from the exporting process to the > > > > collecting process". > > > > > > > > > support different levels of reliability. > > > > > > > > > > For the most basic level of reliability, the > > following should > > > > > be maintained: > > > > > - The collecting process MUST be able to detect > > the level of > > > > > reliability. > > > > > - The collection process MUST be able to detect any > > > > loss of data. > > > > > > > > > > For higher levels of reliability, the following should be > > > > > > > > Are these several higher levels or is it a single higher level > > > > including everything below? > > > > > > > > > maintained: > > > > > - All reliability properties requirements of lower > > levels of > > > > > reliability MUST be maintained. > > > > > > > > Above you say "the following should b maintained", within the > > > > following you say "MUST". Is should x MUST = should? > > > > > > > > > - The exporter process SHOULD be able to communicate > > > with more > > > > > than one collection process. > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > - In case of failure the collection process, or in the > > > > > connectivity between the exporter process and one > > > collection > > > > > process, transmission of data SHOULD be > redirected, in a > > > > > fail-over fashion, to a secondary collection process. > > > > > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > > > > > - In case of failover, data that has not been > acknowledged > > > > > SHOULD be retransmitted to the secondary > > > collection process. > > > > > > > > Isn't this a solution rather than a requirement? > > > > > > > > > - The collection process MUST be able to eliminate > > duplicate > > > > > reporting of the same records emanating from the > > fail over > > > > > mechanism." > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in > section "6.3.2": > > > > > > > > > > "The chosen method of data transfer MUST be extensible > > > concerning > > > > > reliability. It MUST be possible to increase > reliability by > > > > > extensions." > > > > > > > > > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > > > after the second > > > > > paragraph in 6.3.2. The main point on which I differ is > > > > that your proposed > > > > > wording implies that there must be an "ability to ... by > > > > extensions" whereas > > > > > I don't believe that is mandatory to meet the essence of > > > > the requirements. > > > > > If a protocol supports adequate levels of reliability, as > > > > several of the > > > > > currently evaluated protocols do, there may not be a need > > > > for an extension > > > > > > > > Weren't among the people teaching us that there cannot be > > > sufficient > > > > reliability? What is sufficient depends on the > > requirements of the > > > > collecting process or the application processing the > > > transfered data. > > > > > > > > > model. If, on the other hand, the protocol selected does > > > > not have a reliable > > > > > delivery mechanism, then a well-defined means to extend it > > > > must be present. > > > > > > > > Some people said that without application level ACKs > there is no > > > > real reliability. Consequently, all you ask for above is not > > > > reliable and would need to be extensible. > > > > > > > > The main lesson I learned is that there are several levels of > > > > reliability and that you cannot say something is > reliable or not > > > > without specifying what you mean with "reliable". The only > > > > consequence is that you have to > > > > ask for every level, that it still is open for further > > > > increasing reliability. > > > > > > > > > Therefore, may I suggest a slightly different wording than > > > > the version you > > > > > proposed: > > > > > > > > > > "If higher levels of reliability are not supported, > > > there must be > > > > > > > > The term "higher levels" is only implicitly defined by your > > > text above > > > > and still ambiguous. How many levels need to be supported > > such that > > > > you need not to be extensible anymore? > > > > > > > > > a well-defined mechanism to extend the protocol > to allow for > > > > > increasing the reliability to support higher degrees of > > > > > > > > Is "degree" equivqalent to "level"? > > > > > > > > > reliability." > > > > > > > > > > > > > > > > > > > > I believe that even though the wording above may seem to > > > hint at an > > > > > implementation, in fact, it merely may state some lowest > > > > common denominator > > > > > features recurring in practically all existing reliable > > > > delivery protocols. > > > > > > > > > > Best regards, > > > > > > > > > > Tal > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > > in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe > > > > ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > > > ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 16 09:05:01 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11352 for ; Thu, 16 Jan 2003 09:05:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZAQo-0002XV-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jan 2003 07:51:42 -0600 Received: from pool-151-202-13-76.ny5030.east.verizon.net ([151.202.13.76] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZAQm-0002XD-00 for ipfix-req@net.doit.wisc.edu; Thu, 16 Jan 2003 07:51:40 -0600 Received: from SET (set [192.168.0.161]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0GDpdO09559 for ; Thu, 16 Jan 2003 08:51:39 -0500 Reply-To: From: "Carter Bullard" To: Subject: [ipfix-req] does raqmon-pdu compete with ipfix? Date: Thu, 16 Jan 2003 08:51:19 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E7E8@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C2BD3C.73A4C1E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2BD3C.73A4C1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Gentle People, I believe that raqmon-pdu is indeed a direct competitor to IPFIX. Why not realize that raqmon is a form of flow data and have it use IPFIX? Carter -----Original Message----- From: rmonmib-admin@ietf.org [mailto:rmonmib-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, January 16, 2003 8:08 AM To: IETF-Announce: Cc: rmonmib@ietf.org Subject: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Network Monitoring Working Group of the IETF. Title : Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU) Author(s) : A. Siddiqui et al. Filename : draft-ietf-rmonmib-raqmon-pdu-00.txt Pages : 26 Date : 2003-1-15 This memo defines a common protocol data unit (PDU) used between RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report a QOS statistics using RTCP and SNMP as Transport Protocol. The original RAQMON draft [SIDDIQUI3] was split into 3 parts to identify the RAQMON Framework, RAQMON QOS PDU and RAQMON MIB. This memo defined RAQMON QOS Protocol Data Unit (PDU). This memo also outlines mechanisms to use Real Time Transport Control Protocol (RTCP) and Simple Network Management Protocol (SNMP) to transport these PDUs between RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) as outlined in RAQMON Charter of the RMON Workgroup. The memo [SIDDIQUI2] defines a Real-Time Application QOS Monitoring (RAQMON) Framework that extends the RMON Framework to allow Real-time Application QoS information as outlined by RAQMON Charter of the RMON Workgroup. The memo [SIDDIQUI1] defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB [RFC2819] to accommodate RAQMON solution. Distribution of this memo is unlimited. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmonmib-raqmon-pdu-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0000_01C2BD3C.73A4C1E0 Content-Type: Message/External-body; name="ATT00039.dat" Content-Disposition: attachment; filename="ATT00039.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-1-15142234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt ------=_NextPart_000_0000_01C2BD3C.73A4C1E0 Content-Type: Message/External-body; name="draft-ietf-rmonmib-raqmon-pdu-00.txt" Content-Disposition: attachment; filename="draft-ietf-rmonmib-raqmon-pdu-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-1-15142234.I-D@ietf.org> ------=_NextPart_000_0000_01C2BD3C.73A4C1E0-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 16 13:21:22 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18989 for ; Thu, 16 Jan 2003 13:21:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZEUd-0001hQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jan 2003 12:11:55 -0600 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZEUb-0001hK-00 for ipfix-req@net.doit.wisc.edu; Thu, 16 Jan 2003 12:11:53 -0600 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id BCDA28057F5; Thu, 16 Jan 2003 13:11:50 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 737411C009C8; Thu, 16 Jan 2003 13:11:47 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 16 Jan 2003 13:11:47 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F212D24B17@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'carter@qosient.com'" , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] does raqmon-pdu compete with ipfix? Date: Thu, 16 Jan 2003 13:11:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Carter, From the synopsis, it certainly sounds like Raqmon could simply use IPFIX. However, who is your question directed to? Have you had any dialog w/ A. Siddiqui et al.? Regards, Jeff Meyer > -----Original Message----- > From: Carter Bullard [mailto:carter@qosient.com] > Sent: Thursday, January 16, 2003 5:51 AM > To: ipfix-req@net.doit.wisc.edu > Subject: [ipfix-req] does raqmon-pdu compete with ipfix? > > > Gentle People, > I believe that raqmon-pdu is indeed a direct > competitor to IPFIX. Why not realize that raqmon > is a form of flow data and have it use IPFIX? > > Carter > > > -----Original Message----- > From: rmonmib-admin@ietf.org [mailto:rmonmib-admin@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, January 16, 2003 8:08 AM > To: IETF-Announce: > Cc: rmonmib@ietf.org > Subject: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Remote Network > Monitoring > Working Group of the IETF. > > Title : Real-time Application Quality of Service > Monitoring > (RAQMON) Protocol Data Unit (PDU) > Author(s) : A. Siddiqui et al. > Filename : draft-ietf-rmonmib-raqmon-pdu-00.txt > Pages : 26 > Date : 2003-1-15 > > This memo defines a common protocol data unit (PDU) used > between RAQMON > Data Source (RDS) and RAQMON Report Collector (RRC) to report a QOS > statistics using RTCP and SNMP as Transport Protocol. The original > RAQMON draft [SIDDIQUI3] was split into 3 parts to identify the RAQMON > Framework, RAQMON QOS PDU and RAQMON MIB. This memo defined RAQMON QOS > Protocol Data Unit (PDU). This memo also outlines mechanisms > to use Real > Time Transport Control Protocol > (RTCP) and Simple Network Management Protocol (SNMP) to > transport these > PDUs between RAQMON Data Source (RDS) and RAQMON Report > Collector (RRC) > as outlined in RAQMON Charter of the RMON Workgroup. The memo > [SIDDIQUI2] defines a Real-Time Application QOS Monitoring > (RAQMON) Framework that extends the RMON Framework to allow Real-time > Application QoS information as outlined by RAQMON Charter of the RMON > Workgroup. The memo [SIDDIQUI1] defines a portion of the Management > Information Base (MIB) for use with network management > protocols in the > Internet community. The document proposes an extension to the Remote > Monitoring MIB [RFC2819] to accommodate RAQMON solution. > Distribution of > this memo is unlimited. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon- pdu-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmonmib-raqmon-pdu-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 16 14:00:10 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20750 for ; Thu, 16 Jan 2003 14:00:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZF9j-0002dK-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jan 2003 12:54:23 -0600 Received: from pool-151-202-13-76.ny5030.east.verizon.net ([151.202.13.76] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZF9i-0002dC-00 for ipfix-req@net.doit.wisc.edu; Thu, 16 Jan 2003 12:54:22 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0GIsLO09864; Thu, 16 Jan 2003 13:54:21 -0500 From: "Carter Bullard" To: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , Subject: RE: [ipfix-req] does raqmon-pdu compete with ipfix? Date: Thu, 16 Jan 2003 13:54:12 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A50E@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC136@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Jeff, The question was to the whole IPFIX group, of course with the intention of trying to motivate someone to point it out to an AD, who is suppose to be paying attention to what's going on in their family of WG's to prevent duplicate efforts. Because RAQMON-PDU is in the RMON charter, its not just a, "here's an interesting draft, why not come on over to IPFIX and lets work together" kind of problem. If, of course, anyone ever recognizes it as a problem. IMHO this is definitely IPFIX killer technology. What I find interesting is that RAMON-PDU transport has no congestion awareness. Carter > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Thursday, January 16, 2003 1:12 PM > To: 'carter@qosient.com'; ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] does raqmon-pdu compete with ipfix? > > > Carter, > > From the synopsis, it certainly sounds like Raqmon could > simply use IPFIX. However, who is your question directed to? > > Have you had any dialog w/ A. Siddiqui et al.? > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Thursday, January 16, 2003 5:51 AM > > To: ipfix-req@net.doit.wisc.edu > > Subject: [ipfix-req] does raqmon-pdu compete with ipfix? > > > > > > Gentle People, > > I believe that raqmon-pdu is indeed a direct > > competitor to IPFIX. Why not realize that raqmon > > is a form of flow data and have it use IPFIX? > > > > Carter > > > > > > -----Original Message----- > > From: rmonmib-admin@ietf.org > [mailto:rmonmib-admin@ietf.org] On Behalf > > Of Internet-Drafts@ietf.org > > Sent: Thursday, January 16, 2003 8:08 AM > > To: IETF-Announce: > > Cc: rmonmib@ietf.org > > Subject: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Remote Network > > Monitoring > > Working Group of the IETF. > > > > Title : Real-time Application Quality of Service > > Monitoring > > (RAQMON) Protocol Data Unit (PDU) > > Author(s) : A. Siddiqui et al. > > Filename : draft-ietf-rmonmib-raqmon-pdu-00.txt > > Pages : 26 > > Date : 2003-1-15 > > > > This memo defines a common protocol data unit (PDU) used > > between RAQMON > > Data Source (RDS) and RAQMON Report Collector (RRC) to report a QOS > > statistics using RTCP and SNMP as Transport Protocol. The original > > RAQMON draft [SIDDIQUI3] was split into 3 parts to identify > the RAQMON > > Framework, RAQMON QOS PDU and RAQMON MIB. This memo defined > RAQMON QOS > > Protocol Data Unit (PDU). This memo also outlines mechanisms > > to use Real > > Time Transport Control Protocol > > (RTCP) and Simple Network Management Protocol (SNMP) to > > transport these > > PDUs between RAQMON Data Source (RDS) and RAQMON Report > > Collector (RRC) > > as outlined in RAQMON Charter of the RMON Workgroup. The memo > > [SIDDIQUI2] defines a Real-Time Application QOS Monitoring > > (RAQMON) Framework that extends the RMON Framework to allow > Real-time > > Application QoS information as outlined by RAQMON Charter > of the RMON > > Workgroup. The memo [SIDDIQUI1] defines a portion of the Management > > Information Base (MIB) for use with network management > > protocols in the > > Internet community. The document proposes an extension to the Remote > > Monitoring MIB [RFC2819] to accommodate RAQMON solution. > > Distribution of > > this memo is unlimited. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon- > pdu-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-rmonmib-raqmon-pdu-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 16 14:12:37 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21199 for ; Thu, 16 Jan 2003 14:12:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZFH4-0002rp-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jan 2003 13:01:58 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZFH0-0002rg-00 for ipfix-req@net.doit.wisc.edu; Thu, 16 Jan 2003 13:01:54 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0GJ6fq08740; Thu, 16 Jan 2003 11:06:41 -0800 From: "Tal Givoly" To: Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Thu, 16 Jan 2003 11:01:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A50B@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter, To best of my understanding, looking at the requirements, there is no requirement that all versions of IPFIX are interoperable. It may be a useful requirement. However, adding that requirement may introduce a derived requirement to support some form of negotiation. The rationale for not requiring negotiation originally included the fact that out of band configuration could be used to set up compatible/interoperable implementations for both exporter and collector. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard Sent: Wednesday, January 15, 2003 6:36 PM To: 'Tal Givoly' Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek' Subject: RE: [ipfix-req] proposed changes for requirements document Hey Tal, My original mail was a reaction to Jeff suggesting that IPFIX would have retransmission capabilities to address some of his scenarios, which IMHO is not a given. The point I was making in my last email was that if you don't have negotiation, then you won't be able to turn on any type of extension, assuming of course that all versions of IPFIX are interoperable, which, IMHO, is a requirement. The complexity of supporting more than two levels of reliability without some form of negotiation seems to me to be a challenge. I would love to read about your approach!!!!!! Carter > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Wednesday, January 15, 2003 8:51 PM > To: Carter Bullard > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Carter, > > Quoting from the meeting minutes of the previous meeting: > > -- Dave Plonka wrote on 25 November 2002 10:30 -0600: > > The issue of reliability was discussed. Juergen proposed, > and it was > > agreed to by a hum, that the requirements document should > specify that > > the IPFIX protocol MAY have "aditional reliability" and > that it MUST > > be open to reliability extensions. Tal Givoly will supply > clarifying > > text about this higher level of reliability, describing it in an > > implementation independent way. > > Therefore, I do not imply TCP vs. UDP but rather the > "additional reliability" that we agreed the IPFIX protocol > MAY have and MUST be extensible enough to support. Therefore, > my understanding was that it was not tossed out - but rather > classified as MAY support but MUST be extensible enough to support. > > In order to demonstrate that it can be supported, I am > proposing the wording to qualify what that means from a > requirement standpoint. > > If you are referring to "negotiation" - that indeed is not > currently a requirement, nor have I claimed it should be in > any of these recent postings. > > I hope this helps clarify. > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard > Sent: Wednesday, January 15, 2003 4:51 PM > To: 'Tal Givoly' > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hey Tal, > Could that mean TCP vs UDP vs RTP vs multicast, or do you > mean IPFIX level reliability? If its IPFIX level, then > you're going to have to negotiate the optional reliability > features, and I thought that negotiation had been tossed out? > > Carter > > > > > -----Original Message----- > > From: Tal Givoly [mailto:givoly@xacct.com] > > Sent: Wednesday, January 15, 2003 7:45 PM > > To: Carter Bullard > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; > > 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Carter, > > > > Haven't we agreed that the protocol MAY support more reliable > > transports than merely being able to identify the fact that > loss has > > occurred? If that is the case, then we must allow for mechanisms by > > which the protocol can support them. Merely sequencing the > records and > > allowing identification of the amount of records lost supports the > > "must" requirements, but leaves no ability to support the "may" > > requirement in a cost-effective manner (e.g. out of band recovery). > > > > The minimum must requirements of being able to identify how > much data > > has been lost in a potentially unreliable delivery mechanism or for > > any other cause of loss will still be there, but for those > > applications requiring higher reliability, I believe it is > required to > > provide some additional description as part of the requirements. > > > > Tal > > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Wednesday, January 15, 2003 1:08 PM > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek'; 'Tal > > Givoly' > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hey Jeff, > > I agree that enumerating the various conditions is > > the correct thing, so I say great! > > > > On a different note, there is a huge difference > > between detecting/indicating loss of reliability > > and assuring a level of reliability. I am of the > > school that assuring reliability should be outside the > > scope of IPFIX. Even simple retransmission capabilities > > are not a potential solution as the principal target > > device for IPFIX is not going to be able to support > > the feature. > > > > But by providing the information needed to detect > > loss, such as through per record sequence numbering in conjunction > > with timestamping, an application will have all the info needed to > > enable out-of-band recovery. IPFIX could support recovery > itself if it > > could handle selective record transfer requests. > > > > Carter > > > > > > > > > > > -----Original Message----- > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On > > > Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) > > > Sent: Wednesday, January 15, 2003 3:12 PM > > > To: 'Juergen Quittek'; Tal Givoly > > > Cc: ipfix-req@net.doit.wisc.edu > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Hi, > > > > > > There seems to be agreement that losing flow information > > implies a > > > lack of reliability. I think understanding where this > information > > > loss might occur and what steps are taken to "recover" the lost > > > information is the essence of the different "levels of > reliability". > > > > > > > > > Today the requirements draft has the following statement > > in section > > > 6.3.2: > > > > > > > > > "Possible reasons for flow information loss include resource > > > shortage at the exporter, loss of packets between the > > > exporting process and collecting process, etc." > > > > > > > > > Rather than ending with "etc." it would be nice to try to > > enumerate > > > all the basic loss scenarios. I don't think there are > that many in > > > the model defined: > > > > > > > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > > > > > > > Moving from left to right across the model, I see > > > the following "failures" impacting reliability: > > > > > > 1. A metering process may somehow fail to "keep up" with > > > the packets going past the ObsPt. > > > > > > This lack of reliability is not recoverable by the > > > exporter (i.e. The same box won't be able to "see" > > > these flows again). It should be reported as covered > > > in section 5.1. > > > > > > 2. The exporter may be experiencing congestion and > > > not be able to buffer new flows recorded by the metering > > > process. > > > > > > This lack of reliability will again be unrecoverable > > > from the perspective of the exporting system. Either > > > old flows or newly reported flows need to be dropped. > > > Such loss should be reported. > > > > > > 3. A packet carrying a flow sent by the Exporter to the > > Collector > > > is dropped by the network. This is an issue for unreliable > > > transports such as UDP. For reliable transports, these > > > drops are recovered by the transport itself. > > > > > > This lack of reliability is only an issue for UDP based > > > protocols and MAY be addressed through some means, > > > such as buffering on the Exporter and an acknowledgement/ > > > timeout scheme. > > > > > > Having a "failover Collector" greatly increases the > > > likelihood that the Exporter will not exhaust buffering > > > before successfully retransmitting flow information. > > > > > > 4. The network connection between the Exporter and the > > > Collector is lost due to a failure (either in the network > > > or on the collector). > > > > > > The disposition of some flow information in transit may be > > > unknown to the Exporter. In addition subsequent flow > > > information is also at risk of being lost. > > > > > > This lack of reliability MAY be addressed by some > > > means such as buffering on the Exporter and having > > > a failover Collector(s) available. > > > > > > An application layer acknowledgement scheme aids > > > the exporter in identifying what information sent > > > has actually been received by the Collector. > > > > > > 5. The network connection between the Exporter and > > > the Collector is taken down for maintenance or other > > > administrative purposes. > > > > > > In this case it is desireable to gracefully transition > > > the delivery of flows from one Collector to an > > > auxilliary. > > > > > > Procedures for graceful handoff MAY be refined from > > > those for a simple failure (#4), to increase efficiency. > > > > > > 6. Congestion is detected between the Exporter and the > > > Collector, which jeopardizes the delivery of flow > > > information. The slow receiver/link problem. > > > > > > This may be considered either a basic failure of > > > the collector as in #4 above, or unavoidable as in > > > #2 above. > > > > > > > > > So to me, it seems like reliability boils down to whether > > > or not the protocol addresses 3, 4 and 5. > > > > > > I think the protocol MUST address 3, 4 and 5. However in > > > a deployment, there MAY only be one Collector set up. In > > > this case the reliable delivery is likely to be impacted > > > by failures 4 and 5 from time to time. > > > > > > That said, I don't see this as an extension, but really > > > a capability of the protocol. Or perhaps it is a property of > > > the exporter, i.e. are any flows ever buffered for > > > retransmission in the event of loss of the communication > > > channel between the exporter and collector. > > > > > > Perhaps an indication on the part of the exporter as to > > > whether it makes any attempt to retransmit to a secondary > > > should be called out. However I don't see lots of "levels" > > > of reliability. > > > > > > > > > Regards, > > > > > > Jeff Meyer > > > > > > > > > > -----Original Message----- > > > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > > To: Tal Givoly > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > Subject: RE: [ipfix-req] proposed changes for > > requirements document > > > > > > > > > > > > Hi Tal, > > > > > > > > Thank you for the comments. See my replies inline. > > > > > > > > Juergen > > > > > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > > > > > Juergen, > > > > > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. > Reliability": > > > > > > > > > > "Absence of reliability of the data transfer, for > > > > example caused by > > > > > loss or reordering of packets containing flow > > > > information, MUST be > > > > > indicated." > > > > > > > > > > by > > > > > > > > > > "Different levels of reliability of the data > transfer MAY be > > > > > supported. The collecting process MUST have sufficient > > > > information > > > > > for making a conservative assumption about the applied > > > > reliability > > > > > level. This means that the applied level of reliability > > > > MUST be as > > > > > high as or higher than indicated to the collecting > > process." > > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > > > the proposed > > > > > wording: > > > > > > > > > > - It implies that the collecting process must indicate > > the level > > > > > of reliability it is interested in, hence, there must be a > > > > > mechanism to indicate this. > > > > > > > > No. It does not. At least, I cannot see this. Why do > you think so? > > > > > > > > > - The words "conservative assumptions" are ambiguous. > > > > > > > > I agree. They should be changed. > > > > > > > > > - It implies the level of reliability may be higher than > > > > required by > > > > > collecting process - it is unclear to me why this is > > implied by > > > > > the consensus to allow the protocol to "MAY" support higher > > > > > levels of reliability. > > > > > > > > Of course the level may be higher or lower than required by the > > > > collecting process. It just says that the collecting > > process needs > > > > sufficient information on the reliability in order to find out > > > > whether > > > or not the > > > > level is sufficient. > > > > > > > > > > > > > > > > > > > Therefore, may I propose the following alternative as a > > > > replacement for the > > > > > first paragraph in "6.3.2 Reliability": > > > > > > > > > > "The data exchange between the exporter and the > collector MAY > > > > > > > > I'd suggest "data transfer from the exporting process to the > > > > collecting process". > > > > > > > > > support different levels of reliability. > > > > > > > > > > For the most basic level of reliability, the > > following should > > > > > be maintained: > > > > > - The collecting process MUST be able to detect > > the level of > > > > > reliability. > > > > > - The collection process MUST be able to detect any > > > > loss of data. > > > > > > > > > > For higher levels of reliability, the following should be > > > > > > > > Are these several higher levels or is it a single higher level > > > > including everything below? > > > > > > > > > maintained: > > > > > - All reliability properties requirements of lower > > levels of > > > > > reliability MUST be maintained. > > > > > > > > Above you say "the following should b maintained", within the > > > > following you say "MUST". Is should x MUST = should? > > > > > > > > > - The exporter process SHOULD be able to communicate > > > with more > > > > > than one collection process. > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > - In case of failure the collection process, or in the > > > > > connectivity between the exporter process and one > > > collection > > > > > process, transmission of data SHOULD be > redirected, in a > > > > > fail-over fashion, to a secondary collection process. > > > > > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > > > > > - In case of failover, data that has not been > acknowledged > > > > > SHOULD be retransmitted to the secondary > > > collection process. > > > > > > > > Isn't this a solution rather than a requirement? > > > > > > > > > - The collection process MUST be able to eliminate > > duplicate > > > > > reporting of the same records emanating from the > > fail over > > > > > mechanism." > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in > section "6.3.2": > > > > > > > > > > "The chosen method of data transfer MUST be extensible > > > concerning > > > > > reliability. It MUST be possible to increase > reliability by > > > > > extensions." > > > > > > > > > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > > > after the second > > > > > paragraph in 6.3.2. The main point on which I differ is > > > > that your proposed > > > > > wording implies that there must be an "ability to ... by > > > > extensions" whereas > > > > > I don't believe that is mandatory to meet the essence of > > > > the requirements. > > > > > If a protocol supports adequate levels of reliability, as > > > > several of the > > > > > currently evaluated protocols do, there may not be a need > > > > for an extension > > > > > > > > Weren't among the people teaching us that there cannot be > > > sufficient > > > > reliability? What is sufficient depends on the > > requirements of the > > > > collecting process or the application processing the > > > transfered data. > > > > > > > > > model. If, on the other hand, the protocol selected does > > > > not have a reliable > > > > > delivery mechanism, then a well-defined means to extend it > > > > must be present. > > > > > > > > Some people said that without application level ACKs > there is no > > > > real reliability. Consequently, all you ask for above is not > > > > reliable and would need to be extensible. > > > > > > > > The main lesson I learned is that there are several levels of > > > > reliability and that you cannot say something is > reliable or not > > > > without specifying what you mean with "reliable". The only > > > > consequence is that you have to > > > > ask for every level, that it still is open for further > > > > increasing reliability. > > > > > > > > > Therefore, may I suggest a slightly different wording than > > > > the version you > > > > > proposed: > > > > > > > > > > "If higher levels of reliability are not supported, > > > there must be > > > > > > > > The term "higher levels" is only implicitly defined by your > > > text above > > > > and still ambiguous. How many levels need to be supported > > such that > > > > you need not to be extensible anymore? > > > > > > > > > a well-defined mechanism to extend the protocol > to allow for > > > > > increasing the reliability to support higher degrees of > > > > > > > > Is "degree" equivqalent to "level"? > > > > > > > > > reliability." > > > > > > > > > > > > > > > > > > > > I believe that even though the wording above may seem to > > > hint at an > > > > > implementation, in fact, it merely may state some lowest > > > > common denominator > > > > > features recurring in practically all existing reliable > > > > delivery protocols. > > > > > > > > > > Best regards, > > > > > > > > > > Tal > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > > in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe > > > > ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > > > ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 16 14:49:22 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22047 for ; Thu, 16 Jan 2003 14:49:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZFtQ-0003hU-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jan 2003 13:41:36 -0600 Received: from pool-151-202-13-76.ny5030.east.verizon.net ([151.202.13.76] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZFtO-0003hM-00 for ipfix-req@net.doit.wisc.edu; Thu, 16 Jan 2003 13:41:34 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0GJfUO09927; Thu, 16 Jan 2003 14:41:30 -0500 From: "Carter Bullard" To: "'Tal Givoly'" Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Thu, 16 Jan 2003 14:41:21 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A510@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC13B@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Tal, Out of band management is an approach, but not a very reliable or practical approach. Nice if you have only one data collector, but if there are more than one, which I assume that there will be, then SNMP style configuration will be woefully lacking. I'm a major fan of template based negotiation, so if you end up with something regarding this in your contribution, it would make my day. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tal Givoly > Sent: Thursday, January 16, 2003 2:02 PM > To: carter@qosient.com > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Carter, > > To best of my understanding, looking at the requirements, there is no > requirement that all versions of IPFIX are interoperable. It > may be a useful > requirement. However, adding that requirement may introduce a derived > requirement to support some form of negotiation. The rationale for not > requiring negotiation originally included the fact that out of band > configuration could be used to set up compatible/interoperable > implementations for both exporter and collector. > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: Wednesday, January 15, 2003 6:36 PM > To: 'Tal Givoly' > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hey Tal, > My original mail was a reaction to Jeff suggesting > that IPFIX would have retransmission capabilities to > address some of his scenarios, which IMHO is not a given. > > The point I was making in my last email was that if > you don't have negotiation, then you won't be able to > turn on any type of extension, assuming of course that > all versions of IPFIX are interoperable, which, IMHO, > is a requirement. > > The complexity of supporting more than two levels of > reliability without some form of negotiation seems to > me to be a challenge. I would love to read about your > approach!!!!!! > > Carter > > > > -----Original Message----- > > From: Tal Givoly [mailto:givoly@xacct.com] > > Sent: Wednesday, January 15, 2003 8:51 PM > > To: Carter Bullard > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Carter, > > > > Quoting from the meeting minutes of the previous meeting: > > > > -- Dave Plonka wrote on 25 November 2002 10:30 -0600: > > > The issue of reliability was discussed. Juergen proposed, > > and it was > > > agreed to by a hum, that the requirements document should > > specify that > > > the IPFIX protocol MAY have "aditional reliability" and > > that it MUST > > > be open to reliability extensions. Tal Givoly will supply > > clarifying > > > text about this higher level of reliability, describing it in an > > > implementation independent way. > > > > Therefore, I do not imply TCP vs. UDP but rather the > > "additional reliability" that we agreed the IPFIX protocol > > MAY have and MUST be extensible enough to support. Therefore, > > my understanding was that it was not tossed out - but rather > > classified as MAY support but MUST be extensible enough to support. > > > > In order to demonstrate that it can be supported, I am > > proposing the wording to qualify what that means from a > > requirement standpoint. > > > > If you are referring to "negotiation" - that indeed is not > > currently a requirement, nor have I claimed it should be in > > any of these recent postings. > > > > I hope this helps clarify. > > > > Tal > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard > > Sent: Wednesday, January 15, 2003 4:51 PM > > To: 'Tal Givoly' > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hey Tal, > > Could that mean TCP vs UDP vs RTP vs multicast, or do you > > mean IPFIX level reliability? If its IPFIX level, then > > you're going to have to negotiate the optional reliability > > features, and I thought that negotiation had been tossed out? > > > > Carter > > > > > > > > > -----Original Message----- > > > From: Tal Givoly [mailto:givoly@xacct.com] > > > Sent: Wednesday, January 15, 2003 7:45 PM > > > To: Carter Bullard > > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; > > > 'Juergen Quittek' > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Carter, > > > > > > Haven't we agreed that the protocol MAY support more reliable > > > transports than merely being able to identify the fact that > > loss has > > > occurred? If that is the case, then we must allow for > mechanisms by > > > which the protocol can support them. Merely sequencing the > > records and > > > allowing identification of the amount of records lost supports the > > > "must" requirements, but leaves no ability to support the "may" > > > requirement in a cost-effective manner (e.g. out of band > recovery). > > > > > > The minimum must requirements of being able to identify how > > much data > > > has been lost in a potentially unreliable delivery > mechanism or for > > > any other cause of loss will still be there, but for those > > > applications requiring higher reliability, I believe it is > > required to > > > provide some additional description as part of the requirements. > > > > > > Tal > > > > > > -----Original Message----- > > > From: Carter Bullard [mailto:carter@qosient.com] > > > Sent: Wednesday, January 15, 2003 1:08 PM > > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek'; 'Tal > > > Givoly' > > > Cc: ipfix-req@net.doit.wisc.edu > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Hey Jeff, > > > I agree that enumerating the various conditions is > > > the correct thing, so I say great! > > > > > > On a different note, there is a huge difference > > > between detecting/indicating loss of reliability > > > and assuring a level of reliability. I am of the > > > school that assuring reliability should be outside the > > > scope of IPFIX. Even simple retransmission capabilities > > > are not a potential solution as the principal target > > > device for IPFIX is not going to be able to support > > > the feature. > > > > > > But by providing the information needed to detect > > > loss, such as through per record sequence numbering in conjunction > > > with timestamping, an application will have all the info needed to > > > enable out-of-band recovery. IPFIX could support recovery > > itself if it > > > could handle selective record transfer requests. > > > > > > Carter > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On > > > > Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) > > > > Sent: Wednesday, January 15, 2003 3:12 PM > > > > To: 'Juergen Quittek'; Tal Givoly > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > Subject: RE: [ipfix-req] proposed changes for > > requirements document > > > > > > > > > > > > Hi, > > > > > > > > There seems to be agreement that losing flow information > > > implies a > > > > lack of reliability. I think understanding where this > > information > > > > loss might occur and what steps are taken to "recover" the lost > > > > information is the essence of the different "levels of > > reliability". > > > > > > > > > > > > Today the requirements draft has the following statement > > > in section > > > > 6.3.2: > > > > > > > > > > > > "Possible reasons for flow information loss include resource > > > > shortage at the exporter, loss of packets between the > > > > exporting process and collecting process, etc." > > > > > > > > > > > > Rather than ending with "etc." it would be nice to try to > > > enumerate > > > > all the basic loss scenarios. I don't think there are > > that many in > > > > the model defined: > > > > > > > > > > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > > > > > > > > > > Moving from left to right across the model, I see > > > > the following "failures" impacting reliability: > > > > > > > > 1. A metering process may somehow fail to "keep up" with > > > > the packets going past the ObsPt. > > > > > > > > This lack of reliability is not recoverable by the > > > > exporter (i.e. The same box won't be able to "see" > > > > these flows again). It should be reported as covered > > > > in section 5.1. > > > > > > > > 2. The exporter may be experiencing congestion and > > > > not be able to buffer new flows recorded by the metering > > > > process. > > > > > > > > This lack of reliability will again be unrecoverable > > > > from the perspective of the exporting system. Either > > > > old flows or newly reported flows need to be dropped. > > > > Such loss should be reported. > > > > > > > > 3. A packet carrying a flow sent by the Exporter to the > > > Collector > > > > is dropped by the network. This is an issue for > unreliable > > > > transports such as UDP. For reliable transports, these > > > > drops are recovered by the transport itself. > > > > > > > > This lack of reliability is only an issue for UDP based > > > > protocols and MAY be addressed through some means, > > > > such as buffering on the Exporter and an acknowledgement/ > > > > timeout scheme. > > > > > > > > Having a "failover Collector" greatly increases the > > > > likelihood that the Exporter will not exhaust buffering > > > > before successfully retransmitting flow information. > > > > > > > > 4. The network connection between the Exporter and the > > > > Collector is lost due to a failure (either in the network > > > > or on the collector). > > > > > > > > The disposition of some flow information in transit may be > > > > unknown to the Exporter. In addition subsequent flow > > > > information is also at risk of being lost. > > > > > > > > This lack of reliability MAY be addressed by some > > > > means such as buffering on the Exporter and having > > > > a failover Collector(s) available. > > > > > > > > An application layer acknowledgement scheme aids > > > > the exporter in identifying what information sent > > > > has actually been received by the Collector. > > > > > > > > 5. The network connection between the Exporter and > > > > the Collector is taken down for maintenance or other > > > > administrative purposes. > > > > > > > > In this case it is desireable to gracefully transition > > > > the delivery of flows from one Collector to an > > > > auxilliary. > > > > > > > > Procedures for graceful handoff MAY be refined from > > > > those for a simple failure (#4), to increase efficiency. > > > > > > > > 6. Congestion is detected between the Exporter and the > > > > Collector, which jeopardizes the delivery of flow > > > > information. The slow receiver/link problem. > > > > > > > > This may be considered either a basic failure of > > > > the collector as in #4 above, or unavoidable as in > > > > #2 above. > > > > > > > > > > > > So to me, it seems like reliability boils down to whether > > > > or not the protocol addresses 3, 4 and 5. > > > > > > > > I think the protocol MUST address 3, 4 and 5. However in > > > > a deployment, there MAY only be one Collector set up. In > > > > this case the reliable delivery is likely to be impacted > > > > by failures 4 and 5 from time to time. > > > > > > > > That said, I don't see this as an extension, but really > > > > a capability of the protocol. Or perhaps it is a property of > > > > the exporter, i.e. are any flows ever buffered for > > > > retransmission in the event of loss of the communication > > > > channel between the exporter and collector. > > > > > > > > Perhaps an indication on the part of the exporter as to > > > > whether it makes any attempt to retransmit to a secondary > > > > should be called out. However I don't see lots of "levels" > > > > of reliability. > > > > > > > > > > > > Regards, > > > > > > > > Jeff Meyer > > > > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > > > To: Tal Givoly > > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > > Subject: RE: [ipfix-req] proposed changes for > > > requirements document > > > > > > > > > > > > > > > Hi Tal, > > > > > > > > > > Thank you for the comments. See my replies inline. > > > > > > > > > > Juergen > > > > > > > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > > > > > > > Juergen, > > > > > > > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. > > Reliability": > > > > > > > > > > > > "Absence of reliability of the data transfer, for > > > > > example caused by > > > > > > loss or reordering of packets containing flow > > > > > information, MUST be > > > > > > indicated." > > > > > > > > > > > > by > > > > > > > > > > > > "Different levels of reliability of the data > > transfer MAY be > > > > > > supported. The collecting process MUST have sufficient > > > > > information > > > > > > for making a conservative assumption about the applied > > > > > reliability > > > > > > level. This means that the applied level of reliability > > > > > MUST be as > > > > > > high as or higher than indicated to the collecting > > > process." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > > > > the proposed > > > > > > wording: > > > > > > > > > > > > - It implies that the collecting process must indicate > > > the level > > > > > > of reliability it is interested in, hence, there > must be a > > > > > > mechanism to indicate this. > > > > > > > > > > No. It does not. At least, I cannot see this. Why do > > you think so? > > > > > > > > > > > - The words "conservative assumptions" are ambiguous. > > > > > > > > > > I agree. They should be changed. > > > > > > > > > > > - It implies the level of reliability may be higher than > > > > > required by > > > > > > collecting process - it is unclear to me why this is > > > implied by > > > > > > the consensus to allow the protocol to "MAY" > support higher > > > > > > levels of reliability. > > > > > > > > > > Of course the level may be higher or lower than > required by the > > > > > collecting process. It just says that the collecting > > > process needs > > > > > sufficient information on the reliability in order to find out > > > > > whether > > > > or not the > > > > > level is sufficient. > > > > > > > > > > > > > > > > > > > > > > > Therefore, may I propose the following alternative as a > > > > > replacement for the > > > > > > first paragraph in "6.3.2 Reliability": > > > > > > > > > > > > "The data exchange between the exporter and the > > collector MAY > > > > > > > > > > I'd suggest "data transfer from the exporting process to the > > > > > collecting process". > > > > > > > > > > > support different levels of reliability. > > > > > > > > > > > > For the most basic level of reliability, the > > > following should > > > > > > be maintained: > > > > > > - The collecting process MUST be able to detect > > > the level of > > > > > > reliability. > > > > > > - The collection process MUST be able to detect any > > > > > loss of data. > > > > > > > > > > > > For higher levels of reliability, the following > should be > > > > > > > > > > Are these several higher levels or is it a single higher level > > > > > including everything below? > > > > > > > > > > > maintained: > > > > > > - All reliability properties requirements of lower > > > levels of > > > > > > reliability MUST be maintained. > > > > > > > > > > Above you say "the following should b maintained", within the > > > > > following you say "MUST". Is should x MUST = should? > > > > > > > > > > > - The exporter process SHOULD be able to communicate > > > > with more > > > > > > than one collection process. > > > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > - In case of failure the collection process, or in the > > > > > > connectivity between the exporter process and one > > > > collection > > > > > > process, transmission of data SHOULD be > > redirected, in a > > > > > > fail-over fashion, to a secondary collection process. > > > > > > > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > > > > > > > - In case of failover, data that has not been > > acknowledged > > > > > > SHOULD be retransmitted to the secondary > > > > collection process. > > > > > > > > > > Isn't this a solution rather than a requirement? > > > > > > > > > > > - The collection process MUST be able to eliminate > > > duplicate > > > > > > reporting of the same records emanating from the > > > fail over > > > > > > mechanism." > > > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in > > section "6.3.2": > > > > > > > > > > > > "The chosen method of data transfer MUST be extensible > > > > concerning > > > > > > reliability. It MUST be possible to increase > > reliability by > > > > > > extensions." > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > > > > after the second > > > > > > paragraph in 6.3.2. The main point on which I differ is > > > > > that your proposed > > > > > > wording implies that there must be an "ability to ... by > > > > > extensions" whereas > > > > > > I don't believe that is mandatory to meet the essence of > > > > > the requirements. > > > > > > If a protocol supports adequate levels of reliability, as > > > > > several of the > > > > > > currently evaluated protocols do, there may not be a need > > > > > for an extension > > > > > > > > > > Weren't among the people teaching us that there cannot be > > > > sufficient > > > > > reliability? What is sufficient depends on the > > > requirements of the > > > > > collecting process or the application processing the > > > > transfered data. > > > > > > > > > > > model. If, on the other hand, the protocol selected does > > > > > not have a reliable > > > > > > delivery mechanism, then a well-defined means to extend it > > > > > must be present. > > > > > > > > > > Some people said that without application level ACKs > > there is no > > > > > real reliability. Consequently, all you ask for above is not > > > > > reliable and would need to be extensible. > > > > > > > > > > The main lesson I learned is that there are several levels of > > > > > reliability and that you cannot say something is > > reliable or not > > > > > without specifying what you mean with "reliable". The only > > > > > consequence is that you have to > > > > > ask for every level, that it still is open for further > > > > > increasing reliability. > > > > > > > > > > > Therefore, may I suggest a slightly different wording than > > > > > the version you > > > > > > proposed: > > > > > > > > > > > > "If higher levels of reliability are not supported, > > > > there must be > > > > > > > > > > The term "higher levels" is only implicitly defined by your > > > > text above > > > > > and still ambiguous. How many levels need to be supported > > > such that > > > > > you need not to be extensible anymore? > > > > > > > > > > > a well-defined mechanism to extend the protocol > > to allow for > > > > > > increasing the reliability to support higher degrees of > > > > > > > > > > Is "degree" equivqalent to "level"? > > > > > > > > > > > reliability." > > > > > > > > > > > > > > > > > > > > > > > > I believe that even though the wording above may seem to > > > > hint at an > > > > > > implementation, in fact, it merely may state some lowest > > > > > common denominator > > > > > > features recurring in practically all existing reliable > > > > > delivery protocols. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Tal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > > > in message body > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe > > > > > ipfix" in message body > > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > > in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe > > > > ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message > > body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 16 15:43:48 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23407 for ; Thu, 16 Jan 2003 15:43:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZGly-00050g-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jan 2003 14:37:58 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZGlv-00050S-00 for ipfix-req@net.doit.wisc.edu; Thu, 16 Jan 2003 14:37:55 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0GKbIq10193; Thu, 16 Jan 2003 12:37:18 -0800 From: "Tal Givoly" To: "Carter Bullard" Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Thu, 16 Jan 2003 12:32:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A510@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter, I'm the first to support your position here (i.e. that out of band management is not very reliable or practical). In fact, it is one of the unique features in CRANE relative to all other candidate protocols that have been evaluated. Whereas other protocols rely on out of band communication to agree on operational parameters, CRANE negotiates the protocol version, the transport and the templates with multiple collection processes - much like Fax and Modem capability negotiation. For more information, you are welcome to read the CRANE specification. If you need further information regarding how this takes place, it could also be provided. Tal -----Original Message----- From: Carter Bullard [mailto:carter@qosient.com] Sent: Thursday, January 16, 2003 11:41 AM To: 'Tal Givoly' Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek' Subject: RE: [ipfix-req] proposed changes for requirements document Hey Tal, Out of band management is an approach, but not a very reliable or practical approach. Nice if you have only one data collector, but if there are more than one, which I assume that there will be, then SNMP style configuration will be woefully lacking. I'm a major fan of template based negotiation, so if you end up with something regarding this in your contribution, it would make my day. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tal Givoly > Sent: Thursday, January 16, 2003 2:02 PM > To: carter@qosient.com > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Carter, > > To best of my understanding, looking at the requirements, there is no > requirement that all versions of IPFIX are interoperable. It > may be a useful > requirement. However, adding that requirement may introduce a derived > requirement to support some form of negotiation. The rationale for not > requiring negotiation originally included the fact that out of band > configuration could be used to set up compatible/interoperable > implementations for both exporter and collector. > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: Wednesday, January 15, 2003 6:36 PM > To: 'Tal Givoly' > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hey Tal, > My original mail was a reaction to Jeff suggesting > that IPFIX would have retransmission capabilities to > address some of his scenarios, which IMHO is not a given. > > The point I was making in my last email was that if > you don't have negotiation, then you won't be able to > turn on any type of extension, assuming of course that > all versions of IPFIX are interoperable, which, IMHO, > is a requirement. > > The complexity of supporting more than two levels of > reliability without some form of negotiation seems to > me to be a challenge. I would love to read about your > approach!!!!!! > > Carter > > > > -----Original Message----- > > From: Tal Givoly [mailto:givoly@xacct.com] > > Sent: Wednesday, January 15, 2003 8:51 PM > > To: Carter Bullard > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Carter, > > > > Quoting from the meeting minutes of the previous meeting: > > > > -- Dave Plonka wrote on 25 November 2002 10:30 -0600: > > > The issue of reliability was discussed. Juergen proposed, > > and it was > > > agreed to by a hum, that the requirements document should > > specify that > > > the IPFIX protocol MAY have "aditional reliability" and > > that it MUST > > > be open to reliability extensions. Tal Givoly will supply > > clarifying > > > text about this higher level of reliability, describing it in an > > > implementation independent way. > > > > Therefore, I do not imply TCP vs. UDP but rather the > > "additional reliability" that we agreed the IPFIX protocol > > MAY have and MUST be extensible enough to support. Therefore, > > my understanding was that it was not tossed out - but rather > > classified as MAY support but MUST be extensible enough to support. > > > > In order to demonstrate that it can be supported, I am > > proposing the wording to qualify what that means from a > > requirement standpoint. > > > > If you are referring to "negotiation" - that indeed is not > > currently a requirement, nor have I claimed it should be in > > any of these recent postings. > > > > I hope this helps clarify. > > > > Tal > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard > > Sent: Wednesday, January 15, 2003 4:51 PM > > To: 'Tal Givoly' > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hey Tal, > > Could that mean TCP vs UDP vs RTP vs multicast, or do you > > mean IPFIX level reliability? If its IPFIX level, then > > you're going to have to negotiate the optional reliability > > features, and I thought that negotiation had been tossed out? > > > > Carter > > > > > > > > > -----Original Message----- > > > From: Tal Givoly [mailto:givoly@xacct.com] > > > Sent: Wednesday, January 15, 2003 7:45 PM > > > To: Carter Bullard > > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; > > > 'Juergen Quittek' > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Carter, > > > > > > Haven't we agreed that the protocol MAY support more reliable > > > transports than merely being able to identify the fact that > > loss has > > > occurred? If that is the case, then we must allow for > mechanisms by > > > which the protocol can support them. Merely sequencing the > > records and > > > allowing identification of the amount of records lost supports the > > > "must" requirements, but leaves no ability to support the "may" > > > requirement in a cost-effective manner (e.g. out of band > recovery). > > > > > > The minimum must requirements of being able to identify how > > much data > > > has been lost in a potentially unreliable delivery > mechanism or for > > > any other cause of loss will still be there, but for those > > > applications requiring higher reliability, I believe it is > > required to > > > provide some additional description as part of the requirements. > > > > > > Tal > > > > > > -----Original Message----- > > > From: Carter Bullard [mailto:carter@qosient.com] > > > Sent: Wednesday, January 15, 2003 1:08 PM > > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen Quittek'; 'Tal > > > Givoly' > > > Cc: ipfix-req@net.doit.wisc.edu > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Hey Jeff, > > > I agree that enumerating the various conditions is > > > the correct thing, so I say great! > > > > > > On a different note, there is a huge difference > > > between detecting/indicating loss of reliability > > > and assuring a level of reliability. I am of the > > > school that assuring reliability should be outside the > > > scope of IPFIX. Even simple retransmission capabilities > > > are not a potential solution as the principal target > > > device for IPFIX is not going to be able to support > > > the feature. > > > > > > But by providing the information needed to detect > > > loss, such as through per record sequence numbering in conjunction > > > with timestamping, an application will have all the info needed to > > > enable out-of-band recovery. IPFIX could support recovery > > itself if it > > > could handle selective record transfer requests. > > > > > > Carter > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On > > > > Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) > > > > Sent: Wednesday, January 15, 2003 3:12 PM > > > > To: 'Juergen Quittek'; Tal Givoly > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > Subject: RE: [ipfix-req] proposed changes for > > requirements document > > > > > > > > > > > > Hi, > > > > > > > > There seems to be agreement that losing flow information > > > implies a > > > > lack of reliability. I think understanding where this > > information > > > > loss might occur and what steps are taken to "recover" the lost > > > > information is the essence of the different "levels of > > reliability". > > > > > > > > > > > > Today the requirements draft has the following statement > > > in section > > > > 6.3.2: > > > > > > > > > > > > "Possible reasons for flow information loss include resource > > > > shortage at the exporter, loss of packets between the > > > > exporting process and collecting process, etc." > > > > > > > > > > > > Rather than ending with "etc." it would be nice to try to > > > enumerate > > > > all the basic loss scenarios. I don't think there are > > that many in > > > > the model defined: > > > > > > > > > > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > > > > > > > > > > Moving from left to right across the model, I see > > > > the following "failures" impacting reliability: > > > > > > > > 1. A metering process may somehow fail to "keep up" with > > > > the packets going past the ObsPt. > > > > > > > > This lack of reliability is not recoverable by the > > > > exporter (i.e. The same box won't be able to "see" > > > > these flows again). It should be reported as covered > > > > in section 5.1. > > > > > > > > 2. The exporter may be experiencing congestion and > > > > not be able to buffer new flows recorded by the metering > > > > process. > > > > > > > > This lack of reliability will again be unrecoverable > > > > from the perspective of the exporting system. Either > > > > old flows or newly reported flows need to be dropped. > > > > Such loss should be reported. > > > > > > > > 3. A packet carrying a flow sent by the Exporter to the > > > Collector > > > > is dropped by the network. This is an issue for > unreliable > > > > transports such as UDP. For reliable transports, these > > > > drops are recovered by the transport itself. > > > > > > > > This lack of reliability is only an issue for UDP based > > > > protocols and MAY be addressed through some means, > > > > such as buffering on the Exporter and an acknowledgement/ > > > > timeout scheme. > > > > > > > > Having a "failover Collector" greatly increases the > > > > likelihood that the Exporter will not exhaust buffering > > > > before successfully retransmitting flow information. > > > > > > > > 4. The network connection between the Exporter and the > > > > Collector is lost due to a failure (either in the network > > > > or on the collector). > > > > > > > > The disposition of some flow information in transit may be > > > > unknown to the Exporter. In addition subsequent flow > > > > information is also at risk of being lost. > > > > > > > > This lack of reliability MAY be addressed by some > > > > means such as buffering on the Exporter and having > > > > a failover Collector(s) available. > > > > > > > > An application layer acknowledgement scheme aids > > > > the exporter in identifying what information sent > > > > has actually been received by the Collector. > > > > > > > > 5. The network connection between the Exporter and > > > > the Collector is taken down for maintenance or other > > > > administrative purposes. > > > > > > > > In this case it is desireable to gracefully transition > > > > the delivery of flows from one Collector to an > > > > auxilliary. > > > > > > > > Procedures for graceful handoff MAY be refined from > > > > those for a simple failure (#4), to increase efficiency. > > > > > > > > 6. Congestion is detected between the Exporter and the > > > > Collector, which jeopardizes the delivery of flow > > > > information. The slow receiver/link problem. > > > > > > > > This may be considered either a basic failure of > > > > the collector as in #4 above, or unavoidable as in > > > > #2 above. > > > > > > > > > > > > So to me, it seems like reliability boils down to whether > > > > or not the protocol addresses 3, 4 and 5. > > > > > > > > I think the protocol MUST address 3, 4 and 5. However in > > > > a deployment, there MAY only be one Collector set up. In > > > > this case the reliable delivery is likely to be impacted > > > > by failures 4 and 5 from time to time. > > > > > > > > That said, I don't see this as an extension, but really > > > > a capability of the protocol. Or perhaps it is a property of > > > > the exporter, i.e. are any flows ever buffered for > > > > retransmission in the event of loss of the communication > > > > channel between the exporter and collector. > > > > > > > > Perhaps an indication on the part of the exporter as to > > > > whether it makes any attempt to retransmit to a secondary > > > > should be called out. However I don't see lots of "levels" > > > > of reliability. > > > > > > > > > > > > Regards, > > > > > > > > Jeff Meyer > > > > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > > > To: Tal Givoly > > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > > Subject: RE: [ipfix-req] proposed changes for > > > requirements document > > > > > > > > > > > > > > > Hi Tal, > > > > > > > > > > Thank you for the comments. See my replies inline. > > > > > > > > > > Juergen > > > > > > > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > > > > > > > Juergen, > > > > > > > > > > > > Some recommendation of modification to the proposed changes: > > > > > > > > > > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. > > Reliability": > > > > > > > > > > > > "Absence of reliability of the data transfer, for > > > > > example caused by > > > > > > loss or reordering of packets containing flow > > > > > information, MUST be > > > > > > indicated." > > > > > > > > > > > > by > > > > > > > > > > > > "Different levels of reliability of the data > > transfer MAY be > > > > > > supported. The collecting process MUST have sufficient > > > > > information > > > > > > for making a conservative assumption about the applied > > > > > reliability > > > > > > level. This means that the applied level of reliability > > > > > MUST be as > > > > > > high as or higher than indicated to the collecting > > > process." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns regarding > > > > > the proposed > > > > > > wording: > > > > > > > > > > > > - It implies that the collecting process must indicate > > > the level > > > > > > of reliability it is interested in, hence, there > must be a > > > > > > mechanism to indicate this. > > > > > > > > > > No. It does not. At least, I cannot see this. Why do > > you think so? > > > > > > > > > > > - The words "conservative assumptions" are ambiguous. > > > > > > > > > > I agree. They should be changed. > > > > > > > > > > > - It implies the level of reliability may be higher than > > > > > required by > > > > > > collecting process - it is unclear to me why this is > > > implied by > > > > > > the consensus to allow the protocol to "MAY" > support higher > > > > > > levels of reliability. > > > > > > > > > > Of course the level may be higher or lower than > required by the > > > > > collecting process. It just says that the collecting > > > process needs > > > > > sufficient information on the reliability in order to find out > > > > > whether > > > > or not the > > > > > level is sufficient. > > > > > > > > > > > > > > > > > > > > > > > Therefore, may I propose the following alternative as a > > > > > replacement for the > > > > > > first paragraph in "6.3.2 Reliability": > > > > > > > > > > > > "The data exchange between the exporter and the > > collector MAY > > > > > > > > > > I'd suggest "data transfer from the exporting process to the > > > > > collecting process". > > > > > > > > > > > support different levels of reliability. > > > > > > > > > > > > For the most basic level of reliability, the > > > following should > > > > > > be maintained: > > > > > > - The collecting process MUST be able to detect > > > the level of > > > > > > reliability. > > > > > > - The collection process MUST be able to detect any > > > > > loss of data. > > > > > > > > > > > > For higher levels of reliability, the following > should be > > > > > > > > > > Are these several higher levels or is it a single higher level > > > > > including everything below? > > > > > > > > > > > maintained: > > > > > > - All reliability properties requirements of lower > > > levels of > > > > > > reliability MUST be maintained. > > > > > > > > > > Above you say "the following should b maintained", within the > > > > > following you say "MUST". Is should x MUST = should? > > > > > > > > > > > - The exporter process SHOULD be able to communicate > > > > with more > > > > > > than one collection process. > > > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > - In case of failure the collection process, or in the > > > > > > connectivity between the exporter process and one > > > > collection > > > > > > process, transmission of data SHOULD be > > redirected, in a > > > > > > fail-over fashion, to a secondary collection process. > > > > > > > > > > This is already covered by the last paragraph of section 6.3.2 > > > > > > > > > > > - In case of failover, data that has not been > > acknowledged > > > > > > SHOULD be retransmitted to the secondary > > > > collection process. > > > > > > > > > > Isn't this a solution rather than a requirement? > > > > > > > > > > > - The collection process MUST be able to eliminate > > > duplicate > > > > > > reporting of the same records emanating from the > > > fail over > > > > > > mechanism." > > > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in > > section "6.3.2": > > > > > > > > > > > > "The chosen method of data transfer MUST be extensible > > > > concerning > > > > > > reliability. It MUST be possible to increase > > reliability by > > > > > > extensions." > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > > > > after the second > > > > > > paragraph in 6.3.2. The main point on which I differ is > > > > > that your proposed > > > > > > wording implies that there must be an "ability to ... by > > > > > extensions" whereas > > > > > > I don't believe that is mandatory to meet the essence of > > > > > the requirements. > > > > > > If a protocol supports adequate levels of reliability, as > > > > > several of the > > > > > > currently evaluated protocols do, there may not be a need > > > > > for an extension > > > > > > > > > > Weren't among the people teaching us that there cannot be > > > > sufficient > > > > > reliability? What is sufficient depends on the > > > requirements of the > > > > > collecting process or the application processing the > > > > transfered data. > > > > > > > > > > > model. If, on the other hand, the protocol selected does > > > > > not have a reliable > > > > > > delivery mechanism, then a well-defined means to extend it > > > > > must be present. > > > > > > > > > > Some people said that without application level ACKs > > there is no > > > > > real reliability. Consequently, all you ask for above is not > > > > > reliable and would need to be extensible. > > > > > > > > > > The main lesson I learned is that there are several levels of > > > > > reliability and that you cannot say something is > > reliable or not > > > > > without specifying what you mean with "reliable". The only > > > > > consequence is that you have to > > > > > ask for every level, that it still is open for further > > > > > increasing reliability. > > > > > > > > > > > Therefore, may I suggest a slightly different wording than > > > > > the version you > > > > > > proposed: > > > > > > > > > > > > "If higher levels of reliability are not supported, > > > > there must be > > > > > > > > > > The term "higher levels" is only implicitly defined by your > > > > text above > > > > > and still ambiguous. How many levels need to be supported > > > such that > > > > > you need not to be extensible anymore? > > > > > > > > > > > a well-defined mechanism to extend the protocol > > to allow for > > > > > > increasing the reliability to support higher degrees of > > > > > > > > > > Is "degree" equivqalent to "level"? > > > > > > > > > > > reliability." > > > > > > > > > > > > > > > > > > > > > > > > I believe that even though the wording above may seem to > > > > hint at an > > > > > > implementation, in fact, it merely may state some lowest > > > > > common denominator > > > > > > features recurring in practically all existing reliable > > > > > delivery protocols. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Tal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > > > in message body > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe > > > > > ipfix" in message body > > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > > in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe > > > > ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message > > body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 16 17:07:01 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25149 for ; Thu, 16 Jan 2003 17:07:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZI31-0006mb-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jan 2003 15:59:39 -0600 Received: from pool-151-202-13-76.ny5030.east.verizon.net ([151.202.13.76] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZI2z-0006mW-00 for ipfix-req@net.doit.wisc.edu; Thu, 16 Jan 2003 15:59:37 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0GLxaO10141; Thu, 16 Jan 2003 16:59:36 -0500 From: "Carter Bullard" To: "'Tal Givoly'" Cc: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Juergen Quittek'" Subject: RE: [ipfix-req] proposed changes for requirements document Date: Thu, 16 Jan 2003 16:59:27 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A511@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC144@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I think that it is possible to have a single version of IPFIX that can support negotiation without requiring it. Negotiation could be apart of the TCP transport version. RTP over UDP unicast and multicast would of course not need any negotiation but configured as is done with Netflow today. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tal Givoly > Sent: Thursday, January 16, 2003 3:32 PM > To: Carter Bullard > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Carter, > > I'm the first to support your position here (i.e. that out of band > management is not very reliable or practical). In fact, it is > one of the > unique features in CRANE relative to all other candidate > protocols that have > been evaluated. Whereas other protocols rely on out of band > communication to > agree on operational parameters, CRANE negotiates the > protocol version, the > transport and the templates with multiple collection > processes - much like > Fax and Modem capability negotiation. > > For more information, you are welcome to read the CRANE > specification. If > you need further information regarding how this takes place, > it could also > be provided. > > Tal > > -----Original Message----- > From: Carter Bullard [mailto:carter@qosient.com] > Sent: Thursday, January 16, 2003 11:41 AM > To: 'Tal Givoly' > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > 'Juergen Quittek' > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Hey Tal, > Out of band management is an approach, but not > a very reliable or practical approach. Nice if > you have only one data collector, but if there are > more than one, which I assume that there will be, > then SNMP style configuration will be woefully lacking. > > I'm a major fan of template based negotiation, > so if you end up with something regarding this in > your contribution, it would make my day. > > Carter > > > > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tal Givoly > > Sent: Thursday, January 16, 2003 2:02 PM > > To: carter@qosient.com > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Carter, > > > > To best of my understanding, looking at the requirements, > there is no > > requirement that all versions of IPFIX are interoperable. It > > may be a useful > > requirement. However, adding that requirement may introduce > a derived > > requirement to support some form of negotiation. The > rationale for not > > requiring negotiation originally included the fact that out of band > > configuration could be used to set up compatible/interoperable > > implementations for both exporter and collector. > > > > Tal > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Carter Bullard > > Sent: Wednesday, January 15, 2003 6:36 PM > > To: 'Tal Givoly' > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; > > 'Juergen Quittek' > > Subject: RE: [ipfix-req] proposed changes for requirements document > > > > > > Hey Tal, > > My original mail was a reaction to Jeff suggesting > > that IPFIX would have retransmission capabilities to > > address some of his scenarios, which IMHO is not a given. > > > > The point I was making in my last email was that if > > you don't have negotiation, then you won't be able to > > turn on any type of extension, assuming of course that > > all versions of IPFIX are interoperable, which, IMHO, > > is a requirement. > > > > The complexity of supporting more than two levels of > > reliability without some form of negotiation seems to > > me to be a challenge. I would love to read about your > > approach!!!!!! > > > > Carter > > > > > > > -----Original Message----- > > > From: Tal Givoly [mailto:givoly@xacct.com] > > > Sent: Wednesday, January 15, 2003 8:51 PM > > > To: Carter Bullard > > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > > (HP-Cupertino,ex1)'; 'Juergen Quittek' > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Carter, > > > > > > Quoting from the meeting minutes of the previous meeting: > > > > > > -- Dave Plonka wrote on 25 November 2002 10:30 -0600: > > > > The issue of reliability was discussed. Juergen proposed, > > > and it was > > > > agreed to by a hum, that the requirements document should > > > specify that > > > > the IPFIX protocol MAY have "aditional reliability" and > > > that it MUST > > > > be open to reliability extensions. Tal Givoly will supply > > > clarifying > > > > text about this higher level of reliability, describing it in an > > > > implementation independent way. > > > > > > Therefore, I do not imply TCP vs. UDP but rather the > > > "additional reliability" that we agreed the IPFIX protocol > > > MAY have and MUST be extensible enough to support. Therefore, > > > my understanding was that it was not tossed out - but rather > > > classified as MAY support but MUST be extensible enough > to support. > > > > > > In order to demonstrate that it can be supported, I am > > > proposing the wording to qualify what that means from a > > > requirement standpoint. > > > > > > If you are referring to "negotiation" - that indeed is not > > > currently a requirement, nor have I claimed it should be in > > > any of these recent postings. > > > > > > I hope this helps clarify. > > > > > > Tal > > > > > > -----Original Message----- > > > From: majordomo listserver > > > [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard > > > Sent: Wednesday, January 15, 2003 4:51 PM > > > To: 'Tal Givoly' > > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > > (HP-Cupertino,ex1)'; 'Juergen Quittek' > > > Subject: RE: [ipfix-req] proposed changes for > requirements document > > > > > > > > > Hey Tal, > > > Could that mean TCP vs UDP vs RTP vs multicast, or do you > > > mean IPFIX level reliability? If its IPFIX level, then > > > you're going to have to negotiate the optional reliability > > > features, and I thought that negotiation had been tossed out? > > > > > > Carter > > > > > > > > > > > > > -----Original Message----- > > > > From: Tal Givoly [mailto:givoly@xacct.com] > > > > Sent: Wednesday, January 15, 2003 7:45 PM > > > > To: Carter Bullard > > > > Cc: ipfix-req@net.doit.wisc.edu; 'MEYER,JEFFREY D > > > (HP-Cupertino,ex1)'; > > > > 'Juergen Quittek' > > > > Subject: RE: [ipfix-req] proposed changes for > > requirements document > > > > > > > > > > > > Carter, > > > > > > > > Haven't we agreed that the protocol MAY support more reliable > > > > transports than merely being able to identify the fact that > > > loss has > > > > occurred? If that is the case, then we must allow for > > mechanisms by > > > > which the protocol can support them. Merely sequencing the > > > records and > > > > allowing identification of the amount of records lost > supports the > > > > "must" requirements, but leaves no ability to support the "may" > > > > requirement in a cost-effective manner (e.g. out of band > > recovery). > > > > > > > > The minimum must requirements of being able to identify how > > > much data > > > > has been lost in a potentially unreliable delivery > > mechanism or for > > > > any other cause of loss will still be there, but for those > > > > applications requiring higher reliability, I believe it is > > > required to > > > > provide some additional description as part of the requirements. > > > > > > > > Tal > > > > > > > > -----Original Message----- > > > > From: Carter Bullard [mailto:carter@qosient.com] > > > > Sent: Wednesday, January 15, 2003 1:08 PM > > > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Juergen > Quittek'; 'Tal > > > > Givoly' > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > Subject: RE: [ipfix-req] proposed changes for > > requirements document > > > > > > > > > > > > Hey Jeff, > > > > I agree that enumerating the various conditions is > > > > the correct thing, so I say great! > > > > > > > > On a different note, there is a huge difference > > > > between detecting/indicating loss of reliability > > > > and assuring a level of reliability. I am of the > > > > school that assuring reliability should be outside the > > > > scope of IPFIX. Even simple retransmission capabilities > > > > are not a potential solution as the principal target > > > > device for IPFIX is not going to be able to support > > > > the feature. > > > > > > > > But by providing the information needed to detect > > > > loss, such as through per record sequence numbering in > conjunction > > > > with timestamping, an application will have all the > info needed to > > > > enable out-of-band recovery. IPFIX could support recovery > > > itself if it > > > > could handle selective record transfer requests. > > > > > > > > Carter > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: majordomo listserver > > > [mailto:majordomo@mil.doit.wisc.edu] On > > > > > Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) > > > > > Sent: Wednesday, January 15, 2003 3:12 PM > > > > > To: 'Juergen Quittek'; Tal Givoly > > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > > Subject: RE: [ipfix-req] proposed changes for > > > requirements document > > > > > > > > > > > > > > > Hi, > > > > > > > > > > There seems to be agreement that losing flow information > > > > implies a > > > > > lack of reliability. I think understanding where this > > > information > > > > > loss might occur and what steps are taken to > "recover" the lost > > > > > information is the essence of the different "levels of > > > reliability". > > > > > > > > > > > > > > > Today the requirements draft has the following statement > > > > in section > > > > > 6.3.2: > > > > > > > > > > > > > > > "Possible reasons for flow information loss > include resource > > > > > shortage at the exporter, loss of packets between the > > > > > exporting process and collecting process, etc." > > > > > > > > > > > > > > > Rather than ending with "etc." it would be nice to try to > > > > enumerate > > > > > all the basic loss scenarios. I don't think there are > > > that many in > > > > > the model defined: > > > > > > > > > > > > > > > ObsPt -> Metering Proc -> Exporter -> Collector > > > > > > > > > > > > > > > Moving from left to right across the model, I see > > > > > the following "failures" impacting reliability: > > > > > > > > > > 1. A metering process may somehow fail to "keep up" with > > > > > the packets going past the ObsPt. > > > > > > > > > > This lack of reliability is not recoverable by the > > > > > exporter (i.e. The same box won't be able to "see" > > > > > these flows again). It should be reported as covered > > > > > in section 5.1. > > > > > > > > > > 2. The exporter may be experiencing congestion and > > > > > not be able to buffer new flows recorded by the metering > > > > > process. > > > > > > > > > > This lack of reliability will again be unrecoverable > > > > > from the perspective of the exporting system. Either > > > > > old flows or newly reported flows need to be dropped. > > > > > Such loss should be reported. > > > > > > > > > > 3. A packet carrying a flow sent by the Exporter to the > > > > Collector > > > > > is dropped by the network. This is an issue for > > unreliable > > > > > transports such as UDP. For reliable transports, these > > > > > drops are recovered by the transport itself. > > > > > > > > > > This lack of reliability is only an issue for UDP based > > > > > protocols and MAY be addressed through some means, > > > > > such as buffering on the Exporter and an > acknowledgement/ > > > > > timeout scheme. > > > > > > > > > > Having a "failover Collector" greatly increases the > > > > > likelihood that the Exporter will not exhaust buffering > > > > > before successfully retransmitting flow information. > > > > > > > > > > 4. The network connection between the Exporter and the > > > > > Collector is lost due to a failure (either in > the network > > > > > or on the collector). > > > > > > > > > > The disposition of some flow information in > transit may be > > > > > unknown to the Exporter. In addition subsequent flow > > > > > information is also at risk of being lost. > > > > > > > > > > This lack of reliability MAY be addressed by some > > > > > means such as buffering on the Exporter and having > > > > > a failover Collector(s) available. > > > > > > > > > > An application layer acknowledgement scheme aids > > > > > the exporter in identifying what information sent > > > > > has actually been received by the Collector. > > > > > > > > > > 5. The network connection between the Exporter and > > > > > the Collector is taken down for maintenance or other > > > > > administrative purposes. > > > > > > > > > > In this case it is desireable to gracefully transition > > > > > the delivery of flows from one Collector to an > > > > > auxilliary. > > > > > > > > > > Procedures for graceful handoff MAY be refined from > > > > > those for a simple failure (#4), to increase efficiency. > > > > > > > > > > 6. Congestion is detected between the Exporter and the > > > > > Collector, which jeopardizes the delivery of flow > > > > > information. The slow receiver/link problem. > > > > > > > > > > This may be considered either a basic failure of > > > > > the collector as in #4 above, or unavoidable as in > > > > > #2 above. > > > > > > > > > > > > > > > So to me, it seems like reliability boils down to whether > > > > > or not the protocol addresses 3, 4 and 5. > > > > > > > > > > I think the protocol MUST address 3, 4 and 5. However in > > > > > a deployment, there MAY only be one Collector set up. In > > > > > this case the reliable delivery is likely to be impacted > > > > > by failures 4 and 5 from time to time. > > > > > > > > > > That said, I don't see this as an extension, but really > > > > > a capability of the protocol. Or perhaps it is a > property of > > > > > the exporter, i.e. are any flows ever buffered for > > > > > retransmission in the event of loss of the communication > > > > > channel between the exporter and collector. > > > > > > > > > > Perhaps an indication on the part of the exporter as to > > > > > whether it makes any attempt to retransmit to a secondary > > > > > should be called out. However I don't see lots of "levels" > > > > > of reliability. > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Jeff Meyer > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > > > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > > > > To: Tal Givoly > > > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > > > Subject: RE: [ipfix-req] proposed changes for > > > > requirements document > > > > > > > > > > > > > > > > > > Hi Tal, > > > > > > > > > > > > Thank you for the comments. See my replies inline. > > > > > > > > > > > > Juergen > > > > > > > > > > > > -- Tal Givoly wrote on 14 January 2003 10:32 -0800: > > > > > > > > > > > > > Juergen, > > > > > > > > > > > > > > Some recommendation of modification to the > proposed changes: > > > > > > > > > > > > > > > > > > > > > 4. Replace the first paragraph in section "6.3.2. > > > Reliability": > > > > > > > > > > > > > > "Absence of reliability of the data transfer, for > > > > > > example caused by > > > > > > > loss or reordering of packets containing flow > > > > > > information, MUST be > > > > > > > indicated." > > > > > > > > > > > > > > by > > > > > > > > > > > > > > "Different levels of reliability of the data > > > transfer MAY be > > > > > > > supported. The collecting process MUST have sufficient > > > > > > information > > > > > > > for making a conservative assumption about the applied > > > > > > reliability > > > > > > > level. This means that the applied level of > reliability > > > > > > MUST be as > > > > > > > high as or higher than indicated to the collecting > > > > process." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 4, there seem to be a few concerns > regarding > > > > > > the proposed > > > > > > > wording: > > > > > > > > > > > > > > - It implies that the collecting process must indicate > > > > the level > > > > > > > of reliability it is interested in, hence, there > > must be a > > > > > > > mechanism to indicate this. > > > > > > > > > > > > No. It does not. At least, I cannot see this. Why do > > > you think so? > > > > > > > > > > > > > - The words "conservative assumptions" are ambiguous. > > > > > > > > > > > > I agree. They should be changed. > > > > > > > > > > > > > - It implies the level of reliability may be higher than > > > > > > required by > > > > > > > collecting process - it is unclear to me why this is > > > > implied by > > > > > > > the consensus to allow the protocol to "MAY" > > support higher > > > > > > > levels of reliability. > > > > > > > > > > > > Of course the level may be higher or lower than > > required by the > > > > > > collecting process. It just says that the collecting > > > > process needs > > > > > > sufficient information on the reliability in order > to find out > > > > > > whether > > > > > or not the > > > > > > level is sufficient. > > > > > > > > > > > > > > > > > > > > > > > > > > > Therefore, may I propose the following alternative as a > > > > > > replacement for the > > > > > > > first paragraph in "6.3.2 Reliability": > > > > > > > > > > > > > > "The data exchange between the exporter and the > > > collector MAY > > > > > > > > > > > > I'd suggest "data transfer from the exporting process to the > > > > > > collecting process". > > > > > > > > > > > > > support different levels of reliability. > > > > > > > > > > > > > > For the most basic level of reliability, the > > > > following should > > > > > > > be maintained: > > > > > > > - The collecting process MUST be able to detect > > > > the level of > > > > > > > reliability. > > > > > > > - The collection process MUST be able to detect any > > > > > > loss of data. > > > > > > > > > > > > > > For higher levels of reliability, the following > > should be > > > > > > > > > > > > Are these several higher levels or is it a single > higher level > > > > > > including everything below? > > > > > > > > > > > > > maintained: > > > > > > > - All reliability properties requirements of lower > > > > levels of > > > > > > > reliability MUST be maintained. > > > > > > > > > > > > Above you say "the following should b maintained", > within the > > > > > > following you say "MUST". Is should x MUST = should? > > > > > > > > > > > > > - The exporter process SHOULD be able to communicate > > > > > with more > > > > > > > than one collection process. > > > > > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > - In case of failure the collection process, > or in the > > > > > > > connectivity between the exporter process and one > > > > > collection > > > > > > > process, transmission of data SHOULD be > > > redirected, in a > > > > > > > fail-over fashion, to a secondary > collection process. > > > > > > > > > > > > This is already covered by the last paragraph of > section 6.3.2 > > > > > > > > > > > > > - In case of failover, data that has not been > > > acknowledged > > > > > > > SHOULD be retransmitted to the secondary > > > > > collection process. > > > > > > > > > > > > Isn't this a solution rather than a requirement? > > > > > > > > > > > > > - The collection process MUST be able to eliminate > > > > duplicate > > > > > > > reporting of the same records emanating from the > > > > fail over > > > > > > > mechanism." > > > > > > > > > > > > This is already covered as MAY requirement by section 8.3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5. Add new paragraph after second paragraph in > > > section "6.3.2": > > > > > > > > > > > > > > "The chosen method of data transfer MUST be extensible > > > > > concerning > > > > > > > reliability. It MUST be possible to increase > > > reliability by > > > > > > > extensions." > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding item 5, I agree that a paragraph should be added > > > > > > after the second > > > > > > > paragraph in 6.3.2. The main point on which I differ is > > > > > > that your proposed > > > > > > > wording implies that there must be an "ability to ... by > > > > > > extensions" whereas > > > > > > > I don't believe that is mandatory to meet the essence of > > > > > > the requirements. > > > > > > > If a protocol supports adequate levels of reliability, as > > > > > > several of the > > > > > > > currently evaluated protocols do, there may not be a need > > > > > > for an extension > > > > > > > > > > > > Weren't among the people teaching us that there cannot be > > > > > sufficient > > > > > > reliability? What is sufficient depends on the > > > > requirements of the > > > > > > collecting process or the application processing the > > > > > transfered data. > > > > > > > > > > > > > model. If, on the other hand, the protocol selected does > > > > > > not have a reliable > > > > > > > delivery mechanism, then a well-defined means to extend it > > > > > > must be present. > > > > > > > > > > > > Some people said that without application level ACKs > > > there is no > > > > > > real reliability. Consequently, all you ask for above is not > > > > > > reliable and would need to be extensible. > > > > > > > > > > > > The main lesson I learned is that there are several > levels of > > > > > > reliability and that you cannot say something is > > > reliable or not > > > > > > without specifying what you mean with "reliable". The only > > > > > > consequence is that you have to > > > > > > ask for every level, that it still is open for further > > > > > > increasing reliability. > > > > > > > > > > > > > Therefore, may I suggest a slightly different wording than > > > > > > the version you > > > > > > > proposed: > > > > > > > > > > > > > > "If higher levels of reliability are not supported, > > > > > there must be > > > > > > > > > > > > The term "higher levels" is only implicitly defined by your > > > > > text above > > > > > > and still ambiguous. How many levels need to be supported > > > > such that > > > > > > you need not to be extensible anymore? > > > > > > > > > > > > > a well-defined mechanism to extend the protocol > > > to allow for > > > > > > > increasing the reliability to support higher > degrees of > > > > > > > > > > > > Is "degree" equivqalent to "level"? > > > > > > > > > > > > > reliability." > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe that even though the wording above may seem to > > > > > hint at an > > > > > > > implementation, in fact, it merely may state some lowest > > > > > > common denominator > > > > > > > features recurring in practically all existing reliable > > > > > > delivery protocols. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Tal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Help mailto:majordomo@net.doit.wisc.edu and > say "help" > > > > > > in message body > > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > "unsubscribe > > > > > > ipfix" in message body > > > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > > -- > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > > > in message body > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe > > > > > ipfix" in message body > > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > in message > > > body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message > > body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 17 20:14:46 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08499 for ; Fri, 17 Jan 2003 20:14:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ZhIT-0000Wh-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Jan 2003 18:57:17 -0600 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ZhIR-0000WZ-00 for ipfix-req@net.doit.wisc.edu; Fri, 17 Jan 2003 18:57:15 -0600 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id 91835804EED; Fri, 17 Jan 2003 19:57:10 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 5A5A01C000A6; Fri, 17 Jan 2003 19:57:10 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 17 Jan 2003 19:57:10 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F212D24B2C@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'carter@qosient.com'" , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] does raqmon-pdu compete with ipfix? Date: Fri, 17 Jan 2003 19:57:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Hi, Further examining RAQMon, it looks like an interesting approach to address the collection of a certain limited set of flow information from end devices (vs. IPFIX which is more targeted at routers, probes, middleboxes). It is based on an essentially fixed data model containing 28 different attributes. Several of these attributes are particularly focused on QoS aspects of various streaming protocols, other attributes provide system level statistics such as CPU utilization. The attribute set is incomplete compared to that defined in IPFIX requirements. It also only specifies mappings onto non-congestion aware protocols today. Although one could picture mapping it to something like BEEP (RFC 3080). It clearly states that loss of information is a property of the current spec (framework sec. 2.4 bullet #6). Although it claims an extension framework, this basically consists of specifying a different header, which indicates the subsequent encoding of the payload is "interpreted by the application and not by RRC itself." (Hmmm not a lot of guidance there). [see PDU sec. 4.3] Given their design center, which appears to be device centric QoS reporting, with a focus on streaming, this UDP based, fixed set of information may address a need different than IPFIX, i.e. a dirt simple UDP packet that an app can blast at a collector, when it has some info to share. However, RAQMon clearly is incomplete in addressing IPFIX. Regards, Jeff Meyer > -----Original Message----- > From: Carter Bullard [mailto:carter@qosient.com] > Sent: Thursday, January 16, 2003 5:51 AM > To: ipfix-req@net.doit.wisc.edu > Subject: [ipfix-req] does raqmon-pdu compete with ipfix? > > > Gentle People, > I believe that raqmon-pdu is indeed a direct > competitor to IPFIX. Why not realize that raqmon > is a form of flow data and have it use IPFIX? > > Carter > > > -----Original Message----- > From: rmonmib-admin@ietf.org [mailto:rmonmib-admin@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, January 16, 2003 8:08 AM > To: IETF-Announce: > Cc: rmonmib@ietf.org > Subject: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Remote Network > Monitoring > Working Group of the IETF. > > Title : Real-time Application Quality of Service > Monitoring > (RAQMON) Protocol Data Unit (PDU) > Author(s) : A. Siddiqui et al. > Filename : draft-ietf-rmonmib-raqmon-pdu-00.txt > Pages : 26 > Date : 2003-1-15 > > This memo defines a common protocol data unit (PDU) used > between RAQMON > Data Source (RDS) and RAQMON Report Collector (RRC) to report a QOS > statistics using RTCP and SNMP as Transport Protocol. The original > RAQMON draft [SIDDIQUI3] was split into 3 parts to identify the RAQMON > Framework, RAQMON QOS PDU and RAQMON MIB. This memo defined RAQMON QOS > Protocol Data Unit (PDU). This memo also outlines mechanisms > to use Real > Time Transport Control Protocol > (RTCP) and Simple Network Management Protocol (SNMP) to > transport these > PDUs between RAQMON Data Source (RDS) and RAQMON Report > Collector (RRC) > as outlined in RAQMON Charter of the RMON Workgroup. The memo > [SIDDIQUI2] defines a Real-Time Application QOS Monitoring > (RAQMON) Framework that extends the RMON Framework to allow Real-time > Application QoS information as outlined by RAQMON Charter of the RMON > Workgroup. The memo [SIDDIQUI1] defines a portion of the Management > Information Base (MIB) for use with network management > protocols in the > Internet community. The document proposes an extension to the Remote > Monitoring MIB [RFC2819] to accommodate RAQMON solution. > Distribution of > this memo is unlimited. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon- pdu-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmonmib-raqmon-pdu-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jan 20 09:45:36 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21154 for ; Mon, 20 Jan 2003 09:45:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18acx4-0002e1-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jan 2003 08:31:02 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18acx2-0002dp-00 for ipfix@net.doit.wisc.edu; Mon, 20 Jan 2003 08:31:00 -0600 Received: from cisco.com (bclaise-isdn-home3.cisco.com [10.49.4.220]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h0KER6I07153; Mon, 20 Jan 2003 15:27:06 +0100 (CET) Message-ID: <3E2C073A.3040601@cisco.com> Date: Mon, 20 Jan 2003 15:27:06 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. ELK" CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX Requirement & Netflow evaluation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, Some more inline comments on the requirement draft. Let me reply to the comment on the netflow draft in a separate email. Regards, Benoit. > > Hi > > Just few comments from average knowledge user > > Note : reference to draft-claise-ipfix-eval-netflow-03.txt is between > ( ) , reference to draft-ietf-ipfix-reqs-07-txt is between [ ] > > > 2- Metering Process requirement > > B- Reliability [5.1] > For the ATM/FR switch world collecting statistics is a > MANDATORY/MUST requirement ,never seen a switch advertising > XX throughput in pps/cps with statistics collection turned > off . Unfortunatly this is not true in the router world . > If the router is not able to collect statistics at line rate so > this is a LIMITATION and if sampling is proposed so by all mean it > should not be > advertised/characterised as a FEATURE (sampling is a feature if > and only if it is provided in addition to line rate capabilities) > > i suggest to remove the word "either" so " The metering process > MUST be reliable ,missing reliability must be known and indicated by > the manufacturer implementing the IPFIX protocol " Let's not forget that in case of a router, the router still has to route packets, even if it implements IPFIX. This is a different philisophy than for example SS7 where you can't bill, then you don't offer the service. > > > The IPFIX WG should emphasis those points so : > 1- could be taken seriously by the router manufacturer . > 2- Educate the users/customer to consider such capabilities when > selecting a box . > > while browsing the mailing list i could see no voice from the > main network providers ,suggest to try to reach the participation of > this group . > This will help to set/clarify what is the "MUST" ,"Should", > "Optional" requirement . > The discusion is mainly dominated by manufacturer and > application_provider , Some application_provider tried to raise the > issue of what > the customers are expecting still some other simply need a > "simple" protocol ( a certain post indicated " i like XX protocl > because it is simple > to implement and take less memory" irespective if this "simple" > starpped version is good enough for the customers . > This "simple" proposal is good for a customer with couple of > routers but not at all adecate for a provider have 100+ on the > backbone and > 1000's as a CE ) . > > C- sampling [5.2] > Need to indicate that sampling feature is provided above and > over line rate capabilities and not as a replacement . Isn't it covered by: The metering process MAY support packet sampling. If sampling is supported the sampling configuration MUST be well defined. The sampling configuration includes the sampling method and all its parameters. > > At least to indicate that using sampling could reduce the scope > of "application requiring IP flow info export " . What would be your proposed sentence/paragraph? > > ( is it exist in real word any provider charging customer > based on sampling data ? . as an anology imagine a > restaurant charging the customer based on sampling ) > > > D- Overload behavior [5.3] > Need to indicate that whatever reaction is selected is based on > user selection (configuration) . > Also to indicate that the manufacturer should publish when such > condition could arise (CPU load , memory size, throughput in pps ) . Isn't it covered by But in case the overload behavior induces a change of the metering process behavior, the overload behavior MUST be clearly defined. > > > 3- Information model [6.1] > Could we add "Average Packet size" as item nbr "27" which MAY be > collected. > > reg Mpls , their is some view within the WG that Mpls need to be > eliminated . > By doing this the WG is eliminated a fast majority of customer who > need to collect flow information from P router . > Collecting the top label and FEC is basic requirement ,we need to > get more info . In order to keep the IPFIX requirement doc stable may be > issue a seperate draft reg optional Mpls requirement . From the last meeting minutes No objections were raised regarding leaving the document as-is with respect to these issues: - MPLS label/FEC > > I could thinck of the following : > > A- Owner of the top label ( LDP, RSVP-TE,Static,......other) > B- In case of LDP top label : The FEC . > C- In case of RSVP-TE top label : Tunnel end points (Head and tail) > and optionally session name > D-extract N'th nbr of label under the top label ( N is user > configurable) > E- depth of stack . > F- action taken on recieved top label (pop ,swap ..etc) > G- output top label Personally, I tend to agree with you. The most information we can export, the better. But anyway, the information model must be extensible so I don't think we must go through all the possible fields in the req. draft. Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 22 18:14:21 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10907 for ; Wed, 22 Jan 2003 18:14:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bTxP-0001Fk-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Jan 2003 17:06:55 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bTxL-0001Do-00 for ipfix-req@net.doit.wisc.edu; Wed, 22 Jan 2003 17:06:51 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0MN5RR62517 for ; Thu, 23 Jan 2003 00:05:27 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6ED6C85D6C for ; Thu, 23 Jan 2003 01:12:34 +0100 (CET) Date: Thu, 23 Jan 2003 00:06:34 +0100 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] proposed changes for requirements document Message-ID: <10646458.1043280393@[10.1.1.26]> In-Reply-To: <22047953.1041613887@[10.1.1.128]> References: <22047953.1041613887@[10.1.1.128]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, After receiving input from Tal and Jeff, Benoit and I modified the proposal for changing the requirements draft. Again I am asking: Can we agree on this? Juergen 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: "RTP header fields" by "RTP header fields [RFC1889]" 2. Append to Section "2.1. IP Traffic Flow": "Also, please note that although packet properties may depend on application headers, there is no requirement defined in this document related to applicaton headers." 3. Move in section 6.1 "Information Model" item "7. if protocol type is ICMP: ICMP type and code" from the list of MUST attributes to the list of SHOULD attributes. Now it is item 17. 4. Replace the entire section "6.3.2. Reliability" by "Loss of flow records during the data transfer from the exporting process to the collecting process MUST be indicated at the collecting process. This indication MUST allow the collecting process to gauge the number of flow records lost. Possible reasons for flow records loss include but is not limited to: 1. Metering process limitations: lack of memory, processing power, etc. These limitations are already covered in section 5.1. 2. Exporting process limitations: lack of memory, processing power, etc. 3. Data transfer problems: packets that carry flow records sent from the exporting process to the collecting process, are dropped by the network. Examples are connection failures, congestions in combination with an unreliable transport protocol, etc. 4. Collecting process limitations: it may be experiencing congestion and not able to buffer new flows records." Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. In such a case only lack of overall reliability MUST be indicated. For example reordering could be dealt with by adding a sequence number to each packet. The data transfer between exporting process and collecting process MUST be open to reliability extensions including at least - retransmission of lost flow records, - detection of disconnection and fail-over, and This extensibility MAY be used to provide additional reliability." 5. Add to References: "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996." -- Juergen Quittek wrote on 03 January 2003 17:11 +0100: > Dear all, > > Here is a list of suggestions for changes to the requirements document. > They are based on our discussion in Atlanta and on a comment by Benoit. > > I would like to achieve rough consensus on this list of changes > in order to enter working group last call for the requirements document. > > Juergen > > > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: > > "RTP header fields" by "RTP header fields [RFC1889]" > > 2. Append to Section "2.1. IP Traffic Flow": > > "Also, please note that although packet properties may depend on > application headers, there is no requirement defined in this document > related to applicaton headers." > > 3. Move in section 6.1 "Information Model" item "7. if protocol > type is ICMP: ICMP type and code" from the list of MUST > attributes to the list of SHOULD attributes. Now it is item 17. > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > "Absence of reliability of the data transfer, for example caused by > loss or reordering of packets containing flow information, MUST be > indicated." > > by > > "Different levels of reliability of the data transfer MAY be > supported. The collecting process MUST have sufficient information > for making a conservative assumption about the applied reliability > level. This means that the applied level of reliability MUST be as > high as or higher than indicated to the collecting process." > > 5. Add new paragraph after second paragraph in section "6.3.2": > > "The chosen method of data transfer MUST be extensible concerning > reliability. It MUST be possible to increase reliability by > extensions." > > 6. Add to References: > > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: > A Transport Protocol for Real-Time Applications", RFC 1889, > January 1996." > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 22 18:46:15 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11459 for ; Wed, 22 Jan 2003 18:46:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bUVF-0001wp-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Jan 2003 17:41:53 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bUVC-0001wh-00 for ipfix-req@net.doit.wisc.edu; Wed, 22 Jan 2003 17:41:51 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0MNkdq01651; Wed, 22 Jan 2003 15:46:39 -0800 From: "Tal Givoly" To: "Juergen Quittek" Cc: Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 22 Jan 2003 15:41:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <10646458.1043280393@[10.1.1.26]> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, Agreed with all with exception for a minor change I propose to item 4. The problem with the current phrasing is that reliability extension may not cover the most basic means for cost-effective deployments. Therefore, I would like the following bullet added to the bullets beginning with "-": " - an indication of acknowledgement from the collection process to the exporting process, indicating to the exporting process that it may discard flow information records that have been received at the collection process." I believe that by mandating the protocol be at least extensible enough to support this, we can achieve the desired level of reliability and permit for cost-effective deployments (less than 1-1 redundancy). This is one of the least implementation-dependent ways to phrase this item. It is implemented in slightly different ways in a large variety of protocols today, DIAMETER, GTP', RADIUS, CRANE, and Streaming IPDR to name but a few. It crystalizes what extension would be required to afford the right level of applicability to the protocol. Best regards, Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Juergen Quittek Sent: Wednesday, January 22, 2003 3:07 PM To: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] proposed changes for requirements document Dear all, After receiving input from Tal and Jeff, Benoit and I modified the proposal for changing the requirements draft. Again I am asking: Can we agree on this? Juergen 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: "RTP header fields" by "RTP header fields [RFC1889]" 2. Append to Section "2.1. IP Traffic Flow": "Also, please note that although packet properties may depend on application headers, there is no requirement defined in this document related to applicaton headers." 3. Move in section 6.1 "Information Model" item "7. if protocol type is ICMP: ICMP type and code" from the list of MUST attributes to the list of SHOULD attributes. Now it is item 17. 4. Replace the entire section "6.3.2. Reliability" by "Loss of flow records during the data transfer from the exporting process to the collecting process MUST be indicated at the collecting process. This indication MUST allow the collecting process to gauge the number of flow records lost. Possible reasons for flow records loss include but is not limited to: 1. Metering process limitations: lack of memory, processing power, etc. These limitations are already covered in section 5.1. 2. Exporting process limitations: lack of memory, processing power, etc. 3. Data transfer problems: packets that carry flow records sent from the exporting process to the collecting process, are dropped by the network. Examples are connection failures, congestions in combination with an unreliable transport protocol, etc. 4. Collecting process limitations: it may be experiencing congestion and not able to buffer new flows records." Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. In such a case only lack of overall reliability MUST be indicated. For example reordering could be dealt with by adding a sequence number to each packet. The data transfer between exporting process and collecting process MUST be open to reliability extensions including at least - retransmission of lost flow records, - detection of disconnection and fail-over, and This extensibility MAY be used to provide additional reliability." 5. Add to References: "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996." -- Juergen Quittek wrote on 03 January 2003 17:11 +0100: > Dear all, > > Here is a list of suggestions for changes to the requirements document. > They are based on our discussion in Atlanta and on a comment by Benoit. > > I would like to achieve rough consensus on this list of changes > in order to enter working group last call for the requirements document. > > Juergen > > > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: > > "RTP header fields" by "RTP header fields [RFC1889]" > > 2. Append to Section "2.1. IP Traffic Flow": > > "Also, please note that although packet properties may depend on > application headers, there is no requirement defined in this document > related to applicaton headers." > > 3. Move in section 6.1 "Information Model" item "7. if protocol > type is ICMP: ICMP type and code" from the list of MUST > attributes to the list of SHOULD attributes. Now it is item 17. > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > "Absence of reliability of the data transfer, for example caused by > loss or reordering of packets containing flow information, MUST be > indicated." > > by > > "Different levels of reliability of the data transfer MAY be > supported. The collecting process MUST have sufficient information > for making a conservative assumption about the applied reliability > level. This means that the applied level of reliability MUST be as > high as or higher than indicated to the collecting process." > > 5. Add new paragraph after second paragraph in section "6.3.2": > > "The chosen method of data transfer MUST be extensible concerning > reliability. It MUST be possible to increase reliability by > extensions." > > 6. Add to References: > > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: > A Transport Protocol for Real-Time Applications", RFC 1889, > January 1996." > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 22 18:56:09 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11596 for ; Wed, 22 Jan 2003 18:56:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bUZu-00023z-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Jan 2003 17:46:42 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bUZs-00023o-00 for ipfix-req@net.doit.wisc.edu; Wed, 22 Jan 2003 17:46:41 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id MAA25282; Thu, 23 Jan 2003 12:46:37 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AME59623; Thu, 23 Jan 2003 12:46:36 +1300 (NZDT) Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Thu, 23 Jan 2003 12:46:36 +1300 Message-ID: <1043279196.886c7cd197b1f@hotlava.auckland.ac.nz> Date: Thu, 23 Jan 2003 12:46:36 +1300 From: Nevil Brownlee To: Juergen Quittek Cc: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] requirements document References: <22047953.1041613887@[10.1.1.128]> <10646458.1043280393@[10.1.1.26]> In-Reply-To: <10646458.1043280393@[10.1.1.26]> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi uergen et al: > After receiving input from Tal and Jeff, Benoit and I modified the > proposal for changing the requirements draft. Again I am asking: > Can we agree on this? From the WG chair perspective, those changes look fine to me. Can we please try to agree on them quickly, and get the next version of the requirements published? Could Juergen submit the draft next Monday, for instance? We need to get it into WG last call, so that we can submit it to IESG well before the draft deadline for the San Francisco IETF - that's starting to seem very close now! Once the requirements document is done (or better, right now) we also need to get on with the IPFIX Evaluation process - the WG goal is to get agreement at/soon after the San Francisco meeting on the IPFIX protocol so that we can restart progress on the Architecture and Data Model documents. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jan 22 22:22:45 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15345 for ; Wed, 22 Jan 2003 22:22:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bXjc-0006Zx-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Jan 2003 21:08:56 -0600 Received: from palrel10.hp.com ([156.153.255.245]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bXja-0006Zn-00 for ipfix-req@net.doit.wisc.edu; Wed, 22 Jan 2003 21:08:54 -0600 Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel10.hp.com (Postfix) with ESMTP id 75D711C01321; Wed, 22 Jan 2003 19:08:53 -0800 (PST) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id E49361004BA2; Wed, 22 Jan 2003 19:08:52 -0800 (PST) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 22 Jan 2003 19:08:52 -0800 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F212D24B44@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Tal Givoly'" , Juergen Quittek Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document Date: Wed, 22 Jan 2003 19:08:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Hi, I'd agree with Tal, that without any Ack from the Collector, the exporter is going to be hard pressed to identify what needs to be retransmitted. And that any buffering done by the exporter will be suboptimal, since there is no knowledge about whether the flow has been delivered or not. I tried to be careful in my initial list of events which impact the reliability. In the modified list, one thing I don't see is any mention of maintenance (i.e. graceful "failover"). Could this be added as number 5 to your list: 5. The Collector is taken down for maintenance or other administrative purposes. Regards, Jeff Meyer > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Wednesday, January 22, 2003 3:42 PM > To: Juergen Quittek > Cc: ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] proposed changes for requirements document > > > Juergen, > > Agreed with all with exception for a minor change I propose to item 4. > > The problem with the current phrasing is that reliability > extension may not > cover the most basic means for cost-effective deployments. > Therefore, I > would like the following bullet added to the bullets > beginning with "-": > > " - an indication of acknowledgement from the collection > process to the > exporting process, indicating to the exporting process that > it may discard > flow information records that have been received at the > collection process." > > I believe that by mandating the protocol be at least > extensible enough to > support this, we can achieve the desired level of reliability > and permit for > cost-effective deployments (less than 1-1 redundancy). This > is one of the > least implementation-dependent ways to phrase this item. It > is implemented > in slightly different ways in a large variety of protocols > today, DIAMETER, > GTP', RADIUS, CRANE, and Streaming IPDR to name but a few. It > crystalizes > what extension would be required to afford the right level of > applicability > to the protocol. > > Best regards, > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Wednesday, January 22, 2003 3:07 PM > To: ipfix-req@net.doit.wisc.edu > Subject: Re: [ipfix-req] proposed changes for requirements document > > > Dear all, > > After receiving input from Tal and Jeff, Benoit and I modified the > proposal for changing the requirements draft. Again I am asking: > Can we agree on this? > > Juergen > > > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: > "RTP header fields" by "RTP header fields [RFC1889]" > > 2. Append to Section "2.1. IP Traffic Flow": > "Also, please note that although packet properties may depend on > application headers, there is no requirement defined in > this document > related to applicaton headers." > > 3. Move in section 6.1 "Information Model" item "7. if protocol > type is ICMP: ICMP type and code" from the list of MUST > attributes to the list of SHOULD attributes. Now it is item 17. > > 4. Replace the entire section "6.3.2. Reliability" by > "Loss of flow records during the data transfer from the exporting > process to the collecting process MUST be indicated at the > collecting process. This indication MUST allow the collecting > process to gauge the number of flow records lost. Possible reasons > for flow records loss include but is not limited to: > > 1. Metering process limitations: lack of memory, > processing power, etc. > These limitations are already covered in section 5.1. > 2. Exporting process limitations: lack of memory, > processing power, etc. > 3. Data transfer problems: packets that carry flow > records sent from > the exporting process to the collecting process, are > dropped by the > network. Examples are connection failures, congestions > in combination > with an unreliable transport protocol, etc. > 4. Collecting process limitations: it may be experiencing > congestion > and not able to buffer new flows records." > > Please note that if an unreliable transport protocol is used, > reliability can be provided by higher layers. In such a case only > lack of overall reliability MUST be indicated. For > example reordering > could be dealt with by adding a sequence number to each packet. > > The data transfer between exporting process and > collecting process MUST > be open to reliability extensions including at least > - retransmission of lost flow records, > - detection of disconnection and fail-over, and > This extensibility MAY be used to provide additional reliability." > > 5. Add to References: > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. > Jacobson, "RTP: > A Transport Protocol for Real-Time > Applications", RFC 1889, > January 1996." > > > -- Juergen Quittek wrote on 03 January 2003 17:11 +0100: > > > Dear all, > > > > Here is a list of suggestions for changes to the > requirements document. > > They are based on our discussion in Atlanta and on a > comment by Benoit. > > > > I would like to achieve rough consensus on this list of changes > > in order to enter working group last call for the > requirements document. > > > > Juergen > > > > > > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: > > > > "RTP header fields" by "RTP header fields [RFC1889]" > > > > 2. Append to Section "2.1. IP Traffic Flow": > > > > "Also, please note that although packet properties may depend on > > application headers, there is no requirement defined in > this document > > related to applicaton headers." > > > > 3. Move in section 6.1 "Information Model" item "7. if protocol > > type is ICMP: ICMP type and code" from the list of MUST > > attributes to the list of SHOULD attributes. Now it is item 17. > > > > 4. Replace the first paragraph in section "6.3.2. Reliability": > > > > "Absence of reliability of the data transfer, for > example caused by > > loss or reordering of packets containing flow > information, MUST be > > indicated." > > > > by > > > > "Different levels of reliability of the data transfer MAY be > > supported. The collecting process MUST have sufficient > information > > for making a conservative assumption about the applied > reliability > > level. This means that the applied level of reliability > MUST be as > > high as or higher than indicated to the collecting process." > > > > 5. Add new paragraph after second paragraph in section "6.3.2": > > > > "The chosen method of data transfer MUST be extensible concerning > > reliability. It MUST be possible to increase reliability by > > extensions." > > > > 6. Add to References: > > > > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. > Jacobson, > "RTP: > > A Transport Protocol for Real-Time > Applications", RFC > 1889, > > January 1996." > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message > body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 00:17:09 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17581 for ; Thu, 23 Jan 2003 00:17:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bZYV-0001Qf-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Jan 2003 23:05:35 -0600 Received: from pool-151-202-15-26.ny5030.east.verizon.net ([151.202.15.26] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bZYR-0001QV-00 for ipfix-req@net.doit.wisc.edu; Wed, 22 Jan 2003 23:05:32 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0N55VO28566 for ; Thu, 23 Jan 2003 00:05:31 -0500 From: "Carter Bullard" To: Subject: FW: [ipfix-req] does raqmon-pdu compete with ipfix? Date: Thu, 23 Jan 2003 00:05:22 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E805@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Jeff, I'm glad to see that you also recognize RAQMon-PDU as an IP flow information transport protocol. RAQMon is a new component of the RMON Architecture that introduces a completely new philosophy in RMON data generation/collection. It is exactly what the IPFIX concept envisions and is designed to support; remote probes generating flow information to enable various applications. Obviously, the RMON WG is saying that when it wants to use IP flow information as a data source in its new strategy, it doesn't need the minimum features and functions of IPFIX. The chairs and Ads are supporting this position, either out of ignorance or as a hedge. This is the essence of the problem. I believe that RAQMon-PDU is an IPFIX killer not because it can meet the requirements of IPFIX, but rather because RMON, a targeted IPFIX customer doesn't need the functions and features of the protocol. If the IESG accepts that position, then what are IPFIX's chances? I am not aware that the list "routers, probes, middleboxes" excludes end systems. Carter > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Friday, January 17, 2003 7:57 PM > To: 'carter@qosient.com'; ipfix-req@net.doit.wisc.edu > Subject: RE: [ipfix-req] does raqmon-pdu compete with ipfix? > > > Hi, > > Further examining RAQMon, it looks like an interesting > approach to address the collection of a certain limited set of flow > information from end devices (vs. IPFIX which is more > targeted at routers, probes, middleboxes). > > It is based on an essentially fixed data model containing 28 > different attributes. Several of these attributes are particularly > focused on QoS aspects of various streaming protocols, other > attributes provide system level statistics such as CPU utilization. > The attribute set is incomplete compared to that defined in IPFIX > requirements. > > It also only specifies mappings onto non-congestion aware > protocols today. Although one could picture mapping it to > something like BEEP (RFC 3080). > > It clearly states that loss of information is a property > of the current spec (framework sec. 2.4 bullet #6). > > > Although it claims an extension framework, this basically > consists of specifying a different header, which indicates > the subsequent encoding of the payload is "interpreted by the > application and not by RRC itself." (Hmmm not a lot of > guidance there). [see PDU sec. 4.3] > > > Given their design center, which appears to be device > centric QoS reporting, with a focus on streaming, this UDP based, > fixed set of information may address a need different than > IPFIX, i.e. a dirt simple UDP packet that an app can blast > at a collector, when it has some info to share. > > > However, RAQMon clearly is incomplete in addressing IPFIX. > > > Regards, > > Jeff Meyer > > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Thursday, January 16, 2003 5:51 AM > > To: ipfix-req@net.doit.wisc.edu > > Subject: [ipfix-req] does raqmon-pdu compete with ipfix? > > > > > > Gentle People, > > I believe that raqmon-pdu is indeed a direct > > competitor to IPFIX. Why not realize that raqmon > > is a form of flow data and have it use IPFIX? > > > > Carter > > > > > > -----Original Message----- > > From: rmonmib-admin@ietf.org > [mailto:rmonmib-admin@ietf.org] On Behalf > > Of Internet-Drafts@ietf.org > > Sent: Thursday, January 16, 2003 8:08 AM > > To: IETF-Announce: > > Cc: rmonmib@ietf.org > > Subject: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Remote Network > > Monitoring Working Group of the IETF. > > > > Title : Real-time Application Quality of Service > > Monitoring > > (RAQMON) Protocol Data Unit (PDU) > > Author(s) : A. Siddiqui et al. > > Filename : draft-ietf-rmonmib-raqmon-pdu-00.txt > > Pages : 26 > > Date : 2003-1-15 > > > > This memo defines a common protocol data unit (PDU) used between > > RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report > > a QOS statistics using RTCP and SNMP as Transport Protocol. The > > original RAQMON draft [SIDDIQUI3] was split into 3 parts to identify > the RAQMON > > Framework, RAQMON QOS PDU and RAQMON MIB. This memo defined > RAQMON QOS > > Protocol Data Unit (PDU). This memo also outlines mechanisms > > to use Real > > Time Transport Control Protocol > > (RTCP) and Simple Network Management Protocol (SNMP) to > > transport these > > PDUs between RAQMON Data Source (RDS) and RAQMON Report > > Collector (RRC) > > as outlined in RAQMON Charter of the RMON Workgroup. The memo > > [SIDDIQUI2] defines a Real-Time Application QOS Monitoring > > (RAQMON) Framework that extends the RMON Framework to allow > Real-time > > Application QoS information as outlined by RAQMON Charter > of the RMON > > Workgroup. The memo [SIDDIQUI1] defines a portion of the Management > > Information Base (MIB) for use with network management protocols in > > the Internet community. The document proposes an extension to the > > Remote Monitoring MIB [RFC2819] to accommodate RAQMON solution. > > Distribution of > > this memo is unlimited. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon- > pdu-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-rmonmib-raqmon-pdu-00.txt". > > A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmonmib-raqmon-pdu-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 00:22:32 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17667 for ; Thu, 23 Jan 2003 00:22:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bZe9-0001YH-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Jan 2003 23:11:25 -0600 Received: from c3p0.cc.swin.edu.au ([136.186.1.10] helo=net.cc.swin.edu.au) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bZe7-0001Y9-00 for ipfix-req@net.doit.wisc.edu; Wed, 22 Jan 2003 23:11:23 -0600 Received: from fokus.gmd.de (szander-laptop.caia.swin.edu.au [136.186.229.90]) by net.cc.swin.edu.au (8.9.3/8.9.3) with ESMTP id QAA22696; Thu, 23 Jan 2003 16:11:13 +1100 (AEDT) Message-ID: <3E2F7850.9000104@fokus.gmd.de> Date: Thu, 23 Jan 2003 06:06:24 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] proposed changes for requirements document References: <22047953.1041613887@[10.1.1.128]> <10646458.1043280393@[10.1.1.26]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, comments on Reliability inline Juergen Quittek wrote: > Dear all, > > After receiving input from Tal and Jeff, Benoit and I modified the > proposal for changing the requirements draft. Again I am asking: > Can we agree on this? > > Juergen [...] > 4. Replace the entire section "6.3.2. Reliability" by > "Loss of flow records during the data transfer from the exporting > process to the collecting process MUST be indicated at the > collecting process. This indication MUST allow the collecting > process to gauge the number of flow records lost. Possible reasons > for flow records loss include but is not limited to: > > 1. Metering process limitations: lack of memory, processing power, etc. > These limitations are already covered in section 5.1. > 2. Exporting process limitations: lack of memory, processing power, etc. > 3. Data transfer problems: packets that carry flow records sent from > the exporting process to the collecting process, are dropped by the > network. Examples are connection failures, congestions in combination > with an unreliable transport protocol, etc. > 4. Collecting process limitations: it may be experiencing congestion > and not able to buffer new flows records." The first sentence explicitly states an req. for loss during data transfer because this is a section in the "Data Transfer" chapter. In the list there are a couple of other reasons for loss (some which are even covered in a different section). I find this quite confusing. I suggest to remove this list from the draft (reason 1 and 3 are already covered within the draft) or find a more appropriate place for it. comment on reason 1: loss may not result in flow record loss. The loss may even occur before there is a flow record. > Please note that if an unreliable transport protocol is used, > reliability can be provided by higher layers. In such a case only > lack of overall reliability MUST be indicated. For example reordering > could be dealt with by adding a sequence number to each packet. > > The data transfer between exporting process and collecting process MUST > be open to reliability extensions including at least > - retransmission of lost flow records, > - detection of disconnection and fail-over, and point missing? > This extensibility MAY be used to provide additional reliability." > Cheers, Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 03:55:15 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00600 for ; Thu, 23 Jan 2003 03:55:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bd15-0005sZ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Jan 2003 02:47:19 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bd12-0005sR-00 for ipfix-req@net.doit.wisc.edu; Thu, 23 Jan 2003 02:47:16 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0N8l3R69735; Thu, 23 Jan 2003 09:47:04 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E85B385F54; Thu, 23 Jan 2003 10:54:07 +0100 (CET) Date: Thu, 23 Jan 2003 09:48:13 +0100 From: Juergen Quittek To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'Tal Givoly'" Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document Message-ID: <736639.1043315293@[10.1.1.128]> In-Reply-To: <4341EF5F8B4AD311AB4B00902740B9F212D24B44@xcup02.cup.hp.com> References: <4341EF5F8B4AD311AB4B00902740B9F212D24B44@xcup02.cup.hp.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, -- MEYER,JEFFREY D (HP-Cupertino,ex1) wrote on 22 January 2003 19:08 -0800: > Hi, > > I'd agree with Tal, that without any Ack from the Collector, > the exporter is going to be hard pressed to identify what > needs to be retransmitted. And that any buffering done by > the exporter will be suboptimal, since there is no knowledge > about whether the flow has been delivered or not. > > I tried to be careful in my initial list of events which > impact the reliability. In the modified list, one thing > I don't see is any mention of maintenance (i.e. graceful > "failover"). Could this be added as number 5 to your list: > > 5. The Collector is taken down for maintenance or other > administrative purposes. Got your point. I support your proposal. Juergen > > Regards, > > Jeff Meyer > >> -----Original Message----- >> From: Tal Givoly [mailto:givoly@xacct.com] >> Sent: Wednesday, January 22, 2003 3:42 PM >> To: Juergen Quittek >> Cc: ipfix-req@net.doit.wisc.edu >> Subject: RE: [ipfix-req] proposed changes for requirements document >> >> >> Juergen, >> >> Agreed with all with exception for a minor change I propose to item 4. >> >> The problem with the current phrasing is that reliability >> extension may not >> cover the most basic means for cost-effective deployments. >> Therefore, I >> would like the following bullet added to the bullets >> beginning with "-": >> >> " - an indication of acknowledgement from the collection >> process to the >> exporting process, indicating to the exporting process that >> it may discard >> flow information records that have been received at the >> collection process." >> >> I believe that by mandating the protocol be at least >> extensible enough to >> support this, we can achieve the desired level of reliability >> and permit for >> cost-effective deployments (less than 1-1 redundancy). This >> is one of the >> least implementation-dependent ways to phrase this item. It >> is implemented >> in slightly different ways in a large variety of protocols >> today, DIAMETER, >> GTP', RADIUS, CRANE, and Streaming IPDR to name but a few. It >> crystalizes >> what extension would be required to afford the right level of >> applicability >> to the protocol. >> >> Best regards, >> >> Tal >> >> -----Original Message----- >> From: majordomo listserver >> [mailto:majordomo@mil.doit.wisc.edu]On Behalf >> Of Juergen Quittek >> Sent: Wednesday, January 22, 2003 3:07 PM >> To: ipfix-req@net.doit.wisc.edu >> Subject: Re: [ipfix-req] proposed changes for requirements document >> >> >> Dear all, >> >> After receiving input from Tal and Jeff, Benoit and I modified the >> proposal for changing the requirements draft. Again I am asking: >> Can we agree on this? >> >> Juergen >> >> >> 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: >> "RTP header fields" by "RTP header fields [RFC1889]" >> >> 2. Append to Section "2.1. IP Traffic Flow": >> "Also, please note that although packet properties may depend on >> application headers, there is no requirement defined in >> this document >> related to applicaton headers." >> >> 3. Move in section 6.1 "Information Model" item "7. if protocol >> type is ICMP: ICMP type and code" from the list of MUST >> attributes to the list of SHOULD attributes. Now it is item 17. >> >> 4. Replace the entire section "6.3.2. Reliability" by >> "Loss of flow records during the data transfer from the exporting >> process to the collecting process MUST be indicated at the >> collecting process. This indication MUST allow the collecting >> process to gauge the number of flow records lost. Possible reasons >> for flow records loss include but is not limited to: >> >> 1. Metering process limitations: lack of memory, >> processing power, etc. >> These limitations are already covered in section 5.1. >> 2. Exporting process limitations: lack of memory, >> processing power, etc. >> 3. Data transfer problems: packets that carry flow >> records sent from >> the exporting process to the collecting process, are >> dropped by the >> network. Examples are connection failures, congestions >> in combination >> with an unreliable transport protocol, etc. >> 4. Collecting process limitations: it may be experiencing >> congestion >> and not able to buffer new flows records." >> >> Please note that if an unreliable transport protocol is used, >> reliability can be provided by higher layers. In such a case only >> lack of overall reliability MUST be indicated. For >> example reordering >> could be dealt with by adding a sequence number to each packet. >> >> The data transfer between exporting process and >> collecting process MUST >> be open to reliability extensions including at least >> - retransmission of lost flow records, >> - detection of disconnection and fail-over, and >> This extensibility MAY be used to provide additional reliability." >> >> 5. Add to References: >> "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. >> Jacobson, "RTP: >> A Transport Protocol for Real-Time >> Applications", RFC 1889, >> January 1996." >> >> >> -- Juergen Quittek wrote on 03 January 2003 17:11 +0100: >> >> > Dear all, >> > >> > Here is a list of suggestions for changes to the >> requirements document. >> > They are based on our discussion in Atlanta and on a >> comment by Benoit. >> > >> > I would like to achieve rough consensus on this list of changes >> > in order to enter working group last call for the >> requirements document. >> > >> > Juergen >> > >> > >> > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: >> > >> > "RTP header fields" by "RTP header fields [RFC1889]" >> > >> > 2. Append to Section "2.1. IP Traffic Flow": >> > >> > "Also, please note that although packet properties may depend on >> > application headers, there is no requirement defined in >> this document >> > related to applicaton headers." >> > >> > 3. Move in section 6.1 "Information Model" item "7. if protocol >> > type is ICMP: ICMP type and code" from the list of MUST >> > attributes to the list of SHOULD attributes. Now it is item 17. >> > >> > 4. Replace the first paragraph in section "6.3.2. Reliability": >> > >> > "Absence of reliability of the data transfer, for >> example caused by >> > loss or reordering of packets containing flow >> information, MUST be >> > indicated." >> > >> > by >> > >> > "Different levels of reliability of the data transfer MAY be >> > supported. The collecting process MUST have sufficient >> information >> > for making a conservative assumption about the applied >> reliability >> > level. This means that the applied level of reliability >> MUST be as >> > high as or higher than indicated to the collecting process." >> > >> > 5. Add new paragraph after second paragraph in section "6.3.2": >> > >> > "The chosen method of data transfer MUST be extensible concerning >> > reliability. It MUST be possible to increase reliability by >> > extensions." >> > >> > 6. Add to References: >> > >> > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. >> Jacobson, >> "RTP: >> > A Transport Protocol for Real-Time >> Applications", RFC >> 1889, >> > January 1996." >> > >> > >> > -- >> > Help mailto:majordomo@net.doit.wisc.edu and say >> "help" in message >> body >> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> > "unsubscribe ipfix" in message body >> > Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> in message >> body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 04:04:12 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00816 for ; Thu, 23 Jan 2003 04:04:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bd8T-00062K-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Jan 2003 02:54:57 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bd8R-00062C-00 for ipfix-req@net.doit.wisc.edu; Thu, 23 Jan 2003 02:54:55 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0N8stR69828; Thu, 23 Jan 2003 09:54:55 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AF31C85F53; Thu, 23 Jan 2003 11:01:59 +0100 (CET) Date: Thu, 23 Jan 2003 09:56:05 +0100 From: Juergen Quittek To: Tal Givoly Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document Message-ID: <1208718.1043315765@[10.1.1.128]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I completely understand Tal's arguments here. My only concern about this is that I think we declared application level acknowledgements to be out of scope. But my memory might be wrong. If noone else shares this memory or has other concerns, then I suggest to accept Tal's proposal but use a less solution-oriented phrasing instead of the suggested one: "- acknowledgement of flow records by the collecting process." Juergen -- Tal Givoly wrote on 22 January 2003 15:41 -0800: > Juergen, > > Agreed with all with exception for a minor change I propose to item 4. > > The problem with the current phrasing is that reliability extension may not > cover the most basic means for cost-effective deployments. Therefore, I > would like the following bullet added to the bullets beginning with "-": > > " - an indication of acknowledgement from the collection process to the > exporting process, indicating to the exporting process that it may discard > flow information records that have been received at the collection process." > > I believe that by mandating the protocol be at least extensible enough to > support this, we can achieve the desired level of reliability and permit for > cost-effective deployments (less than 1-1 redundancy). This is one of the > least implementation-dependent ways to phrase this item. It is implemented > in slightly different ways in a large variety of protocols today, DIAMETER, > GTP', RADIUS, CRANE, and Streaming IPDR to name but a few. It crystalizes > what extension would be required to afford the right level of applicability > to the protocol. > > Best regards, > > Tal > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Wednesday, January 22, 2003 3:07 PM > To: ipfix-req@net.doit.wisc.edu > Subject: Re: [ipfix-req] proposed changes for requirements document > > > Dear all, > > After receiving input from Tal and Jeff, Benoit and I modified the > proposal for changing the requirements draft. Again I am asking: > Can we agree on this? > > Juergen > > > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: > "RTP header fields" by "RTP header fields [RFC1889]" > > 2. Append to Section "2.1. IP Traffic Flow": > "Also, please note that although packet properties may depend on > application headers, there is no requirement defined in this document > related to applicaton headers." > > 3. Move in section 6.1 "Information Model" item "7. if protocol > type is ICMP: ICMP type and code" from the list of MUST > attributes to the list of SHOULD attributes. Now it is item 17. > > 4. Replace the entire section "6.3.2. Reliability" by > "Loss of flow records during the data transfer from the exporting > process to the collecting process MUST be indicated at the > collecting process. This indication MUST allow the collecting > process to gauge the number of flow records lost. Possible reasons > for flow records loss include but is not limited to: > > 1. Metering process limitations: lack of memory, processing power, etc. > These limitations are already covered in section 5.1. > 2. Exporting process limitations: lack of memory, processing power, etc. > 3. Data transfer problems: packets that carry flow records sent from > the exporting process to the collecting process, are dropped by the > network. Examples are connection failures, congestions in combination > with an unreliable transport protocol, etc. > 4. Collecting process limitations: it may be experiencing congestion > and not able to buffer new flows records." > > Please note that if an unreliable transport protocol is used, > reliability can be provided by higher layers. In such a case only > lack of overall reliability MUST be indicated. For example reordering > could be dealt with by adding a sequence number to each packet. > > The data transfer between exporting process and collecting process MUST > be open to reliability extensions including at least > - retransmission of lost flow records, > - detection of disconnection and fail-over, and > This extensibility MAY be used to provide additional reliability." > > 5. Add to References: > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: > A Transport Protocol for Real-Time Applications", RFC 1889, > January 1996." > > > -- Juergen Quittek wrote on 03 January 2003 17:11 +0100: > >> Dear all, >> >> Here is a list of suggestions for changes to the requirements document. >> They are based on our discussion in Atlanta and on a comment by Benoit. >> >> I would like to achieve rough consensus on this list of changes >> in order to enter working group last call for the requirements document. >> >> Juergen >> >> >> 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: >> >> "RTP header fields" by "RTP header fields [RFC1889]" >> >> 2. Append to Section "2.1. IP Traffic Flow": >> >> "Also, please note that although packet properties may depend on >> application headers, there is no requirement defined in this document >> related to applicaton headers." >> >> 3. Move in section 6.1 "Information Model" item "7. if protocol >> type is ICMP: ICMP type and code" from the list of MUST >> attributes to the list of SHOULD attributes. Now it is item 17. >> >> 4. Replace the first paragraph in section "6.3.2. Reliability": >> >> "Absence of reliability of the data transfer, for example caused by >> loss or reordering of packets containing flow information, MUST be >> indicated." >> >> by >> >> "Different levels of reliability of the data transfer MAY be >> supported. The collecting process MUST have sufficient information >> for making a conservative assumption about the applied reliability >> level. This means that the applied level of reliability MUST be as >> high as or higher than indicated to the collecting process." >> >> 5. Add new paragraph after second paragraph in section "6.3.2": >> >> "The chosen method of data transfer MUST be extensible concerning >> reliability. It MUST be possible to increase reliability by >> extensions." >> >> 6. Add to References: >> >> "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, > "RTP: >> A Transport Protocol for Real-Time Applications", RFC > 1889, >> January 1996." >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 13:00:39 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15168 for ; Thu, 23 Jan 2003 13:00:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18blMT-0004wQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Jan 2003 11:41:57 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18blMR-0004wL-00 for ipfix-req@net.doit.wisc.edu; Thu, 23 Jan 2003 11:41:55 -0600 Received: from Givoly ([192.168.0.2]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0NHkmq12023; Thu, 23 Jan 2003 09:46:48 -0800 From: "Tal Givoly" To: "Juergen Quittek" Cc: Subject: RE: [ipfix-req] proposed changes for requirements document Date: Thu, 23 Jan 2003 09:41:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1208718.1043315765@[10.1.1.128]> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, This is less explicit but is a sufficient placeholder so that in architecture discussions it may be refined. I support this compromise. Tal -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Thursday, January 23, 2003 12:56 AM To: Tal Givoly Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document Dear all, I completely understand Tal's arguments here. My only concern about this is that I think we declared application level acknowledgements to be out of scope. But my memory might be wrong. If noone else shares this memory or has other concerns, then I suggest to accept Tal's proposal but use a less solution-oriented phrasing instead of the suggested one: "- acknowledgement of flow records by the collecting process." Juergen -- Tal Givoly wrote on 22 January 2003 15:41 -0800: > Juergen, > > Agreed with all with exception for a minor change I propose to item 4. > > The problem with the current phrasing is that reliability extension may not > cover the most basic means for cost-effective deployments. Therefore, I > would like the following bullet added to the bullets beginning with "-": > > " - an indication of acknowledgement from the collection process to the > exporting process, indicating to the exporting process that it may discard > flow information records that have been received at the collection process." > > I believe that by mandating the protocol be at least extensible enough to > support this, we can achieve the desired level of reliability and permit for > cost-effective deployments (less than 1-1 redundancy). This is one of the > least implementation-dependent ways to phrase this item. It is implemented > in slightly different ways in a large variety of protocols today, DIAMETER, > GTP', RADIUS, CRANE, and Streaming IPDR to name but a few. It crystalizes > what extension would be required to afford the right level of applicability > to the protocol. > > Best regards, > > Tal > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Wednesday, January 22, 2003 3:07 PM > To: ipfix-req@net.doit.wisc.edu > Subject: Re: [ipfix-req] proposed changes for requirements document > > > Dear all, > > After receiving input from Tal and Jeff, Benoit and I modified the > proposal for changing the requirements draft. Again I am asking: > Can we agree on this? > > Juergen > > > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: > "RTP header fields" by "RTP header fields [RFC1889]" > > 2. Append to Section "2.1. IP Traffic Flow": > "Also, please note that although packet properties may depend on > application headers, there is no requirement defined in this document > related to applicaton headers." > > 3. Move in section 6.1 "Information Model" item "7. if protocol > type is ICMP: ICMP type and code" from the list of MUST > attributes to the list of SHOULD attributes. Now it is item 17. > > 4. Replace the entire section "6.3.2. Reliability" by > "Loss of flow records during the data transfer from the exporting > process to the collecting process MUST be indicated at the > collecting process. This indication MUST allow the collecting > process to gauge the number of flow records lost. Possible reasons > for flow records loss include but is not limited to: > > 1. Metering process limitations: lack of memory, processing power, etc. > These limitations are already covered in section 5.1. > 2. Exporting process limitations: lack of memory, processing power, etc. > 3. Data transfer problems: packets that carry flow records sent from > the exporting process to the collecting process, are dropped by the > network. Examples are connection failures, congestions in combination > with an unreliable transport protocol, etc. > 4. Collecting process limitations: it may be experiencing congestion > and not able to buffer new flows records." > > Please note that if an unreliable transport protocol is used, > reliability can be provided by higher layers. In such a case only > lack of overall reliability MUST be indicated. For example reordering > could be dealt with by adding a sequence number to each packet. > > The data transfer between exporting process and collecting process MUST > be open to reliability extensions including at least > - retransmission of lost flow records, > - detection of disconnection and fail-over, and > This extensibility MAY be used to provide additional reliability." > > 5. Add to References: > "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: > A Transport Protocol for Real-Time Applications", RFC 1889, > January 1996." > > > -- Juergen Quittek wrote on 03 January 2003 17:11 +0100: > >> Dear all, >> >> Here is a list of suggestions for changes to the requirements document. >> They are based on our discussion in Atlanta and on a comment by Benoit. >> >> I would like to achieve rough consensus on this list of changes >> in order to enter working group last call for the requirements document. >> >> Juergen >> >> >> 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: >> >> "RTP header fields" by "RTP header fields [RFC1889]" >> >> 2. Append to Section "2.1. IP Traffic Flow": >> >> "Also, please note that although packet properties may depend on >> application headers, there is no requirement defined in this document >> related to applicaton headers." >> >> 3. Move in section 6.1 "Information Model" item "7. if protocol >> type is ICMP: ICMP type and code" from the list of MUST >> attributes to the list of SHOULD attributes. Now it is item 17. >> >> 4. Replace the first paragraph in section "6.3.2. Reliability": >> >> "Absence of reliability of the data transfer, for example caused by >> loss or reordering of packets containing flow information, MUST be >> indicated." >> >> by >> >> "Different levels of reliability of the data transfer MAY be >> supported. The collecting process MUST have sufficient information >> for making a conservative assumption about the applied reliability >> level. This means that the applied level of reliability MUST be as >> high as or higher than indicated to the collecting process." >> >> 5. Add new paragraph after second paragraph in section "6.3.2": >> >> "The chosen method of data transfer MUST be extensible concerning >> reliability. It MUST be possible to increase reliability by >> extensions." >> >> 6. Add to References: >> >> "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, > "RTP: >> A Transport Protocol for Real-Time Applications", RFC > 1889, >> January 1996." >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 14:45:56 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18323 for ; Thu, 23 Jan 2003 14:45:56 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bnBE-0007Tt-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Jan 2003 13:38:28 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bnBC-0007TX-00 for ipfix-req@net.doit.wisc.edu; Thu, 23 Jan 2003 13:38:26 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA23797; Fri, 24 Jan 2003 08:38:16 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AMG07132; Fri, 24 Jan 2003 08:38:15 +1300 (NZDT) Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Fri, 24 Jan 2003 08:38:15 +1300 Message-ID: <1043350695.90906e98cf8c8@hotlava.auckland.ac.nz> Date: Fri, 24 Jan 2003 08:38:15 +1300 From: Nevil Brownlee To: Carter Bullard Cc: ipfix-req@net.doit.wisc.edu Subject: Re: FW: [ipfix-req] does raqmon-pdu compete with ipfix? References: <5C8959A16A71B449AE793CF52FBBED6607E805@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607E805@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Carter: > RAQMon is a new component of the RMON Architecture > that introduces a completely new philosophy in > RMON data generation/collection. It is exactly what > the IPFIX concept envisions and is designed to support; > remote probes generating flow information to enable > various applications. Obviously, the RMON WG is saying > that when it wants to use IP flow information as a data > source in its new strategy, it doesn't need the minimum features and > functions of IPFIX. The chairs and Ads are supporting this position, > either out of ignorance or as a hedge. This is the essence of the > problem. I think you're taking too simple a view. RAQMon is aimed at providing a simple means for QoS monitor boxes to gather information **about what's happening at the application layer** on small probes implemented in other boxes. The idea - at least the way I thought I understood it - is to provide monitoring of response times for transactions in a wide variety of systems. Although one could use flow information to derive QoS, that seems to be pushing the edges of RAQMon in terms of the amount of data an RAQ monitor box would need to retrieve from its probes. Differences between IPFIX and RAQmon: * RAQMon defines both ends of the data channel, IPFIX only defines the exporting end. * RAQMon seems to be aiming at carrying sets of metric values, probably using a TLV list to encode it. IPFIX is tailored to the exporting of large sets of flow data, minimising the encoding overhead by using templates. * RAQMon is targeted at making measurements at the application layer. IPFIX works with flows, i.e. at the transport layer. * Others ??? Having said all that, I agree with one thing you said - we (the IPFIX WG) need to get moving and make some real progress on the IPFIX documents soon! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 14:51:10 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18467 for ; Thu, 23 Jan 2003 14:51:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bnIY-00006a-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Jan 2003 13:46:02 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bnIW-00006T-00 for ipfix-req@net.doit.wisc.edu; Thu, 23 Jan 2003 13:46:00 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA25748; Fri, 24 Jan 2003 08:45:58 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AMG07678; Fri, 24 Jan 2003 08:45:57 +1300 (NZDT) Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Fri, 24 Jan 2003 08:45:56 +1300 Message-ID: <1043351156.04e7668b3e48a@hotlava.auckland.ac.nz> Date: Fri, 24 Jan 2003 08:45:56 +1300 From: Nevil Brownlee To: Juergen Quittek Cc: Tal Givoly , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document References: <1208718.1043315765@[10.1.1.128]> In-Reply-To: <1208718.1043315765@[10.1.1.128]> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jeurgen: > I completely understand Tal's arguments here. My only concern > about this is that I think we declared application level > acknowledgements to be out of scope. But my memory might be wrong. > > If noone else shares this memory or has other concerns, then I > suggest to accept Tal's proposal but use a less solution-oriented > phrasing instead of the suggested one: > > "- acknowledgement of flow records by the collecting process." 1) Your memory is correct, application-level acks are out of scope. 2) But Tal said .. > The data transfer between exporting process and collecting process MUST > be open to reliability extensions including at least so he's only proposing tht the precesses MUST 'be open to extensions,' which was the consensus from our Atlanta meeting. Tal's text lists two obvious reliability extensions, but I don't think that amounts to a 'solution-oriented phrasing.' I think it's OK as it is. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 23 14:58:06 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18618 for ; Thu, 23 Jan 2003 14:58:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18bnJu-00007k-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Jan 2003 13:47:26 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18bnJs-00007f-00 for ipfix-req@net.doit.wisc.edu; Thu, 23 Jan 2003 13:47:24 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA26199; Fri, 24 Jan 2003 08:47:23 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AMG07815; Fri, 24 Jan 2003 08:47:22 +1300 (NZDT) Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Fri, 24 Jan 2003 08:47:22 +1300 Message-ID: <1043351242.688c6c2c0b842@hotlava.auckland.ac.nz> Date: Fri, 24 Jan 2003 08:47:22 +1300 From: Nevil Brownlee To: Tal Givoly Cc: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] proposed changes for requirements document References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello again Juergen: > This is less explicit but is a sufficient placeholder so that in > architecture discussions it may be refined. > > I support this compromise. Well in that case, so do I. Maybe I should read all my mail before I start answering it :-) Cheers again, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jan 30 23:14:15 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17983 for ; Thu, 30 Jan 2003 23:14:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18eSHZ-00010u-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 Jan 2003 21:56:01 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18eSHX-00010i-00 for ipfix-eval@net.doit.wisc.edu; Thu, 30 Jan 2003 21:55:59 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id QAA06448; Fri, 31 Jan 2003 16:55:55 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AML60743; Fri, 31 Jan 2003 16:55:50 +1300 (NZDT) Received: from 203-96-154-244.tnt9.paradise.net.nz (203-96-154-244.tnt9.paradise.net.nz [203.96.154.244]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Fri, 31 Jan 2003 16:55:50 +1300 Message-ID: <1043985350.1d5f2bc281bc7@hotlava.auckland.ac.nz> Date: Fri, 31 Jan 2003 16:55:50 +1300 From: Nevil Brownlee To: Juergen Quittek Cc: plonka@doit.wisc.edu, "ipfix-eval@net.doit.wisc.edu" , nevil@auckland.ac.nz Subject: [ipfix-eval] Re: next version of IPFIX requirements References: <20030127204706.A8AC086701@venus.office> In-Reply-To: <20030127204706.A8AC086701@venus.office> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 203.96.154.244 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Quoting Juergen Quittek : > Hi Dave and Nevil, > > There is a new version of the IPFIX requirements. You can preview it at > > http://www.ibr.cs.tu-bs.de/~quittek/draft-ietf-ipfix-reqs-08.txt > > Before posting it I want to get your OK on changing the author list. > Following Dave's reminder on the mailing list, I checked the document > against the I-D nits. Among some minor issues, I found that the maximum > length of the author list is 5. In the last version of the requirements > the length of the list was 6. Therefore, I cut the list. When checking > the contribution of all listed authors, I found a big gap between the > first four and the remaining two authors. Therefore, I removed Georg and > KC from the author list and instead mentioned them explicitly in the > acknowledgements section. Additionally, I mentioned the names of many > other contributors in the acknowledgement. > > I will post the document as soon as I have your OK on this change. Good idea to check the I-D nits, we don't want little things like that to slow the RFC process ! I agree with your change to the authors list - Georg and KC came into the Requirements draft fairly late, as I remember. Go ahead and submit the draft, and at the same time, you'd better send a note to Georg and KC telling them about the change (and why we've made it). Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand vil@auckland ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 00:05:50 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19096 for ; Fri, 31 Jan 2003 00:05:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18eTBv-00028p-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 Jan 2003 22:54:15 -0600 Received: from pool-151-202-15-26.ny5030.east.verizon.net ([151.202.15.26] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18eTBt-00028j-00 for ipfix-eval@net.doit.wisc.edu; Thu, 30 Jan 2003 22:54:13 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0V4sDO12227; Thu, 30 Jan 2003 23:54:13 -0500 From: "Carter Bullard" To: "'Juergen Quittek'" Cc: Subject: RE: [ipfix-eval] Re: next version of IPFIX requirements Date: Thu, 30 Jan 2003 23:54:03 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A530@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC3C6@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Juergen, With regard to section 6.7 Anonymization. Because anonymization constraints/requirements have not been described, it is important that there be some indication that the data generated by the probe does not represent truth. I recommend this additional text: > 6.7. Anonymization > > The exporting process MAY be capable of anonymizing source and > destination IP addresses in flow data before exporting them. It MAY > support anonymization of port numbers and other fields. Please note > that anonymization is not originally an application requirement, but > derived from general requirements for treatment of measured traffic > data within a network. When the source produces anonymized flow data, an indication that some form of anonymization has been performed MUST be present, in order to help distinguish truthful vs. non-truthful data. I hope all see the need for this type of requirement given that some of the applications that are envisioned for IP Flow Data are critical applications that would require some truth assurances in the data. While an anonymization indicator won't prevent problems, it would help eliminate some obvious problems. Any suggestions on wording would be appreciated. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > Sent: Thursday, January 30, 2003 10:56 PM > To: Juergen Quittek > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > nevil@auckland.ac.nz > Subject: [ipfix-eval] Re: next version of IPFIX requirements > > > Quoting Juergen Quittek : > > > Hi Dave and Nevil, > > > > There is a new version of the IPFIX requirements. You can > preview it at > > > > http://www.ibr.cs.tu-bs.de/~quittek/draft-ietf-ipfix-reqs-08.txt > > > > Before posting it I want to get your OK on changing the author list. > > Following Dave's reminder on the mailing list, I checked > the document > > against the I-D nits. Among some minor issues, I found that > the maximum > > length of the author list is 5. In the last version of the > requirements > > the length of the list was 6. Therefore, I cut the list. > When checking > > the contribution of all listed authors, I found a big gap > between the > > first four and the remaining two authors. Therefore, I > removed Georg and > > KC from the author list and instead mentioned them explicitly in the > > acknowledgements section. Additionally, I mentioned the > names of many > > other contributors in the acknowledgement. > > > > I will post the document as soon as I have your OK on this change. > > Good idea to check the I-D nits, we don't want little things > like that > to slow the RFC process ! > > I agree with your change to the authors list - Georg and KC came into > the Requirements draft fairly late, as I remember. Go ahead > and submit > the draft, and at the same time, you'd better send a note to Georg and > KC telling them about the change (and why we've made it). > > Cheers, Nevil > > -------------------------------------------------------------- > --------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > vil@auckland > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 10:57:42 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10578 for ; Fri, 31 Jan 2003 10:57:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18edJc-00018y-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Jan 2003 09:42:52 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18edJZ-00018Y-00 for ipfix-eval@net.doit.wisc.edu; Fri, 31 Jan 2003 09:42:50 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0VFgY218708 for ; Fri, 31 Jan 2003 09:42:39 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Jan 2003 09:42:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 31 Jan 2003 09:42:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ipfix-eval] Question regarding Wiretapping Date: Fri, 31 Jan 2003 10:42:23 -0500 Message-ID: Thread-Topic: [ipfix-eval] Re: next version of IPFIX requirements Thread-Index: AcLI3y2hPzImFMl6TnG9WHdkpF6Y3AAX6kFQ From: To: , Cc: , , X-OriginalArrivalTime: 31 Jan 2003 15:42:24.0794 (UTC) FILETIME=[59E297A0:01C2C93F] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10578 Greetings, I have a general question, Hope to get an answer you people. For network management purposes, the network element may duplicate the user traffic (packet ) and forwards towards the management application. This may be considered as wiretapping and not legal in some countries. RFC 2804 describes what is wiretapping etc. Does that mean that user needs to be informed about fields are going to collected etc.... is there any technical solution for it. Regards Ramg -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 12:07:54 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12227 for ; Fri, 31 Jan 2003 12:07:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18eeaH-0002qt-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Jan 2003 11:04:09 -0600 Received: from pool-151-202-15-26.ny5030.east.verizon.net ([151.202.15.26] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18eeaE-0002qY-00 for ipfix-eval@net.doit.wisc.edu; Fri, 31 Jan 2003 11:04:07 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0VH3uO16637; Fri, 31 Jan 2003 12:03:56 -0500 From: "Carter Bullard" To: , , Cc: , , Subject: RE: [ipfix-eval] Question regarding Wiretapping Date: Fri, 31 Jan 2003 12:03:41 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A531@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC3D0@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Ramg, My understanding is that with regard to the U.S. federal voice wiretapping laws there are no restrictions to collecting network traffic by the service provider. The U.S. wiretapping laws simple define the conditions where carriers must disclose collected information to Law Enforcement. There are various state and federal privacy laws that restrict the disclosure of private information by service providers, but none of these laws restrict a service providers ability to collect information for operations management purposes. This is my simple understanding. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of ram.gopal@nokia.com > Sent: Friday, January 31, 2003 10:42 AM > To: n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > nevil@auckland.ac.nz > Subject: [ipfix-eval] Question regarding Wiretapping > > > Greetings, > > I have a general question, Hope to get an answer you people. > > For network management purposes, the network element may > duplicate the user traffic (packet ) and forwards towards the > management application. This may be considered as wiretapping > and not legal in some countries. > > RFC 2804 describes what is wiretapping etc. Does that mean > that user needs to be informed about fields are going > to collected etc.... is there any technical solution for it. > > Regards > Ramg > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 12:54:15 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13657 for ; Fri, 31 Jan 2003 12:54:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18efGO-0003gZ-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Jan 2003 11:47:40 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18efGM-0003gP-00 for ipfix-eval@net.doit.wisc.edu; Fri, 31 Jan 2003 11:47:39 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0VHlUR15330; Fri, 31 Jan 2003 18:47:31 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1BA4628E5D; Fri, 31 Jan 2003 19:53:14 +0100 (CET) Date: Fri, 31 Jan 2003 18:48:49 +0100 From: Juergen Quittek To: Nevil Brownlee Cc: plonka@doit.wisc.edu, "ipfix-eval@net.doit.wisc.edu" , nevil@auckland.ac.nz Subject: [ipfix-eval] Re: next version of IPFIX requirements Message-ID: <33255789.1044038929@[10.1.1.128]> In-Reply-To: <1043985350.1d5f2bc281bc7@hotlava.auckland.ac.nz> References: <1043985350.1d5f2bc281bc7@hotlava.auckland.ac.nz> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil, -- Nevil Brownlee wrote on 31 January 2003 16:55 +1300: > Quoting Juergen Quittek : > >> Hi Dave and Nevil, >> >> There is a new version of the IPFIX requirements. You can preview it at >> >> http://www.ibr.cs.tu-bs.de/~quittek/draft-ietf-ipfix-reqs-08.txt >> >> Before posting it I want to get your OK on changing the author list. >> Following Dave's reminder on the mailing list, I checked the document >> against the I-D nits. Among some minor issues, I found that the maximum >> length of the author list is 5. In the last version of the requirements >> the length of the list was 6. Therefore, I cut the list. When checking >> the contribution of all listed authors, I found a big gap between the >> first four and the remaining two authors. Therefore, I removed Georg and >> KC from the author list and instead mentioned them explicitly in the >> acknowledgements section. Additionally, I mentioned the names of many >> other contributors in the acknowledgement. >> >> I will post the document as soon as I have your OK on this change. > > Good idea to check the I-D nits, we don't want little things like that > to slow the RFC process ! > > I agree with your change to the authors list - Georg and KC came into > the Requirements draft fairly late, as I remember. Go ahead and submit Well, not really. Yes, KC came in late. But Georg was there from the very beginning. However, he stopped being active rather early. Cheers, Juergen > the draft, and at the same time, you'd better send a note to Georg and > KC telling them about the change (and why we've made it). > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > vil@auckland > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 13:34:21 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14883 for ; Fri, 31 Jan 2003 13:34:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18efpV-0004Ru-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Jan 2003 12:23:57 -0600 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18efpT-0004Rm-00 for ipfix-eval@net.doit.wisc.edu; Fri, 31 Jan 2003 12:23:55 -0600 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id 2E47F1C01525; Fri, 31 Jan 2003 13:23:55 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 72F121C00A5A; Fri, 31 Jan 2003 13:23:54 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 31 Jan 2003 13:23:54 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F212D24B8E@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'ram.gopal@nokia.com'" , n.brownlee@auckland.ac.nz, quittek@ccrle.nec.de Cc: plonka@doit.wisc.edu, ipfix-eval@net.doit.wisc.edu, nevil@auckland.ac.nz Subject: RE: [ipfix-eval] Question regarding Wiretapping Date: Fri, 31 Jan 2003 12:59:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Hi, I view the current information model defined by IPFIX as being the equivalent of "call logs". I.e. it shows when and who I spoke to, but doesn't divulge any information about the content of the conversation. So, in the sense the the phone company records all this info and needs/uses it for billing, I view as being an analogous case in the IP world, using IPFix or other usage recording methodologies. Wiretapping, actually monitoring the contents of the conversation is not something which IPFIX has in its information model (as far I am aware). So my take is that the IPFIX information is equivalent to information which is always recorded in the PSTN world. Now from a privacy perspective, who you divulge call logs to has broad legal repurcussions, but that is a separate topic. Regards, Jeff Meyer > -----Original Message----- > From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com] > Sent: Friday, January 31, 2003 7:42 AM > To: n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > nevil@auckland.ac.nz > Subject: [ipfix-eval] Question regarding Wiretapping > > > Greetings, > > I have a general question, Hope to get an answer you people. > > For network management purposes, the network element may > duplicate the user traffic (packet ) and forwards towards the > management application. This may be considered as wiretapping > and not legal in some countries. > > RFC 2804 describes what is wiretapping etc. Does that mean > that user needs to be informed about fields are going > to collected etc.... is there any technical solution for it. > > Regards > Ramg > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 13:50:34 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15354 for ; Fri, 31 Jan 2003 13:50:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18eg74-0004mu-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Jan 2003 12:42:07 -0600 Received: from pool-151-202-15-26.ny5030.east.verizon.net ([151.202.15.26] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18eg73-0004mk-00 for ipfix-eval@net.doit.wisc.edu; Fri, 31 Jan 2003 12:42:05 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0VIg2O17011; Fri, 31 Jan 2003 13:42:02 -0500 From: "Carter Bullard" To: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , , , Cc: , , Subject: RE: [ipfix-eval] Question regarding Wiretapping Date: Fri, 31 Jan 2003 13:41:57 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A532@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC3D5@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Jeff, Just for completeness, the US wiretapping laws cover three types of wiretaps, Pen Register, Trap and Trace and Content surveillance. Flow data can easily support all three types, but the simple flow model described in IPFIX should be able to support Pen Register, which generally provides calling and called party identifiers. It could also provide some of the Trap and Trace data, which looks alot like general PSTN billing data, but is provided in real time. There are standards for the format and transport of the data which collectively are referred to as the J-STD. IPFIX could conceivably meet J-STD transport requirements. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > MEYER,JEFFREY D (HP-Cupertino,ex1) > Sent: Friday, January 31, 2003 1:00 PM > To: 'ram.gopal@nokia.com'; n.brownlee@auckland.ac.nz; > quittek@ccrle.nec.de > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > nevil@auckland.ac.nz > Subject: RE: [ipfix-eval] Question regarding Wiretapping > > > Hi, > > I view the current information model defined by IPFIX > as being the equivalent of "call logs". I.e. it shows when > and who I spoke to, but doesn't divulge any information > about the content of the conversation. > > So, in the sense the the phone company records all this > info and needs/uses it for billing, I view as being an > analogous case in the IP world, using IPFix or other > usage recording methodologies. > > Wiretapping, actually monitoring the contents of the > conversation is not something which IPFIX has in its > information model (as far I am aware). > > So my take is that the IPFIX information is equivalent > to information which is always recorded in the PSTN > world. Now from a privacy perspective, who you divulge > call logs to has broad legal repurcussions, but that is > a separate topic. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com] > > Sent: Friday, January 31, 2003 7:42 AM > > To: n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de > > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > > nevil@auckland.ac.nz > > Subject: [ipfix-eval] Question regarding Wiretapping > > > > > > Greetings, > > > > I have a general question, Hope to get an answer you people. > > > > For network management purposes, the network element may > > duplicate the user traffic (packet ) and forwards towards the > > management application. This may be considered as wiretapping > > and not legal in some countries. > > > > RFC 2804 describes what is wiretapping etc. Does that mean > > that user needs to be informed about fields are going > > to collected etc.... is there any technical solution for it. > > > > Regards > > Ramg > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 16:18:32 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19216 for ; Fri, 31 Jan 2003 16:18:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18eiOH-00006g-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Jan 2003 15:08:01 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18eiOF-00006R-00 for ipfix-eval@net.doit.wisc.edu; Fri, 31 Jan 2003 15:07:59 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h0VL4Mq00692; Fri, 31 Jan 2003 13:04:22 -0800 From: "Tal Givoly" To: "Carter Bullard" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , , , Cc: , , Subject: RE: [ipfix-eval] Question regarding Wiretapping Date: Fri, 31 Jan 2003 12:59:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A532@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, Getting back to the requirements, which of the 5 classes of applications discussed in section 3 of the requirements (Usage-based accounting, Traffic Profiling, Traffic Engineering, Attack/intrusion detection, QoS monitoring), would wiretapping or lawful interception in any form be classified as? Is it the intent that IPFIX protocol support these applications? Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard Sent: Friday, January 31, 2003 10:42 AM To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; ram.gopal@nokia.com; n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; nevil@auckland.ac.nz Subject: RE: [ipfix-eval] Question regarding Wiretapping Hey Jeff, Just for completeness, the US wiretapping laws cover three types of wiretaps, Pen Register, Trap and Trace and Content surveillance. Flow data can easily support all three types, but the simple flow model described in IPFIX should be able to support Pen Register, which generally provides calling and called party identifiers. It could also provide some of the Trap and Trace data, which looks alot like general PSTN billing data, but is provided in real time. There are standards for the format and transport of the data which collectively are referred to as the J-STD. IPFIX could conceivably meet J-STD transport requirements. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > MEYER,JEFFREY D (HP-Cupertino,ex1) > Sent: Friday, January 31, 2003 1:00 PM > To: 'ram.gopal@nokia.com'; n.brownlee@auckland.ac.nz; > quittek@ccrle.nec.de > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > nevil@auckland.ac.nz > Subject: RE: [ipfix-eval] Question regarding Wiretapping > > > Hi, > > I view the current information model defined by IPFIX > as being the equivalent of "call logs". I.e. it shows when > and who I spoke to, but doesn't divulge any information > about the content of the conversation. > > So, in the sense the the phone company records all this > info and needs/uses it for billing, I view as being an > analogous case in the IP world, using IPFix or other > usage recording methodologies. > > Wiretapping, actually monitoring the contents of the > conversation is not something which IPFIX has in its > information model (as far I am aware). > > So my take is that the IPFIX information is equivalent > to information which is always recorded in the PSTN > world. Now from a privacy perspective, who you divulge > call logs to has broad legal repurcussions, but that is > a separate topic. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com] > > Sent: Friday, January 31, 2003 7:42 AM > > To: n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de > > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > > nevil@auckland.ac.nz > > Subject: [ipfix-eval] Question regarding Wiretapping > > > > > > Greetings, > > > > I have a general question, Hope to get an answer you people. > > > > For network management purposes, the network element may > > duplicate the user traffic (packet ) and forwards towards the > > management application. This may be considered as wiretapping > > and not legal in some countries. > > > > RFC 2804 describes what is wiretapping etc. Does that mean > > that user needs to be informed about fields are going > > to collected etc.... is there any technical solution for it. > > > > Regards > > Ramg > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jan 31 17:44:57 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20931 for ; Fri, 31 Jan 2003 17:44:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ejp9-000237-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Jan 2003 16:39:51 -0600 Received: from pool-151-202-15-26.ny5030.east.verizon.net ([151.202.15.26] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ejp7-000230-00 for ipfix-eval@net.doit.wisc.edu; Fri, 31 Jan 2003 16:39:49 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h0VMdeO17212; Fri, 31 Jan 2003 17:39:40 -0500 From: "Carter Bullard" To: "'Tal Givoly'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , , , Cc: , , Subject: RE: [ipfix-eval] Question regarding Wiretapping Date: Fri, 31 Jan 2003 17:39:34 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A533@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660FC3D9@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Tal, Based on the official position of the IETF and Internet Society to not describe technology that supports wiretapping (raven), I wouldn't recommend that IPFIX pursue it. I was just trying to answer Ramg's question. I suspect that the 5 applications mentioned in section 3 don't really qualify as classes of applications. Network Management is formal class of application. While Security Management, which is a logical subset of Network Management, may be considered a class of application, Attack/Intrusion detection is a specific Security Management application, not a class. Carter > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Friday, January 31, 2003 3:59 PM > To: Carter Bullard; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > ram.gopal@nokia.com; n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > nevil@auckland.ac.nz > Subject: RE: [ipfix-eval] Question regarding Wiretapping > > > Hi, > > Getting back to the requirements, which of the 5 classes of > applications > discussed in section 3 of the requirements (Usage-based > accounting, Traffic > Profiling, Traffic Engineering, Attack/intrusion detection, > QoS monitoring), > would wiretapping or lawful interception in any form be classified as? > > Is it the intent that IPFIX protocol support these applications? > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: Friday, January 31, 2003 10:42 AM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; ram.gopal@nokia.com; > n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > nevil@auckland.ac.nz > Subject: RE: [ipfix-eval] Question regarding Wiretapping > > > Hey Jeff, > Just for completeness, the US wiretapping laws cover > three types of wiretaps, Pen Register, Trap and Trace > and Content surveillance. Flow data can easily support > all three types, but the simple flow model described > in IPFIX should be able to support Pen Register, which > generally provides calling and called party identifiers. > It could also provide some of the Trap and Trace data, > which looks alot like general PSTN billing data, but is > provided in real time. > > There are standards for the format and transport of > the data which collectively are referred to as the J-STD. > IPFIX could conceivably meet J-STD transport requirements. > > Carter > > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > > MEYER,JEFFREY D (HP-Cupertino,ex1) > > Sent: Friday, January 31, 2003 1:00 PM > > To: 'ram.gopal@nokia.com'; n.brownlee@auckland.ac.nz; > > quittek@ccrle.nec.de > > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > > nevil@auckland.ac.nz > > Subject: RE: [ipfix-eval] Question regarding Wiretapping > > > > > > Hi, > > > > I view the current information model defined by IPFIX > > as being the equivalent of "call logs". I.e. it shows when > > and who I spoke to, but doesn't divulge any information > > about the content of the conversation. > > > > So, in the sense the the phone company records all this > > info and needs/uses it for billing, I view as being an > > analogous case in the IP world, using IPFix or other > > usage recording methodologies. > > > > Wiretapping, actually monitoring the contents of the > > conversation is not something which IPFIX has in its > > information model (as far I am aware). > > > > So my take is that the IPFIX information is equivalent > > to information which is always recorded in the PSTN > > world. Now from a privacy perspective, who you divulge > > call logs to has broad legal repurcussions, but that is > > a separate topic. > > > > Regards, > > > > Jeff Meyer > > > > > -----Original Message----- > > > From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com] > > > Sent: Friday, January 31, 2003 7:42 AM > > > To: n.brownlee@auckland.ac.nz; quittek@ccrle.nec.de > > > Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; > > > nevil@auckland.ac.nz > > > Subject: [ipfix-eval] Question regarding Wiretapping > > > > > > > > > Greetings, > > > > > > I have a general question, Hope to get an answer you people. > > > > > > For network management purposes, the network element may > > > duplicate the user traffic (packet ) and forwards towards the > > > management application. This may be considered as wiretapping > > > and not legal in some countries. > > > > > > RFC 2804 describes what is wiretapping etc. Does that mean > > > that user needs to be informed about fields are going > > > to collected etc.... is there any technical solution for it. > > > > > > Regards > > > Ramg > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/