From majordomo@mil.doit.wisc.edu Wed Oct 1 03:13:31 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 DAA00925 for ; Wed, 1 Oct 2003 03:13:30 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A4amI-0000Q9-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Oct 2003 01:48:02 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A4amH-0000Q4-00 for ipfix@net.doit.wisc.edu; Wed, 01 Oct 2003 01:48:01 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2003 08:46:25 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h916lsvU000201; Wed, 1 Oct 2003 08:47:54 +0200 (MET DST) Received: from cisco.com (ams-clip-vpn-dhcp182.cisco.com [10.61.64.182]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA00724; Wed, 1 Oct 2003 07:47:55 +0100 (BST) Message-ID: <3F7A789B.4030103@cisco.com> Date: Wed, 01 Oct 2003 07:47:55 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. References: <1D3D2C371FCBD947A7897FABBD3533A502960333@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960333@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit We need to consider IEs on a case by case basis, but I can see that the collector designer would have difficulty with completely open-ended IE sizes. One approach would be for ipfix to declare a recommended maximum for an object, but allow the exporter to exceed that. The other is, as Jeff proposes, to set a hard limit. Either way I think that we agree that the exporter can choose to use a smaller IE size. In the soft limit case, presumably the exporter would only exceed the recommended limit for good reason, and a collector unable to operate with an IE that large would have to flag an error. The difference between a hard and a soft upper bound it how far out we set the upper limit. The twin problems of undersizing and backwards compatibility are notorious in this industry leading to all sorts of work-around. A hard limit design would therefore need to set the limit way above what currently seemed reasonable. Would this then lead to unreasonable storage requirements in the collector? Although we could perhaps regard the collector storage capacity as approximating infinity, what about an aggregator? Stewart MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > Hi, > > One possible way to address Stewart's concern, which seems > primarily around exporters not wanting to fill in 64-bit fields, > is to separate the concern of the information model and the > encoding. > > Specifically, since the current protocol specification > explicitly states lengths used in templates, rather than the > type, an exporter could chose to send quantities in 4 bytes > or 2 bytes or whatever. The consumer would know that the > quantity was actually targeted at some specified size and > process it accordingly. > > Obviously this only works for "downsizing" data items, not > upsizing them. But since the arguments seem around "constrained" > systems, then downsizing would appear to be the use case. > > Changes in things like AS number from 16 to 32-bytes are > changes in the information model, I'd prefer to see these > reflected with explicit updates. > > If explicit types are good enough for C, Java, and DB's I > imagine they're good enough for IPFIX. > > -- Jeff > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Tuesday, September 30, 2003 10:06 AM >>To: MEYER,JEFFREY D (HP-Cupertino,ex1) >>Cc: ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] Variant Field Types. >> >> >> >> >>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >> >>>Hi, >>> >>> Although the use of variant types may seem convenient from the >>>perspective of an >>>exporter, I think the various consumers of the data would >> >>benefit from >> >>>sticking with >>>an explicit type system. >>> >> >>Variant types allow better use of resources and the ability to upgrade >>fields without the need to firstly get IETF approval, and secondly >>synchronise deployment of the exporter and collector upgrade. >> >>Anything that counts is a good example. To cope with the high end >>systems we really need to make them all 64bits. That means that >>tiny system that are memory and export limited and which may never >>wrap a 16 or 32 bit counter need to devote resources to 64 bits. >> >>If we were designing this say 5 years ago we would probably not have >>considered 32 bit AS numbers, now we need to. There are bound to be >>other IE that need to be upgraded, and for each and every one we need >>to synchronise both exporter and collector. >> >>By introducing this flexibility we get greater scope for how we handle >>these upgrades. >> >> >>> Consider operations which involve summing fields, storing >> >>them to a >> >>>DB, etc. >>> >> >>The collector storage is less likely to be the long pole in the tent >>than the exporter or the transmission bandwidth to the collector. The >>collector can therefore more readily be implemented to accept the >>largest reasonable value than can the exporter. >> >> >>> Explicit typing ensures that these consuming applications >> >>can handle >> >>>these values >>>appropriately and also makes the information modeller think >> >>about how these >> >>>types are to be used. >> >>But they have to think worst case during deployment, and my contention >>is that this places undue stress on the exporter and on the network >>bandwidth. >> >> >>> >>> The examples you cite: >>> >>>- ingressPort >>>- egressPort >>>- packetCount >>>- byteCount >>>- sourceAS >>>- destinationAS >>>- nextHopAS >>>- droppedPacketCount >>>- samplingInterval >>>- droppedByteCount >>> >>> fall into a few categories, identifiers (such as ports and AS's), >>>counts and intervals. >>> >>> For the identifiers, I believe the size is fixed by the >> >>relevant RFC's >> >>>(i.e. why would I >>>have a 1 byte Port?). >> >>Clearly but not long ago you would have said "why would I >>have a 4 byte >>AS number" >> >>Also you are thinking in terms of the "examples" we have in >>the current >>RFCs. We need to design this both for future RFCs and for >>vendor specific >>IEs. >> >> >>>For counts, the use of 32 vs. 64 bits is a valid >>>question, however >>>these can be handled by making them explicit (i.e. the >> >>information model >> >>>says if >>>I get this value it is a 32-bit quantity or a 64-bit >> >>quantity and the >> >>>code will address >>>it accordingly). For intervals, the resolution would >> >>determine which >> >>>size is most >>>appropriate. >> >>But this then makes it harder for tiny systems or cramps >>large systems. >> >> >>> >>> The option always exist to define variations on these data items >>>explicitly. E.g. >>>byteCount32 and byteCount64. >> >>Thay leads to two (or more) varients that the collector has >>to support. >>The alternative is for the collector to support the larger, >>and the exporter >>to support what ever size it wants. An alternative way to >>think of this >>is as a data compression technology. >> >> >>> >>> If there is a need to vary the sizes for various fields I'd much >>>rather see the rationale >>>for each discrete sizing made explicit vs. forcing all the >> >>downstream >> >>>consumers of this \ >>>information have to deal with special cases and ambiguity. >>> >> >>That requires too much (unnecessary) synchronisation between >>exporter and collector. >> >>Regards >> >>Stewart >> >> >>> >>>Regards, >>> >>> Jeff Meyer >>> >>> >>> >>> -----Original Message----- >>> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >>> Sent: Monday, September 29, 2003 6:00 PM >>> To: ipfix@net.doit.wisc.edu >>> Subject: [ipfix] Variant Field Types. >>> >>>Hi, >>> >>>The information model only >>>has types for fixed length objects and variable length >>>string like objects. >>> >>>There are a number of information element types (listed below) >>>that would be better defined in terms of fixed-size run-time >>>specified objects. The type variation comes due to difference >>>in the size of the objects used because of an implementation, >>>as demanded by the network or otherwise. >>> >>>The way to make this work is to use the template >>>length field to determine the exact sub-type: >>> >>>The definitions of a variant field type can be stated as: >>> >>>type varUnsignedInt >>> if (element.length == 1) >>> type = unsignedByte >>> else if (element.length <= 2) >>> type = unsignedShort >>> else if (element.length <= 4) >>> type = unsignedInt >>> else if (element.length <= 8) >>> type = unsignedLong >>> else type = undefined >>> >>>type varInt >>> if (element.length == 1) >>> type = byte >>> else if (element.length <= 2) >>> type = short >>> else if (element.length <= 4) >>> type = int >>> else if (element.length <= 8) >>> type = long >>> else type = undefined >>> >>>The candidates that fit into the description above are (I may >>>have missed some also): >>>- ingressPort >>>- egressPort >>>- packetCount >>>- byteCount >>>- sourceAS >>>- destinationAS >>>- nextHopAS >>>- droppedPacketCount >>>- samplingInterval >>>- droppedByteCount >>> >>>Please comment. >>> >>>Thanks >>>Ganesh >> > > -- > 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 Oct 1 11:34: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 LAA19584 for ; Wed, 1 Oct 2003 11:34:57 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A4ihr-0003h6-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Oct 2003 10:15:59 -0500 Received: from sv1.eng.oar.net ([192.148.251.86]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A4ihq-0003gz-00 for ipfix@net.doit.wisc.edu; Wed, 01 Oct 2003 10:15:58 -0500 Received: (qmail 94258 invoked from network); 1 Oct 2003 15:15:55 -0000 Received: from dev1.eng.oar.net (192.148.251.71) by sv1.eng.oar.net with SMTP; 1 Oct 2003 15:15:55 -0000 Received: (qmail 39513 invoked by uid 4454); 1 Oct 2003 15:15:55 -0000 Date: Wed, 1 Oct 2003 11:15:55 -0400 From: Mark Fullmer To: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. Message-ID: <20031001111555.A39319@net.ohio-state.edu> References: <1D3D2C371FCBD947A7897FABBD3533A502960336@xsun01.ptp.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960336@xsun01.ptp.hp.com>; from jeff.meyer2@hp.com on Tue, Sep 30, 2003 at 04:20:07PM -0400 Precedence: bulk Sender: majordomo listserver I'm in favor of setting upper bounds, for example counters don't go past 64 bits. If you don't do this, what's a collector to do with say a 72 bit counter? You can't store it in a uint_64_t anymore so collectors would have to implement arbitrary precision arithmetic to handle potential cases. I don't think this is reasonable to impose on the collectors. The issue I have with the variable length fields as currently specified is the potential for template explosion. If a template has 8 counters, each of which could be 1..8 byte then you have 8^8 potential templates for that one stream of flows. I was hoping for the sake of the collectors we could keep the active templates down to something < 64K so a template lookup could be done with an index instead of a hash. mark On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > Ganesh, > > I'm not clear on how this benefits the collector. Tal and myself produce > different implementations of carrier deployed products which collect from > 100's of devices and dozens of protocols, perhaps our experience here is > worth something, and it tells us variant is undesireable on the collector... > > Regarding your other point: > > One way to solve this problem is if the collector assumes the largest size > for > computations? > > This was my point in the e-mail to Stewart. Have the information model be > EXPLICIT about what is the largest size which is being modeled for a data > item and declare it. Allow the exporter to declare a smaller size in the > template, if the exporter knows that an individual record will always be > accomodated (based on its implementation) in the smaller size. > > So for instance this might say that byteCount should be declared in the > information model as a 64-bit int, while AS is probably sufficient at > 32-bits. > > This accomodates the: > exporter - can use smaller size if known > n/w - can reduce BW if know a smaller size is used > info model - explicit is better than "vague" > collector - addresses persistence and aggregation issues > > Can we call this a compromise? > > Regards, > > Jeff Meyer > > -----Original Message----- > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > Sent: Tuesday, September 30, 2003 10:45 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Variant Field Types. > > > > > MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > > Hi, > > Although the use of variant types may seem convenient from the perspective > of an > exporter, I think the various consumers of the data would benefit from > sticking with > an explicit type system. > > It would benefit the exporter, the n/w, flexibility of interpretation of > fields in the > information model and the collector. > > > > Consider operations which involve summing fields, storing them to a DB, > etc. > > One way to solve this problem is if the collector assumes the largest size > for > computations? > > > > Explicit typing ensures that these consuming applications can handle these > values > appropriately and also makes the information modeller think about how these > types are to be used. > > The examples you cite: > > - ingressPort > - egressPort > - packetCount > - byteCount > - sourceAS > - destinationAS > - nextHopAS > - droppedPacketCount > - samplingInterval > - droppedByteCount > > fall into a few categories, identifiers (such as ports and AS's), counts > and intervals. > > For the identifiers, I believe the size is fixed by the relevant RFC's > (i.e. why would I > have a 1 byte Port?). For counts, the use of 32 vs. 64 bits is a valid > question, however > these can be handled by making them explicit (i.e. the information model > says if > I get this value it is a 32-bit quantity or a 64-bit quantity and the code > will address > it accordingly). For intervals, the resolution would determine which size > is most > appropriate. > > > For AS the size could be 2 or 4 bytes. > You may prefer to use a 1 byte port if you are a small system as against a 4 > byte for > a gigantic system. Both have their own implementation reasons. > > > The option always exist to define variations on these data items > explicitly. E.g. > byteCount32 and byteCount64. > > > Yes. But is'nt this not more of an overhead to introduce new field type as > the requirements > come in and then make sure that it gets deployed in exporter and collector? > > > > If there is a need to vary the sizes for various fields I'd much rather > see the rationale > for each discrete sizing made explicit vs. forcing all the downstream > consumers of this \ > information have to deal with special cases and ambiguity. > > > > This is not a special case handling as you can see that the list above > covers about > 40% of the fields defined today in the information model. It is way to > handle > ambiguity arising out of implementation differences. > > Thanks > Ganesh > > > Regards, > > Jeff Meyer > > > > > -----Original Message----- > From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com > ] > Sent: Monday, September 29, 2003 6:00 PM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] Variant Field Types. > > > Hi, > > > > The information model only > > has types for fixed length objects and variable length > > string like objects. > > > > There are a number of information element types (listed below) > > that would be better defined in terms of fixed-size run-time > > specified objects. The type variation comes due to difference > > in the size of the objects used because of an implementation, > > as demanded by the network or otherwise. > > > > The way to make this work is to use the template > > length field to determine the exact sub-type: > > > > The definitions of a variant field type can be stated as: > > > > type varUnsignedInt > > if (element.length == 1) > > type = unsignedByte > > else if (element.length <= 2) > > type = unsignedShort > > else if (element.length <= 4) > > type = unsignedInt > > else if (element.length <= 8) > > type = unsignedLong > > else type = undefined > > > > type varInt > > if (element.length == 1) > > type = byte > > else if (element.length <= 2) > > type = short > > else if (element.length <= 4) > > type = int > > else if (element.length <= 8) > > type = long > > else type = undefined > > > > The candidates that fit into the description above are (I may > > have missed some also): > > - ingressPort > > - egressPort > > - packetCount > > - byteCount > > - sourceAS > > - destinationAS > > - nextHopAS > > - droppedPacketCount > > - samplingInterval > > - droppedByteCount > > > > Please comment. > > > > Thanks > > Ganesh > > > > -- 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 Oct 1 14:56: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 OAA28551 for ; Wed, 1 Oct 2003 14:56:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A4loU-0002aZ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Oct 2003 13:35:02 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A4loT-0002Zw-00 for ipfix@net.doit.wisc.edu; Wed, 01 Oct 2003 13:35:01 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Oct 2003 11:34:47 -0700 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h91IYwXg007112; Wed, 1 Oct 2003 11:34:58 -0700 (PDT) Received: from cisco.com (sjc-vpn2-1010.cisco.com [10.21.115.242]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA12426; Wed, 1 Oct 2003 11:34:56 -0700 (PDT) Message-ID: <3F7B1E50.6070207@cisco.com> Date: Wed, 01 Oct 2003 11:34:56 -0700 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Fullmer CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. References: <1D3D2C371FCBD947A7897FABBD3533A502960336@xsun01.ptp.hp.com> <20031001111555.A39319@net.ohio-state.edu> Content-Type: multipart/alternative; boundary="------------040909060304080807030802" Precedence: bulk Sender: majordomo listserver --------------040909060304080807030802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark, Mark Fullmer wrote: >I'm in favor of setting upper bounds, for example counters don't go > I agree that a field even if variable in length is limited by an upper bound and this is limit is set on a case by case basis. The whole point of my first e-mail is rather than nailing a field to an explicit type like uint64_t, to let implementors know that they can send/receive these fields in smaller sizes too. >past 64 bits. If you don't do this, what's a collector to do with say >a 72 bit counter? You can't store it in a uint_64_t anymore so collectors >would have to implement arbitrary precision arithmetic to handle potential >cases. I don't think this is reasonable to impose on the collectors. > >The issue I have with the variable length fields as currently specified >is the potential for template explosion. If a template has 8 >counters, each of which could be 1..8 byte then you have >8^8 potential templates for that one stream of flows. > Yes a separate template is needed for varying length. Template explosion because if this would be an implementation choice rather than that imposed by the definition itself. Also the same would have happened if we explicitly define field types for the counters of varying length. Thanks Ganesh > >I was hoping for the sake of the collectors we could keep the active >templates down to something < 64K so a template lookup could be done >with an index instead of a hash. > >mark > >On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > >>Ganesh, >> >> I'm not clear on how this benefits the collector. Tal and myself produce >>different implementations of carrier deployed products which collect from >>100's of devices and dozens of protocols, perhaps our experience here is >>worth something, and it tells us variant is undesireable on the collector... >> >> Regarding your other point: >> >>One way to solve this problem is if the collector assumes the largest size >>for >>computations? >> >> This was my point in the e-mail to Stewart. Have the information model be >>EXPLICIT about what is the largest size which is being modeled for a data >>item and declare it. Allow the exporter to declare a smaller size in the >>template, if the exporter knows that an individual record will always be >>accomodated (based on its implementation) in the smaller size. >> >> So for instance this might say that byteCount should be declared in the >>information model as a 64-bit int, while AS is probably sufficient at >>32-bits. >> >> This accomodates the: >> exporter - can use smaller size if known >> n/w - can reduce BW if know a smaller size is used >> info model - explicit is better than "vague" >> collector - addresses persistence and aggregation issues >> >> Can we call this a compromise? >> >>Regards, >> >> Jeff Meyer >> >>-----Original Message----- >>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >>Sent: Tuesday, September 30, 2003 10:45 AM >>To: MEYER,JEFFREY D (HP-Cupertino,ex1) >>Cc: ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] Variant Field Types. >> >> >> >> >>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >> >> >>Hi, >> >> Although the use of variant types may seem convenient from the perspective >>of an >>exporter, I think the various consumers of the data would benefit from >>sticking with >>an explicit type system. >> >>It would benefit the exporter, the n/w, flexibility of interpretation of >>fields in the >>information model and the collector. >> >> >> >> Consider operations which involve summing fields, storing them to a DB, >>etc. >> >>One way to solve this problem is if the collector assumes the largest size >>for >>computations? >> >> >> >> Explicit typing ensures that these consuming applications can handle these >>values >>appropriately and also makes the information modeller think about how these >>types are to be used. >> >> The examples you cite: >> >>- ingressPort >>- egressPort >>- packetCount >>- byteCount >>- sourceAS >>- destinationAS >>- nextHopAS >>- droppedPacketCount >>- samplingInterval >>- droppedByteCount >> >> fall into a few categories, identifiers (such as ports and AS's), counts >>and intervals. >> >> For the identifiers, I believe the size is fixed by the relevant RFC's >>(i.e. why would I >>have a 1 byte Port?). For counts, the use of 32 vs. 64 bits is a valid >>question, however >>these can be handled by making them explicit (i.e. the information model >>says if >>I get this value it is a 32-bit quantity or a 64-bit quantity and the code >>will address >>it accordingly). For intervals, the resolution would determine which size >>is most >>appropriate. >> >> >>For AS the size could be 2 or 4 bytes. >>You may prefer to use a 1 byte port if you are a small system as against a 4 >>byte for >>a gigantic system. Both have their own implementation reasons. >> >> >> The option always exist to define variations on these data items >>explicitly. E.g. >>byteCount32 and byteCount64. >> >> >>Yes. But is'nt this not more of an overhead to introduce new field type as >>the requirements >>come in and then make sure that it gets deployed in exporter and collector? >> >> >> >> If there is a need to vary the sizes for various fields I'd much rather >>see the rationale >>for each discrete sizing made explicit vs. forcing all the downstream >>consumers of this \ >>information have to deal with special cases and ambiguity. >> >> >> >>This is not a special case handling as you can see that the list above >>covers about >>40% of the fields defined today in the information model. It is way to >>handle >>ambiguity arising out of implementation differences. >> >>Thanks >>Ganesh >> >> >>Regards, >> >> Jeff Meyer >> >> >> >> >>-----Original Message----- >>From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com >> ] >>Sent: Monday, September 29, 2003 6:00 PM >>To: ipfix@net.doit.wisc.edu >>Subject: [ipfix] Variant Field Types. >> >> >>Hi, >> >> >> >>The information model only >> >>has types for fixed length objects and variable length >> >>string like objects. >> >> >> >>There are a number of information element types (listed below) >> >>that would be better defined in terms of fixed-size run-time >> >>specified objects. The type variation comes due to difference >> >>in the size of the objects used because of an implementation, >> >>as demanded by the network or otherwise. >> >> >> >>The way to make this work is to use the template >> >>length field to determine the exact sub-type: >> >> >> >>The definitions of a variant field type can be stated as: >> >> >> >>type varUnsignedInt >> >> if (element.length == 1) >> >> type = unsignedByte >> >> else if (element.length <= 2) >> >> type = unsignedShort >> >> else if (element.length <= 4) >> >> type = unsignedInt >> >> else if (element.length <= 8) >> >> type = unsignedLong >> >> else type = undefined >> >> >> >>type varInt >> >> if (element.length == 1) >> >> type = byte >> >> else if (element.length <= 2) >> >> type = short >> >> else if (element.length <= 4) >> >> type = int >> >> else if (element.length <= 8) >> >> type = long >> >> else type = undefined >> >> >> >>The candidates that fit into the description above are (I may >> >>have missed some also): >> >>- ingressPort >> >>- egressPort >> >>- packetCount >> >>- byteCount >> >>- sourceAS >> >>- destinationAS >> >>- nextHopAS >> >>- droppedPacketCount >> >>- samplingInterval >> >>- droppedByteCount >> >> >> >>Please comment. >> >> >> >>Thanks >> >>Ganesh >> >> >> >> >> >> > >-- >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/ > > > --------------040909060304080807030802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark,

Mark Fullmer wrote:
I'm in favor of setting upper bounds, for example counters don't go

I agree that a field even if variable in length is limited by an upper bound and this is limit is set on a
case by case basis. The whole point of my first e-mail is rather than nailing a field to an explicit
type like uint64_t, to let implementors know that  they can send/receive these fields in smaller
sizes too.
past 64 bits.  If you don't do this, what's a collector to do with say
a 72 bit counter?  You can't store it in a uint_64_t anymore so collectors
would have to implement arbitrary precision arithmetic to handle potential
cases.  I don't think this is reasonable to impose on the collectors.

The issue I have with the variable length fields as currently specified
is the potential for template explosion.  If a template has 8
counters, each of which could be 1..8 byte then you have
8^8 potential templates for that one stream of flows.
Yes a separate template is needed for varying length. Template explosion because if this would be
an implementation choice rather than that imposed by the definition itself. Also the same would
have happened if we explicitly define field types for the counters of varying length.

Thanks
Ganesh

I was hoping for the sake of the collectors we could keep the active
templates down to something < 64K so a template lookup could be done
with an index instead of a hash.

mark

On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
  
Ganesh,
 
  I'm not clear on how this benefits the collector.  Tal and myself produce
different implementations of carrier deployed products which collect from
100's of devices and dozens of protocols, perhaps our experience here is
worth something, and it tells us variant is undesireable on the collector...
 
  Regarding your other point:
 
One way to solve this problem is if the collector assumes the largest size
for 
computations?
 
  This was my point in the e-mail to Stewart.  Have the information model be
EXPLICIT about what is the largest size which is being modeled for a data
item and declare it.  Allow the exporter to declare a smaller size in the
template, if the exporter knows that an individual record will always be
accomodated (based on its implementation) in the smaller size.
 
  So for instance this might say that byteCount should be declared in the
information model as a 64-bit int, while AS is probably sufficient at
32-bits.
 
  This accomodates the:
      exporter - can use smaller size if known
      n/w - can reduce BW if know a smaller size is used
      info model - explicit is better than "vague"
      collector - addresses persistence and aggregation issues
 
  Can we call this a compromise?
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, September 30, 2003 10:45 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Variant Field Types.




MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:


Hi,
 
  Although the use of variant types may seem convenient from the perspective
of an
exporter, I think the various consumers of the data would benefit from
sticking with
an explicit type system.

It would benefit the exporter, the n/w, flexibility of interpretation of
fields in the 
information model  and the collector.


 
  Consider operations which involve summing fields, storing them to a DB,
etc.

One way to solve this problem is if the collector assumes the largest size
for 
computations?


 
  Explicit typing ensures that these consuming applications can handle these
values
appropriately and also makes the information modeller think about how these 
types are to be used.
 
  The examples you cite:
 
- ingressPort 
- egressPort 
- packetCount 
- byteCount 
- sourceAS 
- destinationAS
- nextHopAS 
- droppedPacketCount
- samplingInterval
- droppedByteCount
 
  fall into a few categories, identifiers (such as ports and AS's), counts
and intervals.
 
  For the identifiers, I believe the size is fixed by the relevant RFC's
(i.e. why would I 
have a 1 byte Port?).  For counts, the use of 32 vs. 64 bits is a valid
question, however
these can be handled by making them explicit (i.e. the information model
says if
I get this value it is a 32-bit quantity or a 64-bit quantity and the code
will address
it accordingly).  For intervals, the resolution would determine which size
is most
appropriate.
 

For AS the size could be 2 or 4 bytes.
You may prefer to use a 1 byte port if you are a small system as against a 4
byte for 
a gigantic system. Both have their own implementation reasons.


  The option always exist to define variations on these data items
explicitly.  E.g.
byteCount32 and byteCount64.
 

Yes. But is'nt this not more of an overhead to introduce new field type as
the requirements
come in and then make sure that it gets deployed in exporter and collector?



  If there is a need to vary the sizes for various fields I'd much rather
see the rationale
for each discrete sizing made explicit vs. forcing all the downstream
consumers of this \
information have to deal with special cases and ambiguity.
 
 

This is not a special case handling as you can see that the list above
covers about 
40% of the fields defined today in the information model. It is way to
handle 
ambiguity arising out of implementation differences.

Thanks
Ganesh


Regards,
 
  Jeff Meyer


  

-----Original Message-----
From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com
<mailto:gsadasiv@cisco.com> ]
Sent: Monday, September 29, 2003 6:00 PM
To: ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu> 
Subject: [ipfix] Variant Field Types.


Hi,



The information model <draft-ietf-ipfix-info-01.txt> only

has types for fixed length objects and variable length 

string like objects.



There are a number of information element types (listed below)

that would be better defined in terms of fixed-size run-time

specified objects. The type variation comes due to difference

in the size of the objects used because of an implementation,

as demanded by the network or otherwise.



The way to make this work is to use the template

length field to determine the exact sub-type:



The definitions of a variant field type can be stated as:



type varUnsignedInt

    if (element.length == 1)

         type = unsignedByte

    else if (element.length <= 2)

         type = unsignedShort

    else if (element.length <= 4)

         type = unsignedInt

    else if (element.length <= 8)

         type = unsignedLong

   else type = undefined



type varInt

    if (element.length == 1)

         type = byte

    else if (element.length <= 2)

         type = short

    else if (element.length <= 4)

         type = int

    else if (element.length <= 8)

         type = long

   else type = undefined



The candidates that fit into the description above are (I may

have missed some also):

- ingressPort 

- egressPort 

- packetCount 

- byteCount 

- sourceAS 

- destinationAS

- nextHopAS 

- droppedPacketCount

- samplingInterval

- droppedByteCount



Please comment.



Thanks

Ganesh

    


    

--
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/

--------------040909060304080807030802-- -- 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 Oct 1 15:19:04 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 PAA00375 for ; Wed, 1 Oct 2003 15:19:03 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A4mCY-0003Pm-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Oct 2003 13:59:54 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A4mCW-0003Ph-00 for ipfix@net.doit.wisc.edu; Wed, 01 Oct 2003 13:59:52 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id 597CA1C01677; Wed, 1 Oct 2003 14:59:52 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 52C3D1C000BF; Wed, 1 Oct 2003 14:59:52 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 1 Oct 2003 14:59:52 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296033C@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Ganesh Sadasivan'" , Mark Fullmer Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Variant Field Types. Date: Wed, 1 Oct 2003 14:59:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3884E.2DA74770" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3884E.2DA74770 Content-Type: text/plain; charset="iso-8859-1" Hi, I think the details of using smaller encoding in an implementation belong in the protocol specification vs. the information model. The information model already references the protocol specification for how fields of a given type are encoded. For specific fields, there is still a decision on what would be the maximal type. E.g. do ports need to be 32-bit or 16? Do AS numbers need to be 32 or 64? Given the unit of measure for SampleInterval, what is its limit? These details would go in the information model. Regards, Jeff Meyer -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Wednesday, October 01, 2003 11:35 AM To: Mark Fullmer Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. Mark, Mark Fullmer wrote: I'm in favor of setting upper bounds, for example counters don't go I agree that a field even if variable in length is limited by an upper bound and this is limit is set on a case by case basis. The whole point of my first e-mail is rather than nailing a field to an explicit type like uint64_t, to let implementors know that they can send/receive these fields in smaller sizes too. past 64 bits. If you don't do this, what's a collector to do with say a 72 bit counter? You can't store it in a uint_64_t anymore so collectors would have to implement arbitrary precision arithmetic to handle potential cases. I don't think this is reasonable to impose on the collectors. The issue I have with the variable length fields as currently specified is the potential for template explosion. If a template has 8 counters, each of which could be 1..8 byte then you have 8^8 potential templates for that one stream of flows. Yes a separate template is needed for varying length. Template explosion because if this would be an implementation choice rather than that imposed by the definition itself. Also the same would have happened if we explicitly define field types for the counters of varying length. Thanks Ganesh I was hoping for the sake of the collectors we could keep the active templates down to something < 64K so a template lookup could be done with an index instead of a hash. mark On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: Ganesh, I'm not clear on how this benefits the collector. Tal and myself produce different implementations of carrier deployed products which collect from 100's of devices and dozens of protocols, perhaps our experience here is worth something, and it tells us variant is undesireable on the collector... Regarding your other point: One way to solve this problem is if the collector assumes the largest size for computations? This was my point in the e-mail to Stewart. Have the information model be EXPLICIT about what is the largest size which is being modeled for a data item and declare it. Allow the exporter to declare a smaller size in the template, if the exporter knows that an individual record will always be accomodated (based on its implementation) in the smaller size. So for instance this might say that byteCount should be declared in the information model as a 64-bit int, while AS is probably sufficient at 32-bits. This accomodates the: exporter - can use smaller size if known n/w - can reduce BW if know a smaller size is used info model - explicit is better than "vague" collector - addresses persistence and aggregation issues Can we call this a compromise? Regards, Jeff Meyer -----Original Message----- From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com ] Sent: Tuesday, September 30, 2003 10:45 AM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: Hi, Although the use of variant types may seem convenient from the perspective of an exporter, I think the various consumers of the data would benefit from sticking with an explicit type system. It would benefit the exporter, the n/w, flexibility of interpretation of fields in the information model and the collector. Consider operations which involve summing fields, storing them to a DB, etc. One way to solve this problem is if the collector assumes the largest size for computations? Explicit typing ensures that these consuming applications can handle these values appropriately and also makes the information modeller think about how these types are to be used. The examples you cite: - ingressPort - egressPort - packetCount - byteCount - sourceAS - destinationAS - nextHopAS - droppedPacketCount - samplingInterval - droppedByteCount fall into a few categories, identifiers (such as ports and AS's), counts and intervals. For the identifiers, I believe the size is fixed by the relevant RFC's (i.e. why would I have a 1 byte Port?). For counts, the use of 32 vs. 64 bits is a valid question, however these can be handled by making them explicit (i.e. the information model says if I get this value it is a 32-bit quantity or a 64-bit quantity and the code will address it accordingly). For intervals, the resolution would determine which size is most appropriate. For AS the size could be 2 or 4 bytes. You may prefer to use a 1 byte port if you are a small system as against a 4 byte for a gigantic system. Both have their own implementation reasons. The option always exist to define variations on these data items explicitly. E.g. byteCount32 and byteCount64. Yes. But is'nt this not more of an overhead to introduce new field type as the requirements come in and then make sure that it gets deployed in exporter and collector? If there is a need to vary the sizes for various fields I'd much rather see the rationale for each discrete sizing made explicit vs. forcing all the downstream consumers of this \ information have to deal with special cases and ambiguity. This is not a special case handling as you can see that the list above covers about 40% of the fields defined today in the information model. It is way to handle ambiguity arising out of implementation differences. Thanks Ganesh Regards, Jeff Meyer -----Original Message----- From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com ] Sent: Monday, September 29, 2003 6:00 PM To: ipfix@net.doit.wisc.edu Subject: [ipfix] Variant Field Types. Hi, The information model only has types for fixed length objects and variable length string like objects. There are a number of information element types (listed below) that would be better defined in terms of fixed-size run-time specified objects. The type variation comes due to difference in the size of the objects used because of an implementation, as demanded by the network or otherwise. The way to make this work is to use the template length field to determine the exact sub-type: The definitions of a variant field type can be stated as: type varUnsignedInt if (element.length == 1) type = unsignedByte else if (element.length <= 2) type = unsignedShort else if (element.length <= 4) type = unsignedInt else if (element.length <= 8) type = unsignedLong else type = undefined type varInt if (element.length == 1) type = byte else if (element.length <= 2) type = short else if (element.length <= 4) type = int else if (element.length <= 8) type = long else type = undefined The candidates that fit into the description above are (I may have missed some also): - ingressPort - egressPort - packetCount - byteCount - sourceAS - destinationAS - nextHopAS - droppedPacketCount - samplingInterval - droppedByteCount Please comment. Thanks Ganesh -- 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/ ------_=_NextPart_001_01C3884E.2DA74770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 =20 I think the details of using smaller encoding in an implementation = belong in the=20 protocol specification vs. the information model.  The information = model=20 already references the protocol specification for how fields of a given = type are=20 encoded.
 
 =20 For specific fields, there is still a decision on what would be the = maximal=20 type.  E.g. do ports need to be 32-bit or 16?  Do AS numbers = need to=20 be 32 or 64?  Given the unit of measure for SampleInterval, what = is its=20 limit?  These details would go in the information=20 model.
 
Regards,
 
 =20 Jeff Meyer
-----Original Message-----
From: Ganesh Sadasivan=20 [mailto:gsadasiv@cisco.com]
Sent: Wednesday, October 01, = 2003 11:35=20 AM
To: Mark Fullmer
Cc: MEYER,JEFFREY D=20 (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu
Subject: Re: = [ipfix]=20 Variant Field Types.

Mark,

Mark Fullmer = wrote:
I'm in favor of setting upper bounds, for =
example counters don't go

I=20 agree that a field even if variable in length is limited by an upper = bound and=20 this is limit is set on a
case by case basis. The whole point of = my first=20 e-mail is rather than nailing a field to an explicit
type like = uint64_t, to=20 let implementors know that  they can send/receive these fields = in=20 smaller
sizes too.
past 64 bits.  If you don't do this, =
what's a collector to do with say
a 72 bit counter?  You can't store it in a uint_64_t anymore so =
collectors
would have to implement arbitrary precision arithmetic to handle =
potential
cases.  I don't think this is reasonable to impose on the collectors.

The issue I have with the variable length fields as currently specified
is the potential for template explosion.  If a template has 8
counters, each of which could be 1..8 byte then you have
8^8 potential templates for that one stream of =
flows.
Yes a=20 separate template is needed for varying length. Template explosion = because if=20 this would be
an implementation choice rather than that imposed by = the=20 definition itself. Also the same would
have happened if we = explicitly=20 define field types for the counters of varying length.=20

Thanks
Ganesh
I was hoping for the sake of the collectors we could keep the active
templates down to something < 64K so a template lookup could be done
with an index instead of a hash.

mark

On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D =
(HP-Cupertino,ex1) wrote:
  
Ganesh,
=20
  I'm not clear on how this benefits the collector.  Tal and myself =
produce
different implementations of carrier deployed products which collect =
from
100's of devices and dozens of protocols, perhaps our experience here =
is
worth something, and it tells us variant is undesireable on the =
collector...
=20
  Regarding your other point:
=20
One way to solve this problem is if the collector assumes the largest =
size
for=20
computations?
=20
  This was my point in the e-mail to Stewart.  Have the information =
model be
EXPLICIT about what is the largest size which is being modeled for a =
data
item and declare it.  Allow the exporter to declare a smaller size in =
the
template, if the exporter knows that an individual record will always =
be
accomodated (based on its implementation) in the smaller size.
=20
  So for instance this might say that byteCount should be declared in =
the
information model as a 64-bit int, while AS is probably sufficient at
32-bits.
=20
  This accomodates the:
      exporter - can use smaller size if known
      n/w - can reduce BW if know a smaller size is used
      info model - explicit is better than "vague"
      collector - addresses persistence and aggregation issues
=20
  Can we call this a compromise?
=20
Regards,
=20
  Jeff Meyer

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Tuesday, September 30, 2003 10:45 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Variant Field Types.




MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:


Hi,
=20
  Although the use of variant types may seem convenient from the =
perspective
of an
exporter, I think the various consumers of the data would benefit from
sticking with
an explicit type system.

It would benefit the exporter, the n/w, flexibility of interpretation =
of
fields in the=20
information model  and the collector.


=20
  Consider operations which involve summing fields, storing them to a =
DB,
etc.

One way to solve this problem is if the collector assumes the largest =
size
for=20
computations?


=20
  Explicit typing ensures that these consuming applications can handle =
these
values
appropriately and also makes the information modeller think about how =
these=20
types are to be used.
=20
  The examples you cite:
=20
- ingressPort=20
- egressPort=20
- packetCount=20
- byteCount=20
- sourceAS=20
- destinationAS
- nextHopAS=20
- droppedPacketCount
- samplingInterval
- droppedByteCount
=20
  fall into a few categories, identifiers (such as ports and AS's), =
counts
and intervals.
=20
  For the identifiers, I believe the size is fixed by the relevant =
RFC's
(i.e. why would I=20
have a 1 byte Port?).  For counts, the use of 32 vs. 64 bits is a valid
question, however
these can be handled by making them explicit (i.e. the information =
model
says if
I get this value it is a 32-bit quantity or a 64-bit quantity and the =
code
will address
it accordingly).  For intervals, the resolution would determine which =
size
is most
appropriate.
=20

For AS the size could be 2 or 4 bytes.
You may prefer to use a 1 byte port if you are a small system as =
against a 4
byte for=20
a gigantic system. Both have their own implementation reasons.


  The option always exist to define variations on these data items
explicitly.  E.g.
byteCount32 and byteCount64.
=20

Yes. But is'nt this not more of an overhead to introduce new field type =
as
the requirements
come in and then make sure that it gets deployed in exporter and =
collector?



  If there is a need to vary the sizes for various fields I'd much =
rather
see the rationale
for each discrete sizing made explicit vs. forcing all the downstream
consumers of this \
information have to deal with special cases and ambiguity.
=20
=20

This is not a special case handling as you can see that the list above
covers about=20
40% of the fields defined today in the information model. It is way to
handle=20
ambiguity arising out of implementation differences.

Thanks
Ganesh


Regards,
=20
  Jeff Meyer


 =20

-----Original Message-----
From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com
<mailto:gsadasiv@cisco.com>=
 ]
Sent: Monday, September 29, 2003 6:00 PM
To: ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.e=
du>=20
Subject: [ipfix] Variant Field Types.


Hi,



The information model <draft-ietf-ipfix-info-01.txt> only

has types for fixed length objects and variable length=20

string like objects.



There are a number of information element types (listed below)

that would be better defined in terms of fixed-size run-time

specified objects. The type variation comes due to difference

in the size of the objects used because of an implementation,

as demanded by the network or otherwise.



The way to make this work is to use the template

length field to determine the exact sub-type:



The definitions of a variant field type can be stated as:



type varUnsignedInt

    if (element.length =3D=3D 1)

         type =3D unsignedByte

    else if (element.length <=3D 2)

         type =3D unsignedShort

    else if (element.length <=3D 4)

         type =3D unsignedInt

    else if (element.length <=3D 8)

         type =3D unsignedLong

   else type =3D undefined



type varInt

    if (element.length =3D=3D 1)

         type =3D byte

    else if (element.length <=3D 2)

         type =3D short

    else if (element.length <=3D 4)

         type =3D int

    else if (element.length <=3D 8)

         type =3D long

   else type =3D undefined



The candidates that fit into the description above are (I may

have missed some also):

- ingressPort=20

- egressPort=20

- packetCount=20

- byteCount=20

- sourceAS=20

- destinationAS

- nextHopAS=20

- droppedPacketCount

- samplingInterval

- droppedByteCount



Please comment.



Thanks

Ganesh

   =20


    

--
Help        mailto:majordomo@net.doit.wi=
sc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/=
archive/

------_=_NextPart_001_01C3884E.2DA74770-- -- 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 Oct 2 13:11:13 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 NAA11028 for ; Thu, 2 Oct 2003 13:11:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A56Wa-0001YM-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 11:41:56 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A56WZ-0001YA-00; Thu, 02 Oct 2003 11:41:55 -0500 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92Gfqb25653; Thu, 2 Oct 2003 09:41:52 -0700 (PDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92Gfo120421; Thu, 2 Oct 2003 11:41:50 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 09:41:50 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F930218F24A@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: [ipfix] Ipfix Protocol open items Date: Thu, 2 Oct 2003 09:41:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38904.12381C4C" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38904.12381C4C Content-Type: text/plain; charset="ISO-8859-1" Hello, Have we zeroed in a certain transport protocol? TCP, SCTP-PR or something else? I need to write something to explain how Netflow runs over TCP, but it seems to me somewhat of a lower priority if this is not going to be the default protocol. We should focus on explaning how this should work on the "choosen one". There were also several open items like packet length (size of field, does it replaces the count header, etc, etc). Template management, etc Periodic issue of counts per record/template/etc to ensure we know how many records we lost. It seems to me one of those discussions that die out and we never reach a conclusion. We should have a new version of the protocol draft soon. Can we start reaally reaching a consensus on these things? I'll talk offline with the other editors and send a list of open issue so we can tackle them on by one. Regards, Reinaldo ------_=_NextPart_001_01C38904.12381C4C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Ipfix Protocol open items

Hello,

Have we zeroed in a certain transport protocol? TCP, = SCTP-PR or something else?

I need to write something to explain how Netflow runs = over TCP, but it seems to me somewhat of a lower priority if this is = not going to be the default protocol. We should focus on explaning how = this should work on the "choosen one".

There were also several open items like packet length = (size of field, does it replaces the count header, etc, etc).
Template management, etc
Periodic issue of counts per record/template/etc to = ensure we know how many records we lost.

It seems to me one of those discussions that die out = and we never reach a conclusion. We should have a new version of the = protocol draft soon. Can we start reaally reaching a consensus on these = things?

I'll talk offline with the other editors and send a = list of open issue so we can tackle them on by one.


Regards,

Reinaldo

------_=_NextPart_001_01C38904.12381C4C-- -- 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 Oct 2 13:40:08 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 NAA15467 for ; Thu, 2 Oct 2003 13:40:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A571g-0002g7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 12:14:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A571f-0002g2-00; Thu, 02 Oct 2003 12:14:03 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2003 19:12:28 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h92HDwUX025319; Thu, 2 Oct 2003 19:13:58 +0200 (MET DST) Received: from cisco.com (rtp-vpn2-263.cisco.com [10.82.241.7]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA27005; Thu, 2 Oct 2003 18:13:59 +0100 (BST) Message-ID: <3F7C5CD5.6040007@cisco.com> Date: Thu, 02 Oct 2003 18:13:57 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Ipfix Protocol open items References: <0A11633F61BD9F40B43ABCC694004F930218F24A@zsc3c026.us.nortel.com> In-Reply-To: <0A11633F61BD9F40B43ABCC694004F930218F24A@zsc3c026.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > Hello, > > Have we zeroed in a certain transport protocol? TCP, SCTP-PR or > something else? > > I need to write something to explain how Netflow runs over TCP, but it > seems to me somewhat of a lower priority if this is not going to be the > default protocol. We should focus on explaning how this should work on > the "choosen one". I think that perhaps the question should be put another way. There are WG members who propose SCTP-PR as the default, and SCTP-PR has advantage because of its better flexibility in coping with congestion. So the real question is whether there are WG members who think that the default should be TCP. If no group comes forward, then we have our answer. If there is support then we need to perform a detailed analysis of the relative merits of the two protocols. Stewart -- 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 Oct 2 13:55:40 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 NAA16594 for ; Thu, 2 Oct 2003 13:55:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A57F9-00039H-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 12:27:59 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A57F8-000395-00 for ipfix@net.doit.wisc.edu; Thu, 02 Oct 2003 12:27:58 -0500 Received: (qmail 15763 invoked from network); 2 Oct 2003 17:27:57 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 2 Oct 2003 17:27:57 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h92HRvX03302; Thu, 2 Oct 2003 13:27:57 -0400 Reply-To: From: "Carter Bullard" To: , "'Reinaldo Penno'" Cc: , Subject: [ipfix] STCP as a default transport not Date: Thu, 2 Oct 2003 13:27:54 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6A5@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CDDC4@ptah.newyork.qosient.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk Sender: majordomo listserver I believe that SCTP-PR is not deployed widely enough to be considered a default for any IETF technology. It is not on my Linux RedHat 9.0 distribution, nor my Mac OS-X or my Windows XP system. I don't see it available on any Solaris machine that I have access to. What IETF technology is currently using SCTP as a default transport? Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Stewart Bryant > Sent: Thursday, October 02, 2003 12:14 PM > To: Reinaldo Penno > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > Reinaldo Penno wrote: > > > Hello, > > > > Have we zeroed in a certain transport protocol? TCP, SCTP-PR or > > something else? > > > > I need to write something to explain how Netflow runs over > TCP, but it > > seems to me somewhat of a lower priority if this is not > going to be the > > default protocol. We should focus on explaning how this > should work on > > the "choosen one". > > I think that perhaps the question should be put another way. There are > WG members who propose SCTP-PR as the default, and SCTP-PR has > advantage because of its better flexibility in coping with congestion. > > So the real question is whether there are WG members who think that > the default should be TCP. If no group comes forward, then we have > our answer. If there is support then we need to perform a detailed > analysis of the relative merits of the two protocols. > > Stewart > > > -- > 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 Oct 2 13:57: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 NAA16737 for ; Thu, 2 Oct 2003 13:57:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A57JA-0003EB-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 12:32:08 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A57J9-0003E5-00; Thu, 02 Oct 2003 12:32:07 -0500 Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel12.hp.com (Postfix) with ESMTP id 8BAF51C01D5A; Thu, 2 Oct 2003 10:32:06 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id 821841004BB7; Thu, 2 Oct 2003 10:32:06 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 2 Oct 2003 10:32:06 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960354@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'stbryant@cisco.com'" , Reinaldo Penno Cc: ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Ipfix Protocol open items Date: Thu, 2 Oct 2003 10:32:03 -0700 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, Given the ubiquity of TCP and the challenge of using SCTP "out of the box" on many platforms, I would strongly recommend making TCP the default. I am not aware of Microsoft support for SCTP, nor support on the Java platform. My understanding of some of the experience w/ Diameter interoperability sessions, is that TCP was the dominant transport, even though Diameter calls out both SCTP and TCP as required protocols. An alternative view would be that building more on top of SCTP will drive more adoption and help address the "out of the box" issue. I'm a bit skeptical on this point, since SCTP seems more kernel space than user space, it will be more challenging to get OS and JVM vendors to quickly support it. Regards, Jeff Meyer > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, October 02, 2003 10:14 AM > To: Reinaldo Penno > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > Reinaldo Penno wrote: > > > Hello, > > > > Have we zeroed in a certain transport protocol? TCP, SCTP-PR or > > something else? > > > > I need to write something to explain how Netflow runs over > TCP, but it > > seems to me somewhat of a lower priority if this is not > going to be the > > default protocol. We should focus on explaning how this > should work on > > the "choosen one". > > I think that perhaps the question should be put another way. There are > WG members who propose SCTP-PR as the default, and SCTP-PR has > advantage because of its better flexibility in coping with congestion. > > So the real question is whether there are WG members who think that > the default should be TCP. If no group comes forward, then we have > our answer. If there is support then we need to perform a detailed > analysis of the relative merits of the two protocols. > > Stewart > > > -- > 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 Oct 2 15:24: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 PAA22084 for ; Thu, 2 Oct 2003 15:24:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A58jS-0006Zn-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 14:03:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A58jR-0006Zi-00 for ipfix@net.doit.wisc.edu; Thu, 02 Oct 2003 14:03:21 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 02 Oct 2003 12:09:00 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h92J3G01025115; Thu, 2 Oct 2003 15:03:16 -0400 (EDT) Received: from cisco.com (rtp-vpn2-263.cisco.com [10.82.241.7]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA01829; Thu, 2 Oct 2003 20:03:13 +0100 (BST) Message-ID: <3F7C7670.4050408@cisco.com> Date: Thu, 02 Oct 2003 20:03:12 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Ganesh Sadasivan'" , Mark Fullmer , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. References: <1D3D2C371FCBD947A7897FABBD3533A50296033C@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A50296033C@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff Whether the size reduction fits in the IM or in the protocol draft depends on how closely you see the drafts mapping onto the structure of the implementation. Ultimately the exporter and the collector have to have the same shared IM, including knowledge of the object size that the exporter is actually using. One obvious example is counter wrapping (there may be others). Lets say IM defines a 16 bit counter object, and the collector uses this to interpret the data it receives from the exporter. The exporter on the other hand reduces this to 8 bits. The sequence 7,8,0 means quite different things to each party. In the case above the exporter saw 9 object and the collector thought there had been 17. The collector can only correctly determine what ocured if it knows that the exporter is using the abbreviated size. Now you could regard the use of a different size as a protocol matter i.e. compression is being applied to the data, but to get the correct shared semantics, the protocol engine now has to be aware of the true semantics of IEs rather than just passing them up as abstract objects. Therefore I would think that the part of the system that understands the IEs needs to be aware of the size that the exporter is using, and this leads me to conclude that we might as well describe the size behavior in the IM. Stewart MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > Hi, > > I think the details of using smaller encoding in an implementation > belong in the protocol specification vs. the information model. The > information model already references the protocol specification for how > fields of a given type are encoded. > > For specific fields, there is still a decision on what would be the > maximal type. E.g. do ports need to be 32-bit or 16? Do AS numbers > need to be 32 or 64? Given the unit of measure for SampleInterval, what > is its limit? These details would go in the information model. > > Regards, > > Jeff Meyer > > -----Original Message----- > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > Sent: Wednesday, October 01, 2003 11:35 AM > To: Mark Fullmer > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Variant Field Types. > > Mark, > > Mark Fullmer wrote: > >>I'm in favor of setting upper bounds, for example counters don't go > > > I agree that a field even if variable in length is limited by an > upper bound and this is limit is set on a > case by case basis. The whole point of my first e-mail is rather > than nailing a field to an explicit > type like uint64_t, to let implementors know that they can > send/receive these fields in smaller > sizes too. > >>past 64 bits. If you don't do this, what's a collector to do with say >>a 72 bit counter? You can't store it in a uint_64_t anymore so collectors >>would have to implement arbitrary precision arithmetic to handle potential >>cases. I don't think this is reasonable to impose on the collectors. >> >>The issue I have with the variable length fields as currently specified >>is the potential for template explosion. If a template has 8 >>counters, each of which could be 1..8 byte then you have >>8^8 potential templates for that one stream of flows. > > Yes a separate template is needed for varying length. Template > explosion because if this would be > an implementation choice rather than that imposed by the definition > itself. Also the same would > have happened if we explicitly define field types for the counters > of varying length. > > Thanks > Ganesh > >>I was hoping for the sake of the collectors we could keep the active >>templates down to something < 64K so a template lookup could be done >>with an index instead of a hash. >> >>mark >> >>On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >> >> >>>Ganesh, >>> >>> I'm not clear on how this benefits the collector. Tal and myself produce >>>different implementations of carrier deployed products which collect from >>>100's of devices and dozens of protocols, perhaps our experience here is >>>worth something, and it tells us variant is undesireable on the collector... >>> >>> Regarding your other point: >>> >>>One way to solve this problem is if the collector assumes the largest size >>>for >>>computations? >>> >>> This was my point in the e-mail to Stewart. Have the information model be >>>EXPLICIT about what is the largest size which is being modeled for a data >>>item and declare it. Allow the exporter to declare a smaller size in the >>>template, if the exporter knows that an individual record will always be >>>accomodated (based on its implementation) in the smaller size. >>> >>> So for instance this might say that byteCount should be declared in the >>>information model as a 64-bit int, while AS is probably sufficient at >>>32-bits. >>> >>> This accomodates the: >>> exporter - can use smaller size if known >>> n/w - can reduce BW if know a smaller size is used >>> info model - explicit is better than "vague" >>> collector - addresses persistence and aggregation issues >>> >>> Can we call this a compromise? >>> >>>Regards, >>> >>> Jeff Meyer >>> >>>-----Original Message----- >>>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >>>Sent: Tuesday, September 30, 2003 10:45 AM >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) >>>Cc: ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] Variant Field Types. >>> >>> >>> >>> >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >>> >>> >>>Hi, >>> >>> Although the use of variant types may seem convenient from the perspective >>>of an >>>exporter, I think the various consumers of the data would benefit from >>>sticking with >>>an explicit type system. >>> >>>It would benefit the exporter, the n/w, flexibility of interpretation of >>>fields in the >>>information model and the collector. >>> >>> >>> >>> Consider operations which involve summing fields, storing them to a DB, >>>etc. >>> >>>One way to solve this problem is if the collector assumes the largest size >>>for >>>computations? >>> >>> >>> >>> Explicit typing ensures that these consuming applications can handle these >>>values >>>appropriately and also makes the information modeller think about how these >>>types are to be used. >>> >>> The examples you cite: >>> >>>- ingressPort >>>- egressPort >>>- packetCount >>>- byteCount >>>- sourceAS >>>- destinationAS >>>- nextHopAS >>>- droppedPacketCount >>>- samplingInterval >>>- droppedByteCount >>> >>> fall into a few categories, identifiers (such as ports and AS's), counts >>>and intervals. >>> >>> For the identifiers, I believe the size is fixed by the relevant RFC's >>>(i.e. why would I >>>have a 1 byte Port?). For counts, the use of 32 vs. 64 bits is a valid >>>question, however >>>these can be handled by making them explicit (i.e. the information model >>>says if >>>I get this value it is a 32-bit quantity or a 64-bit quantity and the code >>>will address >>>it accordingly). For intervals, the resolution would determine which size >>>is most >>>appropriate. >>> >>> >>>For AS the size could be 2 or 4 bytes. >>>You may prefer to use a 1 byte port if you are a small system as against a 4 >>>byte for >>>a gigantic system. Both have their own implementation reasons. >>> >>> >>> The option always exist to define variations on these data items >>>explicitly. E.g. >>>byteCount32 and byteCount64. >>> >>> >>>Yes. But is'nt this not more of an overhead to introduce new field type as >>>the requirements >>>come in and then make sure that it gets deployed in exporter and collector? >>> >>> >>> >>> If there is a need to vary the sizes for various fields I'd much rather >>>see the rationale >>>for each discrete sizing made explicit vs. forcing all the downstream >>>consumers of this \ >>>information have to deal with special cases and ambiguity. >>> >>> >>> >>>This is not a special case handling as you can see that the list above >>>covers about >>>40% of the fields defined today in the information model. It is way to >>>handle >>>ambiguity arising out of implementation differences. >>> >>>Thanks >>>Ganesh >>> >>> >>>Regards, >>> >>> Jeff Meyer >>> >>> >>> >>> >>>-----Original Message----- >>>From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com >>> ] >>>Sent: Monday, September 29, 2003 6:00 PM >>>To: ipfix@net.doit.wisc.edu >>>Subject: [ipfix] Variant Field Types. >>> >>> >>>Hi, >>> >>> >>> >>>The information model only >>> >>>has types for fixed length objects and variable length >>> >>>string like objects. >>> >>> >>> >>>There are a number of information element types (listed below) >>> >>>that would be better defined in terms of fixed-size run-time >>> >>>specified objects. The type variation comes due to difference >>> >>>in the size of the objects used because of an implementation, >>> >>>as demanded by the network or otherwise. >>> >>> >>> >>>The way to make this work is to use the template >>> >>>length field to determine the exact sub-type: >>> >>> >>> >>>The definitions of a variant field type can be stated as: >>> >>> >>> >>>type varUnsignedInt >>> >>> if (element.length == 1) >>> >>> type = unsignedByte >>> >>> else if (element.length <= 2) >>> >>> type = unsignedShort >>> >>> else if (element.length <= 4) >>> >>> type = unsignedInt >>> >>> else if (element.length <= 8) >>> >>> type = unsignedLong >>> >>> else type = undefined >>> >>> >>> >>>type varInt >>> >>> if (element.length == 1) >>> >>> type = byte >>> >>> else if (element.length <= 2) >>> >>> type = short >>> >>> else if (element.length <= 4) >>> >>> type = int >>> >>> else if (element.length <= 8) >>> >>> type = long >>> >>> else type = undefined >>> >>> >>> >>>The candidates that fit into the description above are (I may >>> >>>have missed some also): >>> >>>- ingressPort >>> >>>- egressPort >>> >>>- packetCount >>> >>>- byteCount >>> >>>- sourceAS >>> >>>- destinationAS >>> >>>- nextHopAS >>> >>>- droppedPacketCount >>> >>>- samplingInterval >>> >>>- droppedByteCount >>> >>> >>> >>>Please comment. >>> >>> >>> >>>Thanks >>> >>>Ganesh >>> >>> >>> >>> >>> >> >> >>-- >>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 Oct 2 16:06: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 QAA23457 for ; Thu, 2 Oct 2003 16:06:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A59To-0000aD-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 14:51:16 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A59Tn-0000a3-00; Thu, 02 Oct 2003 14:51:15 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h92Jp4XU006659; Thu, 2 Oct 2003 14:51:05 -0500 (CDT) Message-ID: <3F7C81A8.B47DC2E9@alcatel.com> Date: Thu, 02 Oct 2003 14:51:04 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: carter@qosient.com CC: stbryant@cisco.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6A5@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello Carter, If it is true that SCTP hasn't been widely deployed, it is probably because of statements like you have made below. Look, we all know SCTP has a lot of benefits over TCP. If folks like you don't drive its deployement by specifying it as default transport, how will it be ubiquitous? It is a self fulfilling prophesy. For IETF protocols that recommend SCTP as defaults, see rfc 3057, rfc 3331 and rfc 3332 just to name a few. Regards, Alex. Carter Bullard wrote: > I believe that SCTP-PR is not deployed widely enough > to be considered a default for any IETF technology. > It is not on my Linux RedHat 9.0 distribution, nor > my Mac OS-X or my Windows XP system. I don't see it > available on any Solaris machine that I have access > to. > > What IETF technology is currently using SCTP as a > default transport? > > Carter > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Stewart Bryant > > Sent: Thursday, October 02, 2003 12:14 PM > > To: Reinaldo Penno > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > Reinaldo Penno wrote: > > > > > Hello, > > > > > > Have we zeroed in a certain transport protocol? TCP, SCTP-PR or > > > something else? > > > > > > I need to write something to explain how Netflow runs over > > TCP, but it > > > seems to me somewhat of a lower priority if this is not > > going to be the > > > default protocol. We should focus on explaning how this > > should work on > > > the "choosen one". > > > > I think that perhaps the question should be put another way. There are > > WG members who propose SCTP-PR as the default, and SCTP-PR has > > advantage because of its better flexibility in coping with congestion. > > > > So the real question is whether there are WG members who think that > > the default should be TCP. If no group comes forward, then we have > > our answer. If there is support then we need to perform a detailed > > analysis of the relative merits of the two protocols. > > > > Stewart > > > > > > -- > > 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 Oct 2 16:06: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 QAA23508 for ; Thu, 2 Oct 2003 16:06:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A59bL-0000u4-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 14:59:03 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A59bK-0000tx-00 for ipfix@net.doit.wisc.edu; Thu, 02 Oct 2003 14:59:02 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id E9F141C03A22; Thu, 2 Oct 2003 15:59:01 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id DE3231C00A44; Thu, 2 Oct 2003 15:59:01 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 2 Oct 2003 15:59:01 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296035C@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'stbryant@cisco.com'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Ganesh Sadasivan'" , Mark Fullmer , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Variant Field Types. Date: Thu, 2 Oct 2003 15:58:56 -0400 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 Stewart, Counters are an interesting (and irritating) beast. Thankfully I am not aware of any currently defined in the context of IPFIX. If we do encounter these, then there should be an appropriate annotation in the IM indicating this property. My leaning would be to avoid them. The observer in the IPFIX model seems capable of delivering accurate summaries of an observed flow, vs. relying on SNMP style counters. In the case of explicit numeric quantities, i.e. "on this flow I saw this many of this thing", clearly the exporter needs to ensure that the size of its export field has sufficient capacity to accomodate the largest value it may observe. From the perspective of a collector, the maximal size should reflect the largest accumulation of this field which is expected. This would seem to lean towards int64 for most quantities. If the quantities are expected to accumulate beyond this amount, I would recommend the use of float or double. I'm not aware of much consistent support for integers > 2^64. Regards, Jeff Meyer > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, October 02, 2003 12:03 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Ganesh Sadasivan'; Mark Fullmer; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Variant Field Types. > > > Jeff > > Whether the size reduction fits in the IM or in the protocol draft > depends on how closely you see the drafts mapping onto the > structure of the implementation. > > Ultimately the exporter and the collector have to have the same > shared IM, including knowledge of the object size that the exporter > is actually using. > > One obvious example is counter wrapping (there may be others). > Lets say IM defines a 16 bit counter object, and the collector > uses this to interpret the data it receives from the exporter. The > exporter on the other hand reduces this to 8 bits. The sequence > 7,8,0 means quite different things to each party. In the case > above the exporter saw 9 object and the collector thought > there had been 17. The collector can only correctly determine > what ocured if it knows that the exporter is using the abbreviated > size. > > Now you could regard the use of a different size as a protocol matter > i.e. compression is being applied to the data, but to get the correct > shared semantics, the protocol engine now has to be aware of the > true semantics of IEs rather than just passing them up as abstract > objects. > > Therefore I would think that the part of the system that understands > the IEs needs to be aware of the size that the exporter is using, > and this leads me to conclude that we might as well describe the > size behavior in the IM. > > Stewart > > > > > > MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > > Hi, > > > > I think the details of using smaller encoding in an > implementation > > belong in the protocol specification vs. the information > model. The > > information model already references the protocol > specification for how > > fields of a given type are encoded. > > > > For specific fields, there is still a decision on what > would be the > > maximal type. E.g. do ports need to be 32-bit or 16? Do > AS numbers > > need to be 32 or 64? Given the unit of measure for > SampleInterval, what > > is its limit? These details would go in the information model. > > > > Regards, > > > > Jeff Meyer > > > > -----Original Message----- > > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > > Sent: Wednesday, October 01, 2003 11:35 AM > > To: Mark Fullmer > > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] Variant Field Types. > > > > Mark, > > > > Mark Fullmer wrote: > > > >>I'm in favor of setting upper bounds, for example counters don't go > > > > > > I agree that a field even if variable in length is limited by an > > upper bound and this is limit is set on a > > case by case basis. The whole point of my first e-mail is rather > > than nailing a field to an explicit > > type like uint64_t, to let implementors know that they can > > send/receive these fields in smaller > > sizes too. > > > >>past 64 bits. If you don't do this, what's a collector to > do with say > >>a 72 bit counter? You can't store it in a uint_64_t > anymore so collectors > >>would have to implement arbitrary precision arithmetic to > handle potential > >>cases. I don't think this is reasonable to impose on the > collectors. > >> > >>The issue I have with the variable length fields as > currently specified > >>is the potential for template explosion. If a template has 8 > >>counters, each of which could be 1..8 byte then you have > >>8^8 potential templates for that one stream of flows. > > > > Yes a separate template is needed for varying length. Template > > explosion because if this would be > > an implementation choice rather than that imposed by > the definition > > itself. Also the same would > > have happened if we explicitly define field types for > the counters > > of varying length. > > > > Thanks > > Ganesh > > > >>I was hoping for the sake of the collectors we could keep the active > >>templates down to something < 64K so a template lookup could be done > >>with an index instead of a hash. > >> > >>mark > >> > >>On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D > (HP-Cupertino,ex1) wrote: > >> > >> > >>>Ganesh, > >>> > >>> I'm not clear on how this benefits the collector. Tal > and myself produce > >>>different implementations of carrier deployed products > which collect from > >>>100's of devices and dozens of protocols, perhaps our > experience here is > >>>worth something, and it tells us variant is undesireable > on the collector... > >>> > >>> Regarding your other point: > >>> > >>>One way to solve this problem is if the collector assumes > the largest size > >>>for > >>>computations? > >>> > >>> This was my point in the e-mail to Stewart. Have the > information model be > >>>EXPLICIT about what is the largest size which is being > modeled for a data > >>>item and declare it. Allow the exporter to declare a > smaller size in the > >>>template, if the exporter knows that an individual record > will always be > >>>accomodated (based on its implementation) in the smaller size. > >>> > >>> So for instance this might say that byteCount should be > declared in the > >>>information model as a 64-bit int, while AS is probably > sufficient at > >>>32-bits. > >>> > >>> This accomodates the: > >>> exporter - can use smaller size if known > >>> n/w - can reduce BW if know a smaller size is used > >>> info model - explicit is better than "vague" > >>> collector - addresses persistence and aggregation issues > >>> > >>> Can we call this a compromise? > >>> > >>>Regards, > >>> > >>> Jeff Meyer > >>> > >>>-----Original Message----- > >>>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > >>>Sent: Tuesday, September 30, 2003 10:45 AM > >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) > >>>Cc: ipfix@net.doit.wisc.edu > >>>Subject: Re: [ipfix] Variant Field Types. > >>> > >>> > >>> > >>> > >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > >>> > >>> > >>>Hi, > >>> > >>> Although the use of variant types may seem convenient > from the perspective > >>>of an > >>>exporter, I think the various consumers of the data would > benefit from > >>>sticking with > >>>an explicit type system. > >>> > >>>It would benefit the exporter, the n/w, flexibility of > interpretation of > >>>fields in the > >>>information model and the collector. > >>> > >>> > >>> > >>> Consider operations which involve summing fields, > storing them to a DB, > >>>etc. > >>> > >>>One way to solve this problem is if the collector assumes > the largest size > >>>for > >>>computations? > >>> > >>> > >>> > >>> Explicit typing ensures that these consuming > applications can handle these > >>>values > >>>appropriately and also makes the information modeller > think about how these > >>>types are to be used. > >>> > >>> The examples you cite: > >>> > >>>- ingressPort > >>>- egressPort > >>>- packetCount > >>>- byteCount > >>>- sourceAS > >>>- destinationAS > >>>- nextHopAS > >>>- droppedPacketCount > >>>- samplingInterval > >>>- droppedByteCount > >>> > >>> fall into a few categories, identifiers (such as ports > and AS's), counts > >>>and intervals. > >>> > >>> For the identifiers, I believe the size is fixed by the > relevant RFC's > >>>(i.e. why would I > >>>have a 1 byte Port?). For counts, the use of 32 vs. 64 > bits is a valid > >>>question, however > >>>these can be handled by making them explicit (i.e. the > information model > >>>says if > >>>I get this value it is a 32-bit quantity or a 64-bit > quantity and the code > >>>will address > >>>it accordingly). For intervals, the resolution would > determine which size > >>>is most > >>>appropriate. > >>> > >>> > >>>For AS the size could be 2 or 4 bytes. > >>>You may prefer to use a 1 byte port if you are a small > system as against a 4 > >>>byte for > >>>a gigantic system. Both have their own implementation reasons. > >>> > >>> > >>> The option always exist to define variations on these data items > >>>explicitly. E.g. > >>>byteCount32 and byteCount64. > >>> > >>> > >>>Yes. But is'nt this not more of an overhead to introduce > new field type as > >>>the requirements > >>>come in and then make sure that it gets deployed in > exporter and collector? > >>> > >>> > >>> > >>> If there is a need to vary the sizes for various fields > I'd much rather > >>>see the rationale > >>>for each discrete sizing made explicit vs. forcing all the > downstream > >>>consumers of this \ > >>>information have to deal with special cases and ambiguity. > >>> > >>> > >>> > >>>This is not a special case handling as you can see that > the list above > >>>covers about > >>>40% of the fields defined today in the information model. > It is way to > >>>handle > >>>ambiguity arising out of implementation differences. > >>> > >>>Thanks > >>>Ganesh > >>> > >>> > >>>Regards, > >>> > >>> Jeff Meyer > >>> > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com > >>> ] > >>>Sent: Monday, September 29, 2003 6:00 PM > >>>To: ipfix@net.doit.wisc.edu > >>>Subject: [ipfix] Variant Field Types. > >>> > >>> > >>>Hi, > >>> > >>> > >>> > >>>The information model only > >>> > >>>has types for fixed length objects and variable length > >>> > >>>string like objects. > >>> > >>> > >>> > >>>There are a number of information element types (listed below) > >>> > >>>that would be better defined in terms of fixed-size run-time > >>> > >>>specified objects. The type variation comes due to difference > >>> > >>>in the size of the objects used because of an implementation, > >>> > >>>as demanded by the network or otherwise. > >>> > >>> > >>> > >>>The way to make this work is to use the template > >>> > >>>length field to determine the exact sub-type: > >>> > >>> > >>> > >>>The definitions of a variant field type can be stated as: > >>> > >>> > >>> > >>>type varUnsignedInt > >>> > >>> if (element.length == 1) > >>> > >>> type = unsignedByte > >>> > >>> else if (element.length <= 2) > >>> > >>> type = unsignedShort > >>> > >>> else if (element.length <= 4) > >>> > >>> type = unsignedInt > >>> > >>> else if (element.length <= 8) > >>> > >>> type = unsignedLong > >>> > >>> else type = undefined > >>> > >>> > >>> > >>>type varInt > >>> > >>> if (element.length == 1) > >>> > >>> type = byte > >>> > >>> else if (element.length <= 2) > >>> > >>> type = short > >>> > >>> else if (element.length <= 4) > >>> > >>> type = int > >>> > >>> else if (element.length <= 8) > >>> > >>> type = long > >>> > >>> else type = undefined > >>> > >>> > >>> > >>>The candidates that fit into the description above are (I may > >>> > >>>have missed some also): > >>> > >>>- ingressPort > >>> > >>>- egressPort > >>> > >>>- packetCount > >>> > >>>- byteCount > >>> > >>>- sourceAS > >>> > >>>- destinationAS > >>> > >>>- nextHopAS > >>> > >>>- droppedPacketCount > >>> > >>>- samplingInterval > >>> > >>>- droppedByteCount > >>> > >>> > >>> > >>>Please comment. > >>> > >>> > >>> > >>>Thanks > >>> > >>>Ganesh > >>> > >>> > >>> > >>> > >>> > >> > >> > >>-- > >>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 Oct 2 16:54:41 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 QAA23455 for ; Thu, 2 Oct 2003 16:06:06 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A59c7-0000vE-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 14:59:51 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A59c6-0000v6-00 for ipfix@net.doit.wisc.edu; Thu, 02 Oct 2003 14:59:50 -0500 Received: (qmail 8602 invoked from network); 2 Oct 2003 19:59:49 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 2 Oct 2003 19:59:49 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h92JxmX03349; Thu, 2 Oct 2003 15:59:49 -0400 Reply-To: From: "Carter Bullard" To: Cc: , "'Reinaldo Penno'" , , Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 2 Oct 2003 15:59:45 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6A6@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CDDD7@ptah.newyork.qosient.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk Sender: majordomo listserver Hey Alex, Did I say something wrong? I firmly believe that people adopt technology when it solves problems. STCP will get around as its found to be a real solution. But with regard to STCP and IPFIX, I read RFC 3257, the SCTP Applicability Statement, and I don't see where IPFIX fits. Benefits of SCTP over TCP are: multi-streams support multi-homing support preservation of message boundaries unordered reliable message delivery The first three I don't see as requirements for IPFIX. I actually believe the last one to be a problem for IPFIX. STCP is less efficient that TCP, and so if IPFIX doesn't need any of these 4 items, then I don't see the applicability. Carter > -----Original Message----- > From: Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Thursday, October 02, 2003 2:51 PM > To: carter@qosient.com > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > Hello Carter, > > If it is true that SCTP hasn't been widely deployed, it is > probably because > of statements like you have made below. Look, we all know SCTP has > a lot of benefits over TCP. If folks like you don't drive > its deployement > by specifying it as default transport, how will it be > ubiquitous? It is a > self fulfilling prophesy. > > For IETF protocols that recommend SCTP as defaults, see rfc > 3057, rfc 3331 > and rfc 3332 just to name a few. > > Regards, > Alex. > > Carter Bullard wrote: > > > I believe that SCTP-PR is not deployed widely enough > > to be considered a default for any IETF technology. > > It is not on my Linux RedHat 9.0 distribution, nor > > my Mac OS-X or my Windows XP system. I don't see it > > available on any Solaris machine that I have access > > to. > > > > What IETF technology is currently using SCTP as a > > default transport? > > > > Carter > > > > > -----Original Message----- > > > From: majordomo listserver > > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Stewart Bryant > > > Sent: Thursday, October 02, 2003 12:14 PM > > > To: Reinaldo Penno > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > Hello, > > > > > > > > Have we zeroed in a certain transport protocol? TCP, SCTP-PR or > > > > something else? > > > > > > > > I need to write something to explain how Netflow runs over > > > TCP, but it > > > > seems to me somewhat of a lower priority if this is not > > > going to be the > > > > default protocol. We should focus on explaning how this > > > should work on > > > > the "choosen one". > > > > > > I think that perhaps the question should be put another > way. There are > > > WG members who propose SCTP-PR as the default, and SCTP-PR has > > > advantage because of its better flexibility in coping > with congestion. > > > > > > So the real question is whether there are WG members who > think that > > > the default should be TCP. If no group comes forward, then we have > > > our answer. If there is support then we need to perform a detailed > > > analysis of the relative merits of the two protocols. > > > > > > Stewart > > > > > > > > > -- > > > 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 Oct 2 17: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 RAA26069 for ; Thu, 2 Oct 2003 17:14:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A5AZw-000389-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 16:01:40 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A5AZq-000382-00; Thu, 02 Oct 2003 16:01:35 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h92L1KXU019708; Thu, 2 Oct 2003 16:01:21 -0500 (CDT) Message-ID: <3F7C9220.185B8FCC@alcatel.com> Date: Thu, 02 Oct 2003 16:01:20 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: carter@qosient.com CC: stbryant@cisco.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6A6@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Carter, How is SCTP less efficient than TCP? Shouldn't this be the other way round? My experience has been that SCTP starts faster than TCP (meaning its Slow Start mode is less severe than TCP's). That should translate into a more efficient protocol. It is true that IPFIX didn't mandate multi-streams, multi-homing and message boundary preservation, but these are features that make designing with SCTP somewhat of a joy. SCTPs streams simplifies redundant designs. Just set up multi-streams from the Exporter to different Collectors and you have a design that quickly protects your Exporter-collector path. Multi-homing also adds to the survivability of the Exporter-Collector link. If you can't get to the Collector via one network address, you just try the other. Message boundary preservation becomes helpful in the processing of the messages. Your application doesn't have to worry about where a message starts or a new one begins. This makes for an efficient over-all implementation. You know you can chose between Ordered and Unordered reliable message delivery modes. So, this shouldn't be an issue. It just gives more flexibility. SCTP is more secure than TCP. Though not critical in this case, it needs to be mentioned all the same. Regards, Alex. Carter Bullard wrote: > Hey Alex, > Did I say something wrong? I firmly believe that people adopt > technology when it solves problems. STCP will get around as > its found to be a real solution. But with regard to STCP and > IPFIX, I read RFC 3257, the SCTP Applicability Statement, and > I don't see where IPFIX fits. Benefits of SCTP over TCP are: > > multi-streams support > multi-homing support > preservation of message boundaries > unordered reliable message delivery > > The first three I don't see as requirements for IPFIX. > I actually believe the last one to be a problem for IPFIX. > STCP is less efficient that TCP, and so if IPFIX doesn't need > any of these 4 items, then I don't see the applicability. > > Carter > > > -----Original Message----- > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > Sent: Thursday, October 02, 2003 2:51 PM > > To: carter@qosient.com > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Hello Carter, > > > > If it is true that SCTP hasn't been widely deployed, it is > > probably because > > of statements like you have made below. Look, we all know SCTP has > > a lot of benefits over TCP. If folks like you don't drive > > its deployement > > by specifying it as default transport, how will it be > > ubiquitous? It is a > > self fulfilling prophesy. > > > > For IETF protocols that recommend SCTP as defaults, see rfc > > 3057, rfc 3331 > > and rfc 3332 just to name a few. > > > > Regards, > > Alex. > > > > Carter Bullard wrote: > > > > > I believe that SCTP-PR is not deployed widely enough > > > to be considered a default for any IETF technology. > > > It is not on my Linux RedHat 9.0 distribution, nor > > > my Mac OS-X or my Windows XP system. I don't see it > > > available on any Solaris machine that I have access > > > to. > > > > > > What IETF technology is currently using SCTP as a > > > default transport? > > > > > > Carter > > > > > > > -----Original Message----- > > > > From: majordomo listserver > > > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Stewart Bryant > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > To: Reinaldo Penno > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > Hello, > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, SCTP-PR or > > > > > something else? > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > TCP, but it > > > > > seems to me somewhat of a lower priority if this is not > > > > going to be the > > > > > default protocol. We should focus on explaning how this > > > > should work on > > > > > the "choosen one". > > > > > > > > I think that perhaps the question should be put another > > way. There are > > > > WG members who propose SCTP-PR as the default, and SCTP-PR has > > > > advantage because of its better flexibility in coping > > with congestion. > > > > > > > > So the real question is whether there are WG members who > > think that > > > > the default should be TCP. If no group comes forward, then we have > > > > our answer. If there is support then we need to perform a detailed > > > > analysis of the relative merits of the two protocols. > > > > > > > > Stewart > > > > > > > > > > > > -- > > > > 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 Oct 2 17: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 RAA26315 for ; Thu, 2 Oct 2003 17:21:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A5Adg-0003I3-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 16:05:32 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A5Adf-0003Hu-00; Thu, 02 Oct 2003 16:05:31 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id AB5FD1C017B3; Thu, 2 Oct 2003 17:05:30 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 991531C00A6C; Thu, 2 Oct 2003 17:05:30 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 2 Oct 2003 17:05:30 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296035E@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'carter@qosient.com'" , "'alex.audu@alcatel.com'" Cc: "'stbryant@cisco.com'" , "'Reinaldo Penno'" , "'ipfix-chairs@net.doit.wisc.edu'" , "'ipfix@net.doit.wisc.edu'" Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 2 Oct 2003 17:05:22 -0400 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 I'd be interested in knowing what the specific aspects of SCTP are that the IPFIX protocol authors want to use, and how they do or do not conflict in some way with a parallel mapping to TCP. Taking the Diameter approach of specifying both TCP and SCTP would allow for the market to decide if ubiquity of availability or the special capabilities of SCTP are more important. -- Jeff > -----Original Message----- > From: Carter Bullard [mailto:carter@qosient.com] > Sent: Thursday, October 02, 2003 1:00 PM > To: alex.audu@alcatel.com > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] STCP as a default transport not > > > Hey Alex, > Did I say something wrong? I firmly believe that people adopt > technology when it solves problems. STCP will get around as > its found to be a real solution. But with regard to STCP and > IPFIX, I read RFC 3257, the SCTP Applicability Statement, and > I don't see where IPFIX fits. Benefits of SCTP over TCP are: > > multi-streams support > multi-homing support > preservation of message boundaries > unordered reliable message delivery > > The first three I don't see as requirements for IPFIX. > I actually believe the last one to be a problem for IPFIX. > STCP is less efficient that TCP, and so if IPFIX doesn't need > any of these 4 items, then I don't see the applicability. > > Carter > > > > -----Original Message----- > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > Sent: Thursday, October 02, 2003 2:51 PM > > To: carter@qosient.com > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Hello Carter, > > > > If it is true that SCTP hasn't been widely deployed, it is > > probably because > > of statements like you have made below. Look, we all know SCTP has > > a lot of benefits over TCP. If folks like you don't drive > > its deployement > > by specifying it as default transport, how will it be > > ubiquitous? It is a > > self fulfilling prophesy. > > > > For IETF protocols that recommend SCTP as defaults, see rfc > > 3057, rfc 3331 > > and rfc 3332 just to name a few. > > > > Regards, > > Alex. > > > > Carter Bullard wrote: > > > > > I believe that SCTP-PR is not deployed widely enough > > > to be considered a default for any IETF technology. > > > It is not on my Linux RedHat 9.0 distribution, nor > > > my Mac OS-X or my Windows XP system. I don't see it > > > available on any Solaris machine that I have access > > > to. > > > > > > What IETF technology is currently using SCTP as a > > > default transport? > > > > > > Carter > > > > > > > -----Original Message----- > > > > From: majordomo listserver > > > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Stewart Bryant > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > To: Reinaldo Penno > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > Hello, > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > SCTP-PR or > > > > > something else? > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > TCP, but it > > > > > seems to me somewhat of a lower priority if this is not > > > > going to be the > > > > > default protocol. We should focus on explaning how this > > > > should work on > > > > > the "choosen one". > > > > > > > > I think that perhaps the question should be put another > > way. There are > > > > WG members who propose SCTP-PR as the default, and SCTP-PR has > > > > advantage because of its better flexibility in coping > > with congestion. > > > > > > > > So the real question is whether there are WG members who > > think that > > > > the default should be TCP. If no group comes forward, > then we have > > > > our answer. If there is support then we need to perform > a detailed > > > > analysis of the relative merits of the two protocols. > > > > > > > > Stewart > > > > > > > > > > > > -- > > > > 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 Oct 2 23:52:58 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 XAA07674 for ; Thu, 2 Oct 2003 23:52:57 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A5GSR-00007e-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Oct 2003 22:18:19 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A5GSQ-00007Y-00; Thu, 02 Oct 2003 22:18:18 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h933I6EE028675; Fri, 3 Oct 2003 15:18:06 +1200 (NZST) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7BB5B33EDF; Fri, 3 Oct 2003 15:16:48 +1200 (NZST) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00777-09; Fri, 3 Oct 2003 15:16:48 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 220C933ED8; Fri, 3 Oct 2003 15:16:48 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h933I5U30102; Fri, 3 Oct 2003 15:18:05 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Fri, 3 Oct 2003 15:18:05 +1200 Message-ID: <1065151085.df51c4b42e087@hotlava.auckland.ac.nz> Date: Fri, 3 Oct 2003 15:18:05 +1200 From: Nevil Brownlee To: Randy Bush Cc: Allison Mankin , Bert Wijnen , ipfix-reqs@net.doit.wisc.edu, ipfix-cochairs@net.doit.wisc.edu Subject: [ipfix-reqs] Re: IPFIX Requirements issues (resend) References: <1060623486.6cb8e1fd7764b@hotlava.auckland.ac.nz> <1063042982.8bc8611d14d16@hotlava.auckland.ac.nz> 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 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Randy: > in the absense of allison's response, i will now move the process. > > how do you feel the wg has addressed her comments? Juergen Quittek, the Requirememnt Draft Editor hasn't responded to me yet, so I'll answer your question directly. The IPFIX WG discussed the IESG questions arising from version -10.txt, and agreed that all except those from Allison concerning Confidentiality and Anonymisation would be handled by small editing changes. There was a lively discussion of Confidentiality and Anonymisation on the IPFIX list after the Vienna meeting. We reached a clear WG consensus, as follows: a) A fair proportion of users probably would use encryption to get their IPFIX data safely across the Internet. We've said all along that we'd use TLS or IPSEC for that, rather than try to do it at the application layer in IPFIX. We propose to addres your concern about IPFIX encrytion by changing the IPFIX Requirements draft to say that "IPFIX implementations MUST provide for encryption of exported IPFIX data, e.g. by using IPSEC or TLS." b) For anonymization the situation is much less clear. - IPFIX data will normally be collected by network operators for traffic engineering and/or accounting purposes. In both these cases raw (un-anonymized) data is needed; again, since IPFIX data can be encrypted in transit, there is no operational need for further privacy protection. - Although it may be useful for operators to anonymize traffic data before giving researchers access to it, that is easily done (as at present) using anonymization tools. - At this stage there is not a clear understanding of how to implement anonymisation. There are at least three algorithms in use (Crypto-PaN, tcpdpriv, and hashing each address to a randomly chosen anonymised address). Each algorithm has different resource demands, and produces different properties in the anonymised addresses. We believe that anonymization is still a research issue, not something which is ready to go into production network devices. We propose that rather than attempt to standardise anonymisation, we should remove all mention of it from the IPFIX Requirements draft. c) Notwithstanding the remarks in (b), the WG believe that we need to address users' privacy concerns. We propose to do this by adding a 'Privacy Concerns' section to the Requirements draft, as suggested by Sebastain Zander (appended bleow). I emailed Allison on 7 August 03 to ask whether this was sufficient; I've had no response. 'Agreement in principle' is what we're waiting for. Given that, the IPFIX requirements editors will press ahead, make the changes and resubmit requirements-11.txt for IESG consideration. Meanwhile, in the last week or so the IPFIX list seems to have woken up, I hope that we'll have the four main IPFIX drafts fairly complete in time for the November meeting. 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 Sebastian Zander's suggestion: > I think that IPFIX must deal with privacy issues somehow. Afterall we > are standardizing something which could be used to get a detailed log > of a users activities. > > Different countries may have completly different laws on privacy. But > there are laws (e.g. in the EU). So what may be a privacy violation in one > country may not be a privacy violation in another. > > In general i agree to your proposal. However i think some of the arguments > against a MUST are not too strong. If i have a flat rate why would my > provider need to record my flow data? What would prevent someone to give > a 3rd party access to ipfix informtion? Technically nothing... > (but there are laws). > > I think there are differences between security and privacy which justify > a different treatment IMO: > - Security/encryption can *always* be used for ipfix although it means > using more resources etc. whereas privacy/anonymization can *not* be > used in any case (e.g. in case of accounting srcip must not be > anonymized). > - We have to assume that in those cases the people who use ipfix comply to > the relevant privacy laws. Privacy can't be enforced by the protocol > itself, only by laws or social norms. > - The scenarios where people would like to access ipfix data and can do > this only through the use of anonymization are currently rare and out > of scope(?). > - Encryption techniques are more mature and widely understood whereas > anonymization techniques are still research and therefore its more > difficult to put them into a standard now. > - I think its not the scope of this group to develop and/or standard > anonymization techniques. There are standards for encryption but for > anonymization? > > Maybe it would be a good idea to have some text on privacy considerations > in the draft (similar to security considerations). ------------------------------------------------------------------------------- ------------------------------------------------- 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 Oct 3 02:22: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 CAA23745 for ; Fri, 3 Oct 2003 02:22:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A5J55-0005mt-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Oct 2003 01:06:23 -0500 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A5J54-0005ml-00; Fri, 03 Oct 2003 01:06:22 -0500 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A5J4y-0001jn-R4; Thu, 02 Oct 2003 23:06:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 2 Oct 2003 23:06:16 -0700 To: Nevil Brownlee Cc: Allison Mankin , Bert Wijnen , ipfix-reqs@net.doit.wisc.edu, ipfix-cochairs@net.doit.wisc.edu Subject: [ipfix-reqs] Re: IPFIX Requirements issues (resend) References: <1060623486.6cb8e1fd7764b@hotlava.auckland.ac.nz> <1063042982.8bc8611d14d16@hotlava.auckland.ac.nz> <1065151085.df51c4b42e087@hotlava.auckland.ac.nz> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit thanks, nevil randy -- 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 Oct 3 04:48: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 EAA27600 for ; Fri, 3 Oct 2003 04:48:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A5LIV-000393-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Oct 2003 03:28:23 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A5LIU-00038y-00 for ipfix@net.doit.wisc.edu; Fri, 03 Oct 2003 03:28:22 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2003 10:26:45 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h938SGu5021264; Fri, 3 Oct 2003 10:28:17 +0200 (MET DST) Received: from cisco.com (rtp-vpn2-104.cisco.com [10.82.240.104]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA21275; Fri, 3 Oct 2003 09:28:15 +0100 (BST) Message-ID: <3F7D331C.4040806@cisco.com> Date: Fri, 03 Oct 2003 09:28:12 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Ganesh Sadasivan'" , Mark Fullmer , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. References: <1D3D2C371FCBD947A7897FABBD3533A50296035C@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A50296035C@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > Stewart, > > Counters are an interesting (and irritating) beast. Thankfully I > am not aware of any currently defined in the context of IPFIX. > packetCount and byteCount are not counters? In any case we are designing a general purpose system here, and future applications designers should be able to use any basic primitive data object and a wrapping counter is such an object. We also need to be able to scele the system without exploding the number of IEs. Including the variant type allows us to do this. > If we do encounter these, then there should be an appropriate > annotation in the IM indicating this property. That is what defining them as a variant type is doing. > My leaning would be to avoid them. Sure, but why deny the flexibility to the designer that does need them. We have an existance proof in Netflow v9 that there is utility in this type of definition, and I am sure that many more will appear over time. > The observer in the IPFIX model seems capable > of delivering accurate summaries of an observed flow, vs. relying > on SNMP style counters. > > In the case of explicit numeric quantities, i.e. "on this flow I > saw this many of this thing", clearly the exporter needs to ensure > that the size of its export field has sufficient capacity to accomodate > the largest value it may observe. in the normal case... > > From the perspective of a collector, the maximal size should > reflect the largest accumulation of this field which is expected. > This would seem to lean towards int64 for most quantities. I am not so worried about the collector (although I am worried about an aggregator), I am however worried about the observer/exporter which is much more likely to be memory constrained. > > If the quantities are expected to accumulate beyond this amount, > I would recommend the use of float or double. I'm not aware of > much consistent support for integers > 2^64. I agree that in most case 64 bits works, my concern is at the other end of the system where the information is gleaned from the flows. Stewart > > Regards, > > Jeff Meyer > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Thursday, October 02, 2003 12:03 PM >>To: MEYER,JEFFREY D (HP-Cupertino,ex1) >>Cc: 'Ganesh Sadasivan'; Mark Fullmer; ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] Variant Field Types. >> >> >>Jeff >> >>Whether the size reduction fits in the IM or in the protocol draft >>depends on how closely you see the drafts mapping onto the >>structure of the implementation. >> >>Ultimately the exporter and the collector have to have the same >>shared IM, including knowledge of the object size that the exporter >>is actually using. >> >>One obvious example is counter wrapping (there may be others). >>Lets say IM defines a 16 bit counter object, and the collector >>uses this to interpret the data it receives from the exporter. The >>exporter on the other hand reduces this to 8 bits. The sequence >>7,8,0 means quite different things to each party. In the case >>above the exporter saw 9 object and the collector thought >>there had been 17. The collector can only correctly determine >>what ocured if it knows that the exporter is using the abbreviated >>size. >> >>Now you could regard the use of a different size as a protocol matter >>i.e. compression is being applied to the data, but to get the correct >>shared semantics, the protocol engine now has to be aware of the >>true semantics of IEs rather than just passing them up as abstract >>objects. >> >>Therefore I would think that the part of the system that understands >>the IEs needs to be aware of the size that the exporter is using, >>and this leads me to conclude that we might as well describe the >>size behavior in the IM. >> >>Stewart >> >> >> >> >> >>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >> >> >>>Hi, >>> >>> I think the details of using smaller encoding in an >> >>implementation >> >>>belong in the protocol specification vs. the information >> >>model. The >> >>>information model already references the protocol >> >>specification for how >> >>>fields of a given type are encoded. >>> >>> For specific fields, there is still a decision on what >> >>would be the >> >>>maximal type. E.g. do ports need to be 32-bit or 16? Do >> >>AS numbers >> >>>need to be 32 or 64? Given the unit of measure for >> >>SampleInterval, what >> >>>is its limit? These details would go in the information model. >>> >>>Regards, >>> >>> Jeff Meyer >>> >>> -----Original Message----- >>> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >>> Sent: Wednesday, October 01, 2003 11:35 AM >>> To: Mark Fullmer >>> Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu >>> Subject: Re: [ipfix] Variant Field Types. >>> >>> Mark, >>> >>> Mark Fullmer wrote: >>> >>> >>>>I'm in favor of setting upper bounds, for example counters don't go >>> >>> >>> I agree that a field even if variable in length is limited by an >>> upper bound and this is limit is set on a >>> case by case basis. The whole point of my first e-mail is rather >>> than nailing a field to an explicit >>> type like uint64_t, to let implementors know that they can >>> send/receive these fields in smaller >>> sizes too. >>> >>> >>>>past 64 bits. If you don't do this, what's a collector to >> >>do with say >> >>>>a 72 bit counter? You can't store it in a uint_64_t >> >>anymore so collectors >> >>>>would have to implement arbitrary precision arithmetic to >> >>handle potential >> >>>>cases. I don't think this is reasonable to impose on the >> >>collectors. >> >>>>The issue I have with the variable length fields as >> >>currently specified >> >>>>is the potential for template explosion. If a template has 8 >>>>counters, each of which could be 1..8 byte then you have >>>>8^8 potential templates for that one stream of flows. >>> >>> Yes a separate template is needed for varying length. Template >>> explosion because if this would be >>> an implementation choice rather than that imposed by >> >>the definition >> >>> itself. Also the same would >>> have happened if we explicitly define field types for >> >>the counters >> >>> of varying length. >>> >>> Thanks >>> Ganesh >>> >>> >>>>I was hoping for the sake of the collectors we could keep the active >>>>templates down to something < 64K so a template lookup could be done >>>>with an index instead of a hash. >>>> >>>>mark >>>> >>>>On Tue, Sep 30, 2003 at 04:20:07PM -0400, MEYER,JEFFREY D >> >>(HP-Cupertino,ex1) wrote: >> >>>> >>>> >>>> >>>>>Ganesh, >>>>> >>>>> I'm not clear on how this benefits the collector. Tal >> >>and myself produce >> >>>>>different implementations of carrier deployed products >> >>which collect from >> >>>>>100's of devices and dozens of protocols, perhaps our >> >>experience here is >> >>>>>worth something, and it tells us variant is undesireable >> >>on the collector... >> >>>>> Regarding your other point: >>>>> >>>>>One way to solve this problem is if the collector assumes >> >>the largest size >> >>>>>for >>>>>computations? >>>>> >>>>> This was my point in the e-mail to Stewart. Have the >> >>information model be >> >>>>>EXPLICIT about what is the largest size which is being >> >>modeled for a data >> >>>>>item and declare it. Allow the exporter to declare a >> >>smaller size in the >> >>>>>template, if the exporter knows that an individual record >> >>will always be >> >>>>>accomodated (based on its implementation) in the smaller size. >>>>> >>>>> So for instance this might say that byteCount should be >> >>declared in the >> >>>>>information model as a 64-bit int, while AS is probably >> >>sufficient at >> >>>>>32-bits. >>>>> >>>>> This accomodates the: >>>>> exporter - can use smaller size if known >>>>> n/w - can reduce BW if know a smaller size is used >>>>> info model - explicit is better than "vague" >>>>> collector - addresses persistence and aggregation issues >>>>> >>>>> Can we call this a compromise? >>>>> >>>>>Regards, >>>>> >>>>> Jeff Meyer >>>>> >>>>>-----Original Message----- >>>>>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >>>>>Sent: Tuesday, September 30, 2003 10:45 AM >>>>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) >>>>>Cc: ipfix@net.doit.wisc.edu >>>>>Subject: Re: [ipfix] Variant Field Types. >>>>> >>>>> >>>>> >>>>> >>>>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >>>>> >>>>> >>>>>Hi, >>>>> >>>>> Although the use of variant types may seem convenient >> >>from the perspective >> >>>>>of an >>>>>exporter, I think the various consumers of the data would >> >>benefit from >> >>>>>sticking with >>>>>an explicit type system. >>>>> >>>>>It would benefit the exporter, the n/w, flexibility of >> >>interpretation of >> >>>>>fields in the >>>>>information model and the collector. >>>>> >>>>> >>>>> >>>>> Consider operations which involve summing fields, >> >>storing them to a DB, >> >>>>>etc. >>>>> >>>>>One way to solve this problem is if the collector assumes >> >>the largest size >> >>>>>for >>>>>computations? >>>>> >>>>> >>>>> >>>>> Explicit typing ensures that these consuming >> >>applications can handle these >> >>>>>values >>>>>appropriately and also makes the information modeller >> >>think about how these >> >>>>>types are to be used. >>>>> >>>>> The examples you cite: >>>>> >>>>>- ingressPort >>>>>- egressPort >>>>>- packetCount >>>>>- byteCount >>>>>- sourceAS >>>>>- destinationAS >>>>>- nextHopAS >>>>>- droppedPacketCount >>>>>- samplingInterval >>>>>- droppedByteCount >>>>> >>>>> fall into a few categories, identifiers (such as ports >> >>and AS's), counts >> >>>>>and intervals. >>>>> >>>>> For the identifiers, I believe the size is fixed by the >> >>relevant RFC's >> >>>>>(i.e. why would I >>>>>have a 1 byte Port?). For counts, the use of 32 vs. 64 >> >>bits is a valid >> >>>>>question, however >>>>>these can be handled by making them explicit (i.e. the >> >>information model >> >>>>>says if >>>>>I get this value it is a 32-bit quantity or a 64-bit >> >>quantity and the code >> >>>>>will address >>>>>it accordingly). For intervals, the resolution would >> >>determine which size >> >>>>>is most >>>>>appropriate. >>>>> >>>>> >>>>>For AS the size could be 2 or 4 bytes. >>>>>You may prefer to use a 1 byte port if you are a small >> >>system as against a 4 >> >>>>>byte for >>>>>a gigantic system. Both have their own implementation reasons. >>>>> >>>>> >>>>> The option always exist to define variations on these data items >>>>>explicitly. E.g. >>>>>byteCount32 and byteCount64. >>>>> >>>>> >>>>>Yes. But is'nt this not more of an overhead to introduce >> >>new field type as >> >>>>>the requirements >>>>>come in and then make sure that it gets deployed in >> >>exporter and collector? >> >>>>> >>>>> >>>>> If there is a need to vary the sizes for various fields >> >>I'd much rather >> >>>>>see the rationale >>>>>for each discrete sizing made explicit vs. forcing all the >> >>downstream >> >>>>>consumers of this \ >>>>>information have to deal with special cases and ambiguity. >>>>> >>>>> >>>>> >>>>>This is not a special case handling as you can see that >> >>the list above >> >>>>>covers about >>>>>40% of the fields defined today in the information model. >> >>It is way to >> >>>>>handle >>>>>ambiguity arising out of implementation differences. >>>>> >>>>>Thanks >>>>>Ganesh >>>>> >>>>> >>>>>Regards, >>>>> >>>>> Jeff Meyer >>>>> >>>>> >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com >>>>> ] >>>>>Sent: Monday, September 29, 2003 6:00 PM >>>>>To: ipfix@net.doit.wisc.edu >>>>>Subject: [ipfix] Variant Field Types. >>>>> >>>>> >>>>>Hi, >>>>> >>>>> >>>>> >>>>>The information model only >>>>> >>>>>has types for fixed length objects and variable length >>>>> >>>>>string like objects. >>>>> >>>>> >>>>> >>>>>There are a number of information element types (listed below) >>>>> >>>>>that would be better defined in terms of fixed-size run-time >>>>> >>>>>specified objects. The type variation comes due to difference >>>>> >>>>>in the size of the objects used because of an implementation, >>>>> >>>>>as demanded by the network or otherwise. >>>>> >>>>> >>>>> >>>>>The way to make this work is to use the template >>>>> >>>>>length field to determine the exact sub-type: >>>>> >>>>> >>>>> >>>>>The definitions of a variant field type can be stated as: >>>>> >>>>> >>>>> >>>>>type varUnsignedInt >>>>> >>>>> if (element.length == 1) >>>>> >>>>> type = unsignedByte >>>>> >>>>> else if (element.length <= 2) >>>>> >>>>> type = unsignedShort >>>>> >>>>> else if (element.length <= 4) >>>>> >>>>> type = unsignedInt >>>>> >>>>> else if (element.length <= 8) >>>>> >>>>> type = unsignedLong >>>>> >>>>> else type = undefined >>>>> >>>>> >>>>> >>>>>type varInt >>>>> >>>>> if (element.length == 1) >>>>> >>>>> type = byte >>>>> >>>>> else if (element.length <= 2) >>>>> >>>>> type = short >>>>> >>>>> else if (element.length <= 4) >>>>> >>>>> type = int >>>>> >>>>> else if (element.length <= 8) >>>>> >>>>> type = long >>>>> >>>>> else type = undefined >>>>> >>>>> >>>>> >>>>>The candidates that fit into the description above are (I may >>>>> >>>>>have missed some also): >>>>> >>>>>- ingressPort >>>>> >>>>>- egressPort >>>>> >>>>>- packetCount >>>>> >>>>>- byteCount >>>>> >>>>>- sourceAS >>>>> >>>>>- destinationAS >>>>> >>>>>- nextHopAS >>>>> >>>>>- droppedPacketCount >>>>> >>>>>- samplingInterval >>>>> >>>>>- droppedByteCount >>>>> >>>>> >>>>> >>>>>Please comment. >>>>> >>>>> >>>>> >>>>>Thanks >>>>> >>>>>Ganesh >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>-- >>>>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 Sun Oct 5 00:38: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 AAA24814 for ; Sun, 5 Oct 2003 00:38:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A60MO-0005Ak-00 for ipfix-list@mil.doit.wisc.edu; Sat, 04 Oct 2003 23:19:08 -0500 Received: from sv1.eng.oar.net ([192.148.251.86]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A60MN-0005Ac-00 for ipfix@net.doit.wisc.edu; Sat, 04 Oct 2003 23:19:07 -0500 Received: (qmail 21590 invoked from network); 5 Oct 2003 04:19:07 -0000 Received: from dev1.eng.oar.net (192.148.251.71) by sv1.eng.oar.net with SMTP; 5 Oct 2003 04:19:07 -0000 Received: (qmail 75808 invoked by uid 4454); 5 Oct 2003 04:19:07 -0000 Date: Sun, 5 Oct 2003 00:19:07 -0400 From: Mark Fullmer To: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" Cc: "'stbryant@cisco.com'" , "'Ganesh Sadasivan'" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Variant Field Types. Message-ID: <20031005001907.A75742@net.ohio-state.edu> References: <1D3D2C371FCBD947A7897FABBD3533A50296035C@xsun01.ptp.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A50296035C@xsun01.ptp.hp.com>; from jeff.meyer2@hp.com on Thu, Oct 02, 2003 at 03:58:56PM -0400 Precedence: bulk Sender: majordomo listserver On Thu, Oct 02, 2003 at 03:58:56PM -0400, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > If the quantities are expected to accumulate beyond this amount, > I would recommend the use of float or double. I'm not aware of > much consistent support for integers > 2^64. Some implementation of the observation point will be running in kernel space where floating point arithmetic is not available. mark -- 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 Oct 6 07:56:14 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 HAA26174 for ; Mon, 6 Oct 2003 07:56:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6TXq-000467-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Oct 2003 06:28:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6TXp-00045t-00 for ipfix@net.doit.wisc.edu; Mon, 06 Oct 2003 06:28:53 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2003 13:27:11 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h96BSjUw012221; Mon, 6 Oct 2003 13:28:45 +0200 (MET DST) Received: from cisco.com (ams-clip-vpn-dhcp317.cisco.com [10.61.65.61]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA01637; Mon, 6 Oct 2003 12:28:48 +0100 (BST) Message-ID: <3F8151F0.6010603@cisco.com> Date: Mon, 06 Oct 2003 12:28:48 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ipfix@net.doit.wisc.edu'" , psamp@ops.ietf.org Subject: [ipfix] [Fwd: I-D ACTION:draft-bryant-ipfix-vendor-ie-00.txt] Content-Type: multipart/mixed; boundary="------------030505060803070406060001" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030505060803070406060001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPFIX Vendor Specific Information Elements Author(s) : S. Bryant, G. Sadasivan Filename : draft-bryant-ipfix-vendor-ie-00.txt Pages : 20 Date : 2003-10-3 Both IPFIX and PSAMP need methods whereby vendors can add proprietary information elements (IEs) to data flowsets. This draft proposes two possible methods of providing vendor specific IEs. The extension of these methods to provide vendor specific scope and options is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bryant-ipfix-vendor-ie-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-bryant-ipfix-vendor-ie-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-bryant-ipfix-vendor-ie-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. --------------030505060803070406060001 Content-Type: Message/External-body; name="draft-bryant-ipfix-vendor-ie-00.txt" Content-Disposition: inline; filename="draft-bryant-ipfix-vendor-ie-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-3164236.I-D@ietf.org> --------------030505060803070406060001-- -- 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 Oct 6 12:57:08 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 MAA11910 for ; Mon, 6 Oct 2003 12:57:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6YLC-0006ds-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Oct 2003 11:36:10 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6YLA-0006di-00; Mon, 06 Oct 2003 11:36:08 -0500 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96GYVm23202; Mon, 6 Oct 2003 09:34:31 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Oct 2003 09:34:25 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F930218F277@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'carter@qosient.com'" , "'alex.audu@alcatel.com'" Cc: "'stbryant@cisco.com'" , "'ipfix-chairs@net.doit.wisc.edu'" , "'ipfix@net.doit.wisc.edu'" Subject: RE: [ipfix] STCP as a default transport not Date: Mon, 6 Oct 2003 09:34:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38C27.B3D5A684" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38C27.B3D5A684 Content-Type: text/plain; charset="ISO-8859-1" Okay... It seems we haven't reached a (firm) conclusion, but we need to get the draft going and this is a big piece of it. Jeff seems to propose specifying both (TCP and SCTP). Anyone opposes this? Or should we stick with one protocol mapping? We need to start converging on this really soon. Thanks, Reinaldo > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Thursday, October 02, 2003 5:05 PM > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > Subject: RE: [ipfix] STCP as a default transport not > > > I'd be interested in knowing what the specific aspects of > SCTP are that the IPFIX protocol authors want to use, and how > they do or do not conflict in some way with a parallel mapping to TCP. > > Taking the Diameter approach of specifying both TCP and SCTP > would allow for the market to decide if ubiquity of > availability or the special capabilities of SCTP are more important. > > -- Jeff > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Thursday, October 02, 2003 1:00 PM > > To: alex.audu@alcatel.com > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Hey Alex, > > Did I say something wrong? I firmly believe that people adopt > > technology when it solves problems. STCP will get around > as its found > > to be a real solution. But with regard to STCP and IPFIX, > I read RFC > > 3257, the SCTP Applicability Statement, and I don't see where IPFIX > > fits. Benefits of SCTP over TCP are: > > > > multi-streams support > > multi-homing support > > preservation of message boundaries > > unordered reliable message delivery > > > > The first three I don't see as requirements for IPFIX. > > I actually believe the last one to be a problem for IPFIX. STCP is > > less efficient that TCP, and so if IPFIX doesn't need any > of these 4 > > items, then I don't see the applicability. > > > > Carter > > > > > > > -----Original Message----- > > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > > Sent: Thursday, October 02, 2003 2:51 PM > > > To: carter@qosient.com > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Hello Carter, > > > > > > If it is true that SCTP hasn't been widely deployed, it > is probably > > > because of statements like you have made below. Look, we all know > > > SCTP has a lot of benefits over TCP. If folks like you > don't drive > > > its deployement > > > by specifying it as default transport, how will it be > > > ubiquitous? It is a > > > self fulfilling prophesy. > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, > > > rfc 3331 and rfc 3332 just to name a few. > > > > > > Regards, > > > Alex. > > > > > > Carter Bullard wrote: > > > > > > > I believe that SCTP-PR is not deployed widely enough > > > > to be considered a default for any IETF technology. > > > > It is not on my Linux RedHat 9.0 distribution, nor > > > > my Mac OS-X or my Windows XP system. I don't see it > available on > > > > any Solaris machine that I have access to. > > > > > > > > What IETF technology is currently using SCTP as a > > > > default transport? > > > > > > > > Carter > > > > > > > > > -----Original Message----- > > > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] > > > > > On Behalf Of Stewart Bryant > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > To: Reinaldo Penno > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > SCTP-PR or > > > > > > something else? > > > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > > TCP, but it > > > > > > seems to me somewhat of a lower priority if this is not > > > > > going to be the > > > > > > default protocol. We should focus on explaning how this > > > > > should work on > > > > > > the "choosen one". > > > > > > > > > > I think that perhaps the question should be put another > > > way. There are > > > > > WG members who propose SCTP-PR as the default, and > SCTP-PR has > > > > > advantage because of its better flexibility in coping > > > with congestion. > > > > > > > > > > So the real question is whether there are WG members who > > > think that > > > > > the default should be TCP. If no group comes forward, > > then we have > > > > > our answer. If there is support then we need to perform > > a detailed > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > Stewart > > > > > > > > > > > > > > > -- > > > > > 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/ > > > ------_=_NextPart_001_01C38C27.B3D5A684 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] STCP as a default transport not

Okay...

It seems we haven't reached a (firm) conclusion, but = we need to get the draft going and this is a big piece of it. Jeff = seems to propose specifying both (TCP and SCTP). Anyone opposes this? = Or should we stick with one protocol mapping?

We need to start converging on this really soon. =

Thanks,

Reinaldo



> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] =
> Sent: Thursday, October 02, 2003 5:05 PM
> To: 'carter@qosient.com'; = 'alex.audu@alcatel.com'
> Cc: 'stbryant@cisco.com'; Penno, Reinaldo = [BL60:SF30:EXCH];
> 'ipfix-chairs@net.doit.wisc.edu'; = 'ipfix@net.doit.wisc.edu'
> Subject: RE: [ipfix] STCP as a default = transport not
>
>
> I'd be interested in knowing what the specific = aspects of
> SCTP are that the IPFIX protocol authors want = to use, and how
> they do or do not conflict in some way with a = parallel mapping to TCP.
>
> Taking the Diameter approach of specifying both = TCP and SCTP
> would allow for the market to decide if = ubiquity of
> availability or the special capabilities of = SCTP are more important.
>
> -- Jeff
>
> > -----Original Message-----
> > From: Carter Bullard [mailto:carter@qosient.com]=
> > Sent: Thursday, October 02, 2003 1:00 = PM
> > To: alex.audu@alcatel.com
> > Cc: stbryant@cisco.com; 'Reinaldo Penno'; =
> > ipfix-chairs@net.doit.wisc.edu; = ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] STCP as a default = transport not
> >
> >
> > Hey Alex,
> >    Did I say something = wrong?  I firmly believe that people adopt
> > technology when it solves problems.  = STCP will get around
> as its found
> > to be a real solution.  But with = regard to STCP and IPFIX,
> I read RFC
> > 3257, the SCTP Applicability Statement, = and I don't see where IPFIX
> > fits.  Benefits of SCTP over TCP = are:
> >
> >    multi-streams = support
> >    multi-homing = support
> >    preservation of message = boundaries
> >    unordered reliable = message delivery
> >
> > The first three I don't see as = requirements for IPFIX.
> > I actually believe the last one to be a = problem for IPFIX. STCP is
> > less efficient that TCP, and so if IPFIX = doesn't need any
> of these 4
> > items, then I don't see the = applicability.
> >
> > Carter
> >
> >
> > > -----Original Message-----
> > > From: Alex Audu [mailto:alex.audu@alcatel.com]<= /FONT>
> > > Sent: Thursday, October 02, 2003 2:51 = PM
> > > To: carter@qosient.com
> > > Cc: stbryant@cisco.com; 'Reinaldo = Penno';
> > > ipfix-chairs@net.doit.wisc.edu; = ipfix@net.doit.wisc.edu
> > > Subject: Re: [ipfix] STCP as a = default transport not
> > >
> > >
> > > Hello Carter,
> > >
> > > If it is true that SCTP hasn't been = widely deployed, it
> is probably
> > > because of statements like you have = made below. Look, we all know
> > > SCTP has a lot of benefits over = TCP.  If folks like you
> don't drive
> > > its deployement
> > > by specifying it as default = transport, how will it be
> > > ubiquitous? It is a
> > > self fulfilling prophesy.
> > >
> > > For IETF protocols that recommend = SCTP as defaults, see rfc 3057,
> > > rfc 3331 and rfc 3332 just to name a = few.
> > >
> > > Regards,
> > > Alex.
> > >
> > > Carter Bullard wrote:
> > >
> > > > I believe that SCTP-PR is not = deployed widely enough
> > > > to be considered a default for = any IETF technology.
> > > > It is not on my Linux RedHat 9.0 = distribution, nor
> > > > my Mac OS-X or my Windows XP = system.  I don't see it
> available on
> > > > any Solaris machine that I have = access to.
> > > >
> > > > What IETF technology is = currently using SCTP as a
> > > > default transport?
> > > >
> > > > Carter
> > > >
> > > > > -----Original = Message-----
> > > > > From: majordomo listserver =
> [mailto:majordomo@mil.doit.wi= sc.edu]
> > > > > On Behalf Of Stewart = Bryant
> > > > > Sent: Thursday, October 02, = 2003 12:14 PM
> > > > > To: Reinaldo Penno
> > > > > Cc: = ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > > > Subject: Re: [ipfix] Ipfix = Protocol open items
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Reinaldo Penno = wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Have we zeroed in a = certain transport protocol? TCP,
> > SCTP-PR or
> > > > > > something else?
> > > > > >
> > > > > > I need to write = something to explain how Netflow runs over
> > > > > TCP, but it
> > > > > > seems to me somewhat = of a lower priority if this is not
> > > > > going to be the
> > > > > > default protocol. We = should focus on explaning how this
> > > > > should work on
> > > > > > the "choosen = one".
> > > > >
> > > > > I think that perhaps the = question should be put another
> > > way. There are
> > > > > WG members who propose = SCTP-PR as the default, and
> SCTP-PR has
> > > > > advantage because of its = better flexibility in coping
> > > with congestion.
> > > > >
> > > > > So the real question is = whether there are WG members who
> > > think that
> > > > > the default should be TCP. = If no group comes forward,
> > then we have
> > > > > our answer. If there is = support then we need to perform
> > a detailed
> > > > > analysis of the relative = merits of the two protocols.
> > > > >
> > > > > Stewart
> > > > >
> > > > >
> > > > > --
> > > > > = Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
> > > > > in message body
> > > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> > > > > "unsubscribe = ipfix" in message body
> > > > > = Archive     http://ipfix.doit.wisc.edu/archive/
> > > > >
> > > >
> > > > --
> > > > = Help        mailto:majordomo@net.doit.wi= sc.edu and say
> > > "help" in message = body
> > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> > > > "unsubscribe ipfix" in = message body
> > > > Archive     = http://ipfix.doit.wisc.edu/archive/
> > >
> > >
> >
> >
> >
> >
> > --
> > = Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
> > in message body
> > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say "unsubscribe
> > ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
>

------_=_NextPart_001_01C38C27.B3D5A684-- -- 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 Oct 6 13:38: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 NAA14259 for ; Mon, 6 Oct 2003 13:38:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6ZBJ-0000W6-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Oct 2003 12:30:01 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A6ZBH-0000Va-00 for ipfix@net.doit.wisc.edu; Mon, 06 Oct 2003 12:29:59 -0500 Received: (qmail 78579 invoked from network); 6 Oct 2003 17:29:58 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 6 Oct 2003 17:29:58 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h96HTwX13517; Mon, 6 Oct 2003 13:29:58 -0400 Reply-To: From: "Carter Bullard" To: "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , Cc: , , Subject: RE: [ipfix] STCP as a default transport not Date: Mon, 6 Oct 2003 13:29:54 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6A9@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CDF96@ptah.newyork.qosient.com> Importance: Normal Precedence: bulk Sender: majordomo listserver I am emphatically against any mention of SCTP, unless someone can point out how the SCTP applicability statement, RFC 3257, applies to IPFIX. Carter -----Original Message----- From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] Sent: Monday, October 06, 2003 11:34 AM To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; 'alex.audu@alcatel.com' Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' Subject: RE: [ipfix] STCP as a default transport not Okay... It seems we haven't reached a (firm) conclusion, but we need to get the draft going and this is a big piece of it. Jeff seems to propose specifying both (TCP and SCTP). Anyone opposes this? Or should we stick with one protocol mapping? We need to start converging on this really soon. Thanks, Reinaldo > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Thursday, October 02, 2003 5:05 PM > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > Subject: RE: [ipfix] STCP as a default transport not > > > I'd be interested in knowing what the specific aspects of > SCTP are that the IPFIX protocol authors want to use, and how > they do or do not conflict in some way with a parallel mapping to TCP. > > Taking the Diameter approach of specifying both TCP and SCTP > would allow for the market to decide if ubiquity of > availability or the special capabilities of SCTP are more important. > > -- Jeff > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Thursday, October 02, 2003 1:00 PM > > To: alex.audu@alcatel.com > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Hey Alex, > > Did I say something wrong? I firmly believe that people adopt > > technology when it solves problems. STCP will get around > as its found > > to be a real solution. But with regard to STCP and IPFIX, > I read RFC > > 3257, the SCTP Applicability Statement, and I don't see where IPFIX > > fits. Benefits of SCTP over TCP are: > > > > multi-streams support > > multi-homing support > > preservation of message boundaries > > unordered reliable message delivery > > > > The first three I don't see as requirements for IPFIX. > > I actually believe the last one to be a problem for IPFIX. STCP is > > less efficient that TCP, and so if IPFIX doesn't need any > of these 4 > > items, then I don't see the applicability. > > > > Carter > > > > > > > -----Original Message----- > > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > > Sent: Thursday, October 02, 2003 2:51 PM > > > To: carter@qosient.com > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Hello Carter, > > > > > > If it is true that SCTP hasn't been widely deployed, it > is probably > > > because of statements like you have made below. Look, we all know > > > SCTP has a lot of benefits over TCP. If folks like you > don't drive > > > its deployement > > > by specifying it as default transport, how will it be > > > ubiquitous? It is a > > > self fulfilling prophesy. > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, > > > rfc 3331 and rfc 3332 just to name a few. > > > > > > Regards, > > > Alex. > > > > > > Carter Bullard wrote: > > > > > > > I believe that SCTP-PR is not deployed widely enough > > > > to be considered a default for any IETF technology. > > > > It is not on my Linux RedHat 9.0 distribution, nor > > > > my Mac OS-X or my Windows XP system. I don't see it > available on > > > > any Solaris machine that I have access to. > > > > > > > > What IETF technology is currently using SCTP as a > > > > default transport? > > > > > > > > Carter > > > > > > > > > -----Original Message----- > > > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] > > > > > On Behalf Of Stewart Bryant > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > To: Reinaldo Penno > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > SCTP-PR or > > > > > > something else? > > > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > > TCP, but it > > > > > > seems to me somewhat of a lower priority if this is not > > > > > going to be the > > > > > > default protocol. We should focus on explaning how this > > > > > should work on > > > > > > the "choosen one". > > > > > > > > > > I think that perhaps the question should be put another > > > way. There are > > > > > WG members who propose SCTP-PR as the default, and > SCTP-PR has > > > > > advantage because of its better flexibility in coping > > > with congestion. > > > > > > > > > > So the real question is whether there are WG members who > > > think that > > > > > the default should be TCP. If no group comes forward, > > then we have > > > > > our answer. If there is support then we need to perform > > a detailed > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > Stewart > > > > > > > > > > > > > > > -- > > > > > 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 Mon Oct 6 15:46: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 PAA19348 for ; Mon, 6 Oct 2003 15:46:11 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6b8B-0004Py-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Oct 2003 14:34:55 -0500 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6b89-0004Pm-00; Mon, 06 Oct 2003 14:34:53 -0500 Received: from Givoly (000-042-155.area2.spcsdns.net [68.24.164.8]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h96JglC25406; Mon, 6 Oct 2003 12:42:50 -0700 From: "Tal Givoly" To: "Reinaldo Penno" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , , Cc: , , Subject: RE: [ipfix] STCP as a default transport not Date: Mon, 6 Oct 2003 12:33:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C38C06.07905DE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0A11633F61BD9F40B43ABCC694004F930218F277@zsc3c026.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C38C06.07905DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [ipfix] STCP as a default transport notReinaldo, It seems better to first specify TCP and when there are compelling reasons, a future version may define mapping to SCTP. Several issues, in particular, reliability, become a bit hairy when you start deciding what do you want to send over reliable vs. non-reliable SCTP and this would prolong the process. With TCP, less options exist to get hung up over. Just my $0.02. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Monday, October 06, 2003 9:34 AM To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; 'alex.audu@alcatel.com' Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' Subject: RE: [ipfix] STCP as a default transport not Okay... It seems we haven't reached a (firm) conclusion, but we need to get the draft going and this is a big piece of it. Jeff seems to propose specifying both (TCP and SCTP). Anyone opposes this? Or should we stick with one protocol mapping? We need to start converging on this really soon. Thanks, Reinaldo > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Thursday, October 02, 2003 5:05 PM > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > Subject: RE: [ipfix] STCP as a default transport not > > > I'd be interested in knowing what the specific aspects of > SCTP are that the IPFIX protocol authors want to use, and how > they do or do not conflict in some way with a parallel mapping to TCP. > > Taking the Diameter approach of specifying both TCP and SCTP > would allow for the market to decide if ubiquity of > availability or the special capabilities of SCTP are more important. > > -- Jeff > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Thursday, October 02, 2003 1:00 PM > > To: alex.audu@alcatel.com > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Hey Alex, > > Did I say something wrong? I firmly believe that people adopt > > technology when it solves problems. STCP will get around > as its found > > to be a real solution. But with regard to STCP and IPFIX, > I read RFC > > 3257, the SCTP Applicability Statement, and I don't see where IPFIX > > fits. Benefits of SCTP over TCP are: > > > > multi-streams support > > multi-homing support > > preservation of message boundaries > > unordered reliable message delivery > > > > The first three I don't see as requirements for IPFIX. > > I actually believe the last one to be a problem for IPFIX. STCP is > > less efficient that TCP, and so if IPFIX doesn't need any > of these 4 > > items, then I don't see the applicability. > > > > Carter > > > > > > > -----Original Message----- > > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > > Sent: Thursday, October 02, 2003 2:51 PM > > > To: carter@qosient.com > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Hello Carter, > > > > > > If it is true that SCTP hasn't been widely deployed, it > is probably > > > because of statements like you have made below. Look, we all know > > > SCTP has a lot of benefits over TCP. If folks like you > don't drive > > > its deployement > > > by specifying it as default transport, how will it be > > > ubiquitous? It is a > > > self fulfilling prophesy. > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, > > > rfc 3331 and rfc 3332 just to name a few. > > > > > > Regards, > > > Alex. > > > > > > Carter Bullard wrote: > > > > > > > I believe that SCTP-PR is not deployed widely enough > > > > to be considered a default for any IETF technology. > > > > It is not on my Linux RedHat 9.0 distribution, nor > > > > my Mac OS-X or my Windows XP system. I don't see it > available on > > > > any Solaris machine that I have access to. > > > > > > > > What IETF technology is currently using SCTP as a > > > > default transport? > > > > > > > > Carter > > > > > > > > > -----Original Message----- > > > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] > > > > > On Behalf Of Stewart Bryant > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > To: Reinaldo Penno > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > SCTP-PR or > > > > > > something else? > > > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > > TCP, but it > > > > > > seems to me somewhat of a lower priority if this is not > > > > > going to be the > > > > > > default protocol. We should focus on explaning how this > > > > > should work on > > > > > > the "choosen one". > > > > > > > > > > I think that perhaps the question should be put another > > > way. There are > > > > > WG members who propose SCTP-PR as the default, and > SCTP-PR has > > > > > advantage because of its better flexibility in coping > > > with congestion. > > > > > > > > > > So the real question is whether there are WG members who > > > think that > > > > > the default should be TCP. If no group comes forward, > > then we have > > > > > our answer. If there is support then we need to perform > > a detailed > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > Stewart > > > > > > > > > > > > > > > -- > > > > > 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/ > > > ------=_NextPart_000_0068_01C38C06.07905DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] STCP as a default transport not
Reinaldo,
 
It=20 seems better to first specify TCP and when there are compelling reasons, = a=20 future version may define mapping to SCTP. Several issues, in = particular,=20 reliability, become a bit hairy when you start deciding what do you want = to send=20 over reliable vs. non-reliable SCTP and this would prolong the process. = With=20 TCP, less options exist to get hung up over.
 
Just=20 my $0.02.
 
Tal
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Monday, October 06, 2003 9:34 AM
To:=20 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com';=20 'alex.audu@alcatel.com'
Cc: 'stbryant@cisco.com';=20 'ipfix-chairs@net.doit.wisc.edu'; = 'ipfix@net.doit.wisc.edu'
Subject:=20 RE: [ipfix] STCP as a default transport not

Okay...

It seems we haven't reached a (firm) conclusion, but = we need=20 to get the draft going and this is a big piece of it. Jeff seems to = propose=20 specifying both (TCP and SCTP). Anyone opposes this? Or should we = stick with=20 one protocol mapping?

We need to start converging on this really soon. =

Thanks,

Reinaldo



> -----Original Message-----
>=20 From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]=20
> Sent: Thursday, October 02, 2003 5:05 = PM=20
> To: 'carter@qosient.com'; = 'alex.audu@alcatel.com'=20
> Cc: 'stbryant@cisco.com'; Penno, Reinaldo=20 [BL60:SF30:EXCH];
>=20 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' =
> Subject: RE: [ipfix] STCP as a default transport = not=20
>
> =
> I'd be interested in knowing what the specific aspects = of=20
> SCTP are that the IPFIX protocol = authors want to=20 use, and how
> they do or do not conflict = in some=20 way with a parallel mapping to TCP.
>=20
> Taking the Diameter approach of = specifying both=20 TCP and SCTP
> would allow for the market = to decide=20 if ubiquity of
> availability or the = special=20 capabilities of SCTP are more important.
>=20
> -- Jeff
>=20
> > -----Original Message----- =
> > From: Carter Bullard [mailto:carter@qosient.com] =
> > Sent: Thursday, October 02, 2003 1:00 = PM=20
> > To: alex.audu@alcatel.com =
> > Cc: stbryant@cisco.com; 'Reinaldo Penno'; =
> > ipfix-chairs@net.doit.wisc.edu;=20 ipfix@net.doit.wisc.edu
> > Subject: = RE: [ipfix]=20 STCP as a default transport not
> >=20
> >
> = > Hey=20 Alex,
> >    Did I say = something=20 wrong?  I firmly believe that people adopt
>=20 > technology when it solves problems.  STCP will get around=20
> as its found
> > to=20 be a real solution.  But with regard to STCP and IPFIX, =
> I read RFC
> > 3257, the = SCTP=20 Applicability Statement, and I don't see where IPFIX
> > fits.  Benefits of SCTP over TCP are: =
> >
> = >   =20 multi-streams support
> = >   =20 multi-homing support
> = >   =20 preservation of message boundaries
>=20 >    unordered reliable message delivery =
> >
> > The first three = I don't see=20 as requirements for IPFIX.
> > I = actually=20 believe the last one to be a problem for IPFIX. STCP is =
> > less efficient that TCP, and so if IPFIX doesn't = need any=20
> of these 4
> >=20 items, then I don't see the applicability.
> >=20
> > Carter
> >=20
> >
> = > >=20 -----Original Message-----
> > > = From: Alex=20 Audu [mailto:alex.audu@alcatel.com]=20
> > > Sent: Thursday, October 02, 2003 = 2:51=20 PM
> > > To: = carter@qosient.com=20
> > > Cc: stbryant@cisco.com; 'Reinaldo = Penno';=20
> > > = ipfix-chairs@net.doit.wisc.edu;=20 ipfix@net.doit.wisc.edu
> > > = Subject: Re:=20 [ipfix] STCP as a default transport not
> = >=20 >
> > >
> >=20 > Hello Carter,
> > > =
> > > If it is true that SCTP hasn't been widely = deployed, it=20
> is probably
> >=20 > because of statements like you have made below. Look, we all know =
> > > SCTP has a lot of benefits = over=20 TCP.  If folks like you
> don't = drive=20
> > > its deployement
>=20 > > by specifying it as default transport, how will it be =
> > > ubiquitous? It is a
> > > self fulfilling prophesy.
>=20 > >
> > > For IETF protocols = that=20 recommend SCTP as defaults, see rfc 3057,
> >=20 > rfc 3331 and rfc 3332 just to name a few.
>=20 > >
> > > Regards, =
> > > Alex.
> > = >=20
> > > Carter Bullard wrote: =
> > >
> > > > = I believe=20 that SCTP-PR is not deployed widely enough
> >=20 > > to be considered a default for any IETF technology. =
> > > > It is not on my Linux RedHat 9.0 = distribution,=20 nor
> > > > my Mac OS-X or my = Windows XP=20 system.  I don't see it
> available = on=20
> > > > any Solaris machine that = I have=20 access to.
> > > > =
> > > > What IETF technology is currently using = SCTP as=20 a
> > > > default = transport?=20
> > > >
> = > >=20 > Carter
> > > > =
> > > > > -----Original Message----- =
> > > > > From: majordomo listserver =
> [mailto:majordomo@mil.doit.wis= c.edu]=20
> > > > > On Behalf Of = Stewart=20 Bryant
> > > > > Sent: = Thursday,=20 October 02, 2003 12:14 PM
> > > = > > To:=20 Reinaldo Penno
> > > > > Cc:=20 ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu =
> > > > > Subject: Re: [ipfix] Ipfix Protocol = open=20 items
> > > > > =
> > > > >
> > = > >=20 >
> > > > > =
> > > > > Reinaldo Penno wrote: =
> > > > >
> > = > >=20 > > Hello,
> > > > > = >=20
> > > > > > Have we zeroed in a = certain=20 transport protocol? TCP,
> > SCTP-PR = or=20
> > > > > > something = else?=20
> > > > > >
>=20 > > > > > I need to write something to explain how = Netflow runs=20 over
> > > > > TCP, but = it=20
> > > > > > seems to me somewhat = of a lower=20 priority if this is not
> > > > = > going=20 to be the
> > > > > > = default=20 protocol. We should focus on explaning how this
>=20 > > > > should work on
> > = > >=20 > > the "choosen one".
> > > = >=20 >
> > > > > I think that = perhaps the=20 question should be put another
> > = > way.=20 There are
> > > > > WG = members who=20 propose SCTP-PR as the default, and
> = SCTP-PR has=20
> > > > > advantage because = of its=20 better flexibility in coping
> > > = with=20 congestion.
> > > > > =
> > > > > So the real question is whether = there are WG=20 members who
> > > think that =
> > > > > the default should be TCP. If no = group comes=20 forward,
> > then we have =
> > > > > our answer. If there is support then = we need=20 to perform
> > a detailed =
> > > > > analysis of the relative merits of = the two=20 protocols.
> > > > > =
> > > > > Stewart
> > >=20 > >
> > > > > =
> > > > > --
> = > > >=20 > Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help"
> > > > > in = message=20 body
> > > > > Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
> > > > > = "unsubscribe ipfix"=20 in message body
> > > > >=20 Archive     http://ipfix.doit.wisc.edu/archive/ =
> > > > >
> > = >=20 >
> > > > --
> > > > = Help        mailto:majordomo@net.doit.wis= c.edu=20 and say
> > > "help" in message = body=20
> > > > Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
> > > > "unsubscribe = ipfix" in=20 message body
> > > >=20 Archive     http://ipfix.doit.wisc.edu/archive/ =
> > >
> > = >
> >
> > =
> >
> > =
> > --
> >=20 Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help"
> > in message = body=20
> > Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say "unsubscribe
> > ipfix" in = message=20 body
> > = Archive     http://ipfix.doit.wisc.edu/archive/ =
> >
>=20

------=_NextPart_000_0068_01C38C06.07905DE0-- -- 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 Oct 7 11:23:08 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 LAA06801 for ; Tue, 7 Oct 2003 11:23:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6tFj-0004rw-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Oct 2003 09:55:55 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6tFh-0004rl-00; Tue, 07 Oct 2003 09:55:53 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h97EteYD005717; Tue, 7 Oct 2003 09:55:41 -0500 (CDT) Message-ID: <3F82D3EB.39B16507@alcatel.com> Date: Tue, 07 Oct 2003 09:55:40 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: carter@qosient.com CC: "'Reinaldo Penno'" , "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , stbryant@cisco.com, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6A9@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello Carter, This excerpt from rfc 3257 indicates SCTP can be used in place of TCP. Moreover, SCTP makes it easier to design a more reliable system due to its multi-homing and multiple streams-per-assoication features. This works well for a redundant (carrier grade) IPFIX architecture. Also, its message oriented feature makes it easier for the application to detect application message boundaries. It would be appreciated if you could point out technical reasons why SCTP is not a good solution for IPFIX. Otherwise, I vote for SCTP for IPFIX. Regards, Alex. ==================================================== 2.2 SCTP service model SCTP is also connection-oriented and provides all the transport services that TCP provides. Many Internet applications therefore should find that either TCP or SCTP will meet their transport requirements. Note, for applications conscious about processing cost, there might be a difference in processing cost associated with running SCTP with only a single ordered stream and one address pair in comparison to running TCP. However, SCTP has some additional capabilities that TCP lacks and This can make SCTP a better choice for some applications and environments: - multi-streams support: SCTP supports the delivery of multiple independent user message streams within a single SCTP association. This capability, when properly used, can alleviate the so-called head-of-line-blocking problem caused by the strict sequence delivery constraint imposed to the user data by TCP. This can be particularly useful for applications that need to exchange multiple, logically separate message streams between two endpoints. - multi-homing support: SCTP provides transparent support for communications between two endpoints of which one or both is multi-homed. SCTP provides monitoring of the reachability of the addresses on the remote endpoint and in the case of failure can transparently failover from the primary address to an alternate address, without upper layer intervention. This capability can be used to build redundant paths between two SCTP endpoints and can be particularly useful for applications that seek transport-level fault tolerance. Achieving path redundancy between two SCTP endpoints normally requires that the two endpoints being equipped with multiple interfaces assigned with multiple addresses and that routing is configured appropriately (see Section 3). - preservation of message boundaries: SCTP preserves application messages boundaries. This is useful when the application data is not a continuous byte stream but comes in logical chunks that the receiver handles separately. In contrast, TCP offers a reliable data stream that has no indication of what an application may consider logical chunks of the data. - unordered reliable message delivery: SCTP supports the transportation of user messages that have no application-specified order, yet need guaranteed reliable delivery. Applications that need to send un-ordered reliable messages or prefer using their own message sequencing and ordering mechanisms may find this SCTP capability useful. ===================================================== Carter Bullard wrote: > I am emphatically against any mention of SCTP, unless someone > can point out how the SCTP applicability statement, RFC 3257, > applies to IPFIX. > > Carter > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] > Sent: Monday, October 06, 2003 11:34 AM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; > 'alex.audu@alcatel.com' > Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; > 'ipfix@net.doit.wisc.edu' > Subject: RE: [ipfix] STCP as a default transport not > > Okay... > It seems we haven't reached a (firm) conclusion, but we need to get the > draft going and this is a big piece of it. Jeff seems to propose specifying > both (TCP and SCTP). Anyone opposes this? Or should we stick with one > protocol mapping? > We need to start converging on this really soon. > Thanks, > Reinaldo > > > -----Original Message----- > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > > Sent: Thursday, October 02, 2003 5:05 PM > > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > I'd be interested in knowing what the specific aspects of > > SCTP are that the IPFIX protocol authors want to use, and how > > they do or do not conflict in some way with a parallel mapping to TCP. > > > > Taking the Diameter approach of specifying both TCP and SCTP > > would allow for the market to decide if ubiquity of > > availability or the special capabilities of SCTP are more important. > > > > -- Jeff > > > > > -----Original Message----- > > > From: Carter Bullard [mailto:carter@qosient.com] > > > Sent: Thursday, October 02, 2003 1:00 PM > > > To: alex.audu@alcatel.com > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > Hey Alex, > > > Did I say something wrong? I firmly believe that people adopt > > > technology when it solves problems. STCP will get around > > as its found > > > to be a real solution. But with regard to STCP and IPFIX, > > I read RFC > > > 3257, the SCTP Applicability Statement, and I don't see where IPFIX > > > fits. Benefits of SCTP over TCP are: > > > > > > multi-streams support > > > multi-homing support > > > preservation of message boundaries > > > unordered reliable message delivery > > > > > > The first three I don't see as requirements for IPFIX. > > > I actually believe the last one to be a problem for IPFIX. STCP is > > > less efficient that TCP, and so if IPFIX doesn't need any > > of these 4 > > > items, then I don't see the applicability. > > > > > > Carter > > > > > > > > > > -----Original Message----- > > > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > > > Sent: Thursday, October 02, 2003 2:51 PM > > > > To: carter@qosient.com > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > Hello Carter, > > > > > > > > If it is true that SCTP hasn't been widely deployed, it > > is probably > > > > because of statements like you have made below. Look, we all know > > > > SCTP has a lot of benefits over TCP. If folks like you > > don't drive > > > > its deployement > > > > by specifying it as default transport, how will it be > > > > ubiquitous? It is a > > > > self fulfilling prophesy. > > > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, > > > > rfc 3331 and rfc 3332 just to name a few. > > > > > > > > Regards, > > > > Alex. > > > > > > > > Carter Bullard wrote: > > > > > > > > > I believe that SCTP-PR is not deployed widely enough > > > > > to be considered a default for any IETF technology. > > > > > It is not on my Linux RedHat 9.0 distribution, nor > > > > > my Mac OS-X or my Windows XP system. I don't see it > > available on > > > > > any Solaris machine that I have access to. > > > > > > > > > > What IETF technology is currently using SCTP as a > > > > > default transport? > > > > > > > > > > Carter > > > > > > > > > > > -----Original Message----- > > > > > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] > > > > > > On Behalf Of Stewart Bryant > > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > > To: Reinaldo Penno > > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > > SCTP-PR or > > > > > > > something else? > > > > > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > > > TCP, but it > > > > > > > seems to me somewhat of a lower priority if this is not > > > > > > going to be the > > > > > > > default protocol. We should focus on explaning how this > > > > > > should work on > > > > > > > the "choosen one". > > > > > > > > > > > > I think that perhaps the question should be put another > > > > way. There are > > > > > > WG members who propose SCTP-PR as the default, and > > SCTP-PR has > > > > > > advantage because of its better flexibility in coping > > > > with congestion. > > > > > > > > > > > > So the real question is whether there are WG members who > > > > think that > > > > > > the default should be TCP. If no group comes forward, > > > then we have > > > > > > our answer. If there is support then we need to perform > > > a detailed > > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > -- > > > > > > 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 Tue Oct 7 11:29:03 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 LAA07700 for ; Tue, 7 Oct 2003 11:29:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6tW4-0005cD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Oct 2003 10:12:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6tW3-0005c1-00; Tue, 07 Oct 2003 10:12:47 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2003 17:11:06 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h97FCfk8024392; Tue, 7 Oct 2003 17:12:41 +0200 (MET DST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-151.cisco.com [64.103.65.151]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA19740; Tue, 7 Oct 2003 16:12:44 +0100 (BST) Message-ID: <3F82D7EB.1010101@cisco.com> Date: Tue, 07 Oct 2003 16:12:43 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: carter@qosient.com, "'Reinaldo Penno'" , "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6A9@ptah.newyork.qosient.com> <3F82D3EB.39B16507@alcatel.com> In-Reply-To: <3F82D3EB.39B16507@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I think that the interest is in using PR-SCTP as described in http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt rather than RFC 2960 SCTP. This claims the following benefits: 1.3 Benefits of PR-SCTP Hereafter, we use the notation "PR-SCTP" to refer to the SCTP protocol extended as defined in this document. The following are some of the advantages for integrating partially reliable data service into SCTP, i.e., benefits of PR-SCTP: 1. Some application layer protocols may benefit from being able to use a single SCTP association to carry both reliable content, -- such as text pages, billing and accounting information, setup signaling -- and unreliable content, e.g. state that is highly sensitive to timeliness, where generating a new packet is more advantageous than transmitting an old one [1]. 2. Partially reliable data traffic carried by PR-SCTP will enjoy the same communication failure detection and protection capabilities as the normal reliable SCTP data traffic does. This includes the ability to: - quickly detect a failed destination address; - fail-over to an alternate destination address, and; - be notified if the data receiver becomes unreachable. 3. In addition to providing unordered unreliable data transfer as UDP does, PR-SCTP can provide ordered unreliable data transfer service. 4. PR-SCTP employs the same congestion control and congestion avoidance for all data traffic, whether reliable or partially reliable - this is very desirable since SCTP enforces TCP-friendliness (unlike UDP.) 5. Because of the chunk bundling function of SCTP, reliable and unreliable messages can be multiplexed over a single PR-SCTP association. Therefore, the number of IP datagrams (and hence the network overhead) can be reduced versus having to send these different types of data using separate protocols. Additionally, this multiplexing allows for port savings versus using different ports for reliable and unreliable connections. ---------- PR-SCTP has the option of being able to configure the exporter to work on a best effort data export basis, rather than being constrained to work on a reliable basis. We should spend some time thinking about the behaviour we want in the exporter when the network is congested, perhaps due to an attack. PR-SCTP gives us the option of running a best effort data collection to gleen what is going on, when a TCP based exporter would otherwise collapse due to backlog on the exporter. Stewart -- 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 Oct 7 11:42:53 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 LAA08739 for ; Tue, 7 Oct 2003 11:42:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6tZI-0005lb-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Oct 2003 10:16:08 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6tZG-0005lT-00; Tue, 07 Oct 2003 10:16:06 -0500 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97FBps06529; Tue, 7 Oct 2003 08:11:52 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 08:11:51 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F930218F28A@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'alex.audu@alcatel.com'" , carter@qosient.com Cc: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , stbryant@cisco.com, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Tue, 7 Oct 2003 08:11:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38CE5.5571561A" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38CE5.5571561A Content-Type: text/plain; charset="ISO-8859-1" I have a question in - multi-homing support. My original idea is that SCTP would bring value in reliability because a exporter could make a connection to exporter A and if it finds that connection has problems, switch to a totally separate collector B. Reading the excerpt below, it seems SCTP can only make the failover when the two interfaces are on the same device, i.e., under the control of the same SCTP stack I guess. "This capability can be used to build redundant paths between two SCTP endpoints....Achieving path redundancy between two SCTP endpoints normally requires that the two endpoints being equipped with multiple interfaces assigned with multiple addresses and that routing is configured appropriately" In this case it seems to me SCTP would not bring real value at least in reliability) since the main concern is being able to switch from collector A to collector B, where A and B are different devices altogether. Could you clarify? Thanks, Reinaldo > -----Original Message----- > From: Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Tuesday, October 07, 2003 10:56 AM > To: carter@qosient.com > Cc: Penno, Reinaldo [BL60:SF30:EXCH]; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; stbryant@cisco.com; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > Hello Carter, > > This excerpt from rfc 3257 indicates SCTP can be used in > place of TCP. Moreover, SCTP makes it easier to design a more > reliable system due to its multi-homing and multiple > streams-per-assoication features. This works well for a > redundant (carrier grade) IPFIX architecture. Also, its > message oriented feature makes it easier for the application > to detect application message boundaries. > > It would be appreciated if you could point out technical > reasons why SCTP is not a good solution for IPFIX. Otherwise, > I vote for SCTP for IPFIX. > > Regards, > Alex. > > ==================================================== > > 2.2 SCTP service model > > SCTP is also connection-oriented and provides all the transport > services that TCP provides. Many Internet applications therefore > should find that either TCP or SCTP will meet their transport > requirements. Note, for applications conscious about processing > cost, there might be a difference in processing cost > associated with > running SCTP with only a single ordered stream and one address pair > in comparison to running TCP. > > However, SCTP has some additional capabilities that TCP lacks and > This can make SCTP a better choice for some applications and > environments: > > - multi-streams support: > > SCTP supports the delivery of multiple independent user message > streams within a single SCTP association. This capability, when > properly used, can alleviate the so-called head-of-line-blocking > problem caused by the strict sequence delivery constraint > imposed to > the user data by TCP. > > This can be particularly useful for applications that need to > exchange multiple, logically separate message streams between two > endpoints. > > - multi-homing support: > > SCTP provides transparent support for communications between two > endpoints of which one or both is multi-homed. > > SCTP provides monitoring of the reachability of the > addresses on the > remote endpoint and in the case of failure can > transparently failover > from the primary address to an alternate address, without > upper layer > intervention. > > This capability can be used to build redundant paths > between two SCTP > endpoints and can be particularly useful for applications that seek > transport-level fault tolerance. > > Achieving path redundancy between two SCTP endpoints normally > requires that the two endpoints being equipped with multiple > interfaces assigned with multiple addresses and that routing is > configured appropriately (see Section 3). > > - preservation of message boundaries: > > SCTP preserves application messages boundaries. This is > useful when > the application data is not a continuous byte stream but comes in > logical chunks that the receiver handles separately. > > In contrast, TCP offers a reliable data stream that has no > indication > of what an application may consider logical chunks of the data. > > - unordered reliable message delivery: > > SCTP supports the transportation of user messages that have no > application-specified order, yet need guaranteed reliable delivery. > > Applications that need to send un-ordered reliable > messages or prefer > using their own message sequencing and ordering mechanisms may find > this SCTP capability useful. > > ===================================================== > > Carter Bullard wrote: > > > I am emphatically against any mention of SCTP, unless someone can > > point out how the SCTP applicability statement, RFC 3257, > applies to > > IPFIX. > > > > Carter > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] > > Sent: Monday, October 06, 2003 11:34 AM > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; > > 'alex.audu@alcatel.com' > > Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; > > 'ipfix@net.doit.wisc.edu' > > Subject: RE: [ipfix] STCP as a default transport not > > > > Okay... > > It seems we haven't reached a (firm) conclusion, but we need to get > > the draft going and this is a big piece of it. Jeff seems > to propose > > specifying both (TCP and SCTP). Anyone opposes this? Or should we > > stick with one protocol mapping? We need to start > converging on this > > really soon. Thanks, > > Reinaldo > > > > > -----Original Message----- > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > [mailto:jeff.meyer2@hp.com] > > > Sent: Thursday, October 02, 2003 5:05 PM > > > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > > > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > > > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > I'd be interested in knowing what the specific aspects of > SCTP are > > > that the IPFIX protocol authors want to use, and how they > do or do > > > not conflict in some way with a parallel mapping to TCP. > > > > > > Taking the Diameter approach of specifying both TCP and > SCTP would > > > allow for the market to decide if ubiquity of availability or the > > > special capabilities of SCTP are more important. > > > > > > -- Jeff > > > > > > > -----Original Message----- > > > > From: Carter Bullard [mailto:carter@qosient.com] > > > > Sent: Thursday, October 02, 2003 1:00 PM > > > > To: alex.audu@alcatel.com > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > > > > Hey Alex, > > > > Did I say something wrong? I firmly believe that > people adopt > > > > technology when it solves problems. STCP will get around > > > as its found > > > > to be a real solution. But with regard to STCP and IPFIX, > > > I read RFC > > > > 3257, the SCTP Applicability Statement, and I don't see where > > > > IPFIX fits. Benefits of SCTP over TCP are: > > > > > > > > multi-streams support > > > > multi-homing support > > > > preservation of message boundaries > > > > unordered reliable message delivery > > > > > > > > The first three I don't see as requirements for IPFIX. > > > > I actually believe the last one to be a problem for > IPFIX. STCP is > > > > less efficient that TCP, and so if IPFIX doesn't need any > > > of these 4 > > > > items, then I don't see the applicability. > > > > > > > > Carter > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > > > > Sent: Thursday, October 02, 2003 2:51 PM > > > > > To: carter@qosient.com > > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > > > > Hello Carter, > > > > > > > > > > If it is true that SCTP hasn't been widely deployed, it > > > is probably > > > > > because of statements like you have made below. Look, we all > > > > > know SCTP has a lot of benefits over TCP. If folks like you > > > don't drive > > > > > its deployement > > > > > by specifying it as default transport, how will it be > > > > > ubiquitous? It is a self fulfilling prophesy. > > > > > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc > > > > > 3057, rfc 3331 and rfc 3332 just to name a few. > > > > > > > > > > Regards, > > > > > Alex. > > > > > > > > > > Carter Bullard wrote: > > > > > > > > > > > I believe that SCTP-PR is not deployed widely enough to be > > > > > > considered a default for any IETF technology. It is > not on my > > > > > > Linux RedHat 9.0 distribution, nor my Mac OS-X or > my Windows > > > > > > XP system. I don't see it > > > available on > > > > > > any Solaris machine that I have access to. > > > > > > > > > > > > What IETF technology is currently using SCTP as a default > > > > > > transport? > > > > > > > > > > > > Carter > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: majordomo listserver > > > [mailto:majordomo@mil.doit.wisc.edu] > > > > > > > On Behalf Of Stewart Bryant > > > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > > > To: Reinaldo Penno > > > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu > > > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > > > SCTP-PR or > > > > > > > > something else? > > > > > > > > > > > > > > > > I need to write something to explain how > Netflow runs over > > > > > > > TCP, but it > > > > > > > > seems to me somewhat of a lower priority if this is not > > > > > > > going to be the > > > > > > > > default protocol. We should focus on explaning how this > > > > > > > should work on > > > > > > > > the "choosen one". > > > > > > > > > > > > > > I think that perhaps the question should be put another > > > > > way. There are > > > > > > > WG members who propose SCTP-PR as the default, and > > > SCTP-PR has > > > > > > > advantage because of its better flexibility in coping > > > > > with congestion. > > > > > > > > > > > > > > So the real question is whether there are WG members who > > > > > think that > > > > > > > the default should be TCP. If no group comes forward, > > > > then we have > > > > > > > our answer. If there is support then we need to perform > > > > a detailed > > > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > 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/ > > ------_=_NextPart_001_01C38CE5.5571561A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] STCP as a default transport not

I have a question in - multi-homing support.

My original idea is that SCTP would bring value in = reliability because a exporter could make a connection to exporter A = and if it finds that connection has problems, switch to a totally = separate collector B.

Reading the excerpt below, it seems SCTP can only = make the failover when the two interfaces are on the same device, i.e., = under the control of the same SCTP stack I guess. 

"This capability can be used to build redundant = paths between two SCTP endpoints....Achieving path redundancy between = two SCTP endpoints normally requires that the two endpoints being = equipped with multiple interfaces assigned with multiple addresses and = that routing is configured appropriately"

In this case it seems to me SCTP would not bring real = value at least in reliability) since the main concern is being able to = switch from collector A to collector B, where A and B are different = devices altogether.

Could you clarify?

Thanks,

Reinaldo

> -----Original Message-----
> From: Alex Audu [mailto:alex.audu@alcatel.com] =
> Sent: Tuesday, October 07, 2003 10:56 AM
> To: carter@qosient.com
> Cc: Penno, Reinaldo [BL60:SF30:EXCH]; = 'MEYER,JEFFREY D
> (HP-Cupertino,ex1)'; stbryant@cisco.com; =
> ipfix-chairs@net.doit.wisc.edu; = ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] STCP as a default = transport not
>
>
> Hello Carter,
>
> This excerpt from rfc 3257 indicates SCTP can = be used in
> place of TCP. Moreover, SCTP makes it easier to = design a more
> reliable system due to its multi-homing and = multiple
> streams-per-assoication features. This works = well for a
> redundant (carrier grade) IPFIX = architecture.  Also, its
> message oriented feature makes it easier for = the application
> to detect application message = boundaries.
>
> It would be appreciated if you could point out = technical
> reasons why SCTP is not a good solution for = IPFIX. Otherwise,
> I vote for SCTP for IPFIX.
>
> Regards,
> Alex.
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> 2.2 SCTP service model
>
>    SCTP is also = connection-oriented and provides all the transport
>    services that TCP = provides.  Many Internet applications therefore
>    should find that either TCP = or SCTP will meet their transport
>    requirements.  Note, for = applications conscious about processing
>    cost, there might be a = difference in processing cost
> associated with
>    running SCTP with only a = single ordered stream and one address pair
>    in comparison to running = TCP.
>
>    However, SCTP has some = additional capabilities that TCP lacks and
>    This can make SCTP a better = choice for some applications and
>    environments:
>
>    - multi-streams = support:
>
>    SCTP supports the delivery of = multiple independent user message
>    streams within a single SCTP = association.  This capability, when
>    properly used, can alleviate = the so-called head-of-line-blocking
>    problem caused by the strict = sequence delivery constraint
> imposed to
>    the user data by TCP.
>
>    This can be particularly = useful for applications that need to
>    exchange multiple, logically = separate message streams between two
>    endpoints.
>
>    - multi-homing = support:
>
>    SCTP provides transparent = support for communications between two
>    endpoints of which one or = both is multi-homed.
>
>    SCTP provides monitoring of = the reachability of the
> addresses on the
>    remote endpoint and in the = case of failure can
> transparently failover
>    from the primary address to = an alternate address, without
> upper layer
>    intervention.
>
>    This capability can be used = to build redundant paths
> between two SCTP
>    endpoints and can be = particularly useful for applications that seek
>    transport-level fault = tolerance.
>
>    Achieving path redundancy = between two SCTP endpoints normally
>    requires that the two = endpoints being equipped with multiple
>    interfaces assigned with = multiple addresses and that routing is
>    configured appropriately (see = Section 3).
>
>    - preservation of message = boundaries:
>
>    SCTP preserves application = messages boundaries.  This is
> useful when
>    the application data is not a = continuous byte stream but comes in
>    logical chunks that the = receiver handles separately.
>
>    In contrast, TCP offers a = reliable data stream that has no
> indication
>    of what an application may = consider logical chunks of the data.
>
>    - unordered reliable message = delivery:
>
>    SCTP supports the = transportation of user messages that have no
>    application-specified order, = yet need guaranteed reliable delivery.
>
>    Applications that need to = send un-ordered reliable
> messages or prefer
>    using their own message = sequencing and ordering mechanisms may find
>    this SCTP capability = useful.
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>
> Carter Bullard wrote:
>
> > I am emphatically against any mention of = SCTP, unless someone can
> > point out how the SCTP applicability = statement, RFC 3257,
> applies to
> > IPFIX.
> >
> > Carter
> >
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.c= om]
> > Sent: Monday, October 06, 2003 11:34 = AM
> > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; = 'carter@qosient.com';
> > 'alex.audu@alcatel.com'
> > Cc: 'stbryant@cisco.com'; = 'ipfix-chairs@net.doit.wisc.edu';
> > 'ipfix@net.doit.wisc.edu'
> > Subject: RE: [ipfix] STCP as a default = transport not
> >
> > Okay...
> > It seems we haven't reached a (firm) = conclusion, but we need to get
> > the draft going and this is a big piece of = it. Jeff seems
> to propose
> > specifying both (TCP and SCTP). Anyone = opposes this? Or should we
> > stick with one protocol mapping? We need = to start
> converging on this
> > really soon. Thanks,
> > Reinaldo
> >
> > > -----Original Message-----
> > > From: MEYER,JEFFREY D = (HP-Cupertino,ex1)
> [mailto:jeff.meyer2@hp.com]=
> > > Sent: Thursday, October 02, 2003 5:05 = PM
> > > To: 'carter@qosient.com'; = 'alex.audu@alcatel.com'
> > > Cc: 'stbryant@cisco.com'; Penno, = Reinaldo [BL60:SF30:EXCH];
> > > 'ipfix-chairs@net.doit.wisc.edu'; = 'ipfix@net.doit.wisc.edu'
> > > Subject: RE: [ipfix] STCP as a = default transport not
> > >
> > >
> > > I'd be interested in knowing what the = specific aspects of
> SCTP are
> > > that the IPFIX protocol authors want = to use, and how they
> do or do
> > > not conflict in some way with a = parallel mapping to TCP.
> > >
> > > Taking the Diameter approach of = specifying both TCP and
> SCTP would
> > > allow for the market to decide if = ubiquity of availability or the
> > > special capabilities of SCTP are more = important.
> > >
> > > -- Jeff
> > >
> > > > -----Original = Message-----
> > > > From: Carter Bullard [mailto:carter@qosient.com]=
> > > > Sent: Thursday, October 02, 2003 = 1:00 PM
> > > > To: alex.audu@alcatel.com
> > > > Cc: stbryant@cisco.com; = 'Reinaldo Penno';
> > > > ipfix-chairs@net.doit.wisc.edu; = ipfix@net.doit.wisc.edu
> > > > Subject: RE: [ipfix] STCP as a = default transport not
> > > >
> > > >
> > > > Hey Alex,
> > > >    Did I say = something wrong?  I firmly believe that
> people adopt
> > > > technology when it solves = problems.  STCP will get around
> > > as its found
> > > > to be a real solution.  But = with regard to STCP and IPFIX,
> > > I read RFC
> > > > 3257, the SCTP Applicability = Statement, and I don't see where
> > > > IPFIX fits.  Benefits of = SCTP over TCP are:
> > > >
> > > >    multi-streams = support
> > > >    multi-homing = support
> > > >    preservation = of message boundaries
> > > >    unordered = reliable message delivery
> > > >
> > > > The first three I don't see as = requirements for IPFIX.
> > > > I actually believe the last one = to be a problem for
> IPFIX. STCP is
> > > > less efficient that TCP, and so = if IPFIX doesn't need any
> > > of these 4
> > > > items, then I don't see the = applicability.
> > > >
> > > > Carter
> > > >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Alex Audu [mailto:alex.audu@alcatel.com]<= /FONT>
> > > > > Sent: Thursday, October 02, = 2003 2:51 PM
> > > > > To: = carter@qosient.com
> > > > > Cc: stbryant@cisco.com; = 'Reinaldo Penno';
> > > > > = ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > > > Subject: Re: [ipfix] STCP = as a default transport not
> > > > >
> > > > >
> > > > > Hello Carter,
> > > > >
> > > > > If it is true that SCTP = hasn't been widely deployed, it
> > > is probably
> > > > > because of statements like = you have made below. Look, we all
> > > > > know SCTP has a lot of = benefits over TCP.  If folks like you
> > > don't drive
> > > > > its deployement
> > > > > by specifying it as default = transport, how will it be
> > > > > ubiquitous? It is a self = fulfilling prophesy.
> > > > >
> > > > > For IETF protocols that = recommend SCTP as defaults, see rfc
> > > > > 3057, rfc 3331 and rfc 3332 = just to name a few.
> > > > >
> > > > > Regards,
> > > > > Alex.
> > > > >
> > > > > Carter Bullard = wrote:
> > > > >
> > > > > > I believe that SCTP-PR = is not deployed widely enough to be
> > > > > > considered a default = for any IETF technology. It is
> not on my
> > > > > > Linux RedHat 9.0 = distribution, nor my Mac OS-X or
> my Windows
> > > > > > XP system.  I = don't see it
> > > available on
> > > > > > any Solaris machine = that I have access to.
> > > > > >
> > > > > > What IETF technology = is currently using SCTP as a default
> > > > > > transport?
> > > > > >
> > > > > > Carter
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: majordomo = listserver
> > > [mailto:majordomo@mil.doit.wi= sc.edu]
> > > > > > > On Behalf Of = Stewart Bryant
> > > > > > > Sent: Thursday, = October 02, 2003 12:14 PM
> > > > > > > To: Reinaldo = Penno
> > > > > > > Cc: = ipfix-chairs@net.doit.wisc.edu;
> ipfix@net.doit.wisc.edu
> > > > > > > Subject: Re: = [ipfix] Ipfix Protocol open items
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Reinaldo Penno = wrote:
> > > > > > >
> > > > > > > > = Hello,
> > > > > > > >
> > > > > > > > Have we = zeroed in a certain transport protocol? TCP,
> > > > SCTP-PR or
> > > > > > > > something = else?
> > > > > > > >
> > > > > > > > I need to = write something to explain how
> Netflow runs over
> > > > > > > TCP, but = it
> > > > > > > > seems to me = somewhat of a lower priority if this is not
> > > > > > > going to be = the
> > > > > > > > default = protocol. We should focus on explaning how this
> > > > > > > should work = on
> > > > > > > > the = "choosen one".
> > > > > > >
> > > > > > > I think that = perhaps the question should be put another
> > > > > way. There are
> > > > > > > WG members who = propose SCTP-PR as the default, and
> > > SCTP-PR has
> > > > > > > advantage because = of its better flexibility in coping
> > > > > with congestion.
> > > > > > >
> > > > > > > So the real = question is whether there are WG members who
> > > > > think that
> > > > > > > the default = should be TCP. If no group comes forward,
> > > > then we have
> > > > > > > our answer. If = there is support then we need to perform
> > > > a detailed
> > > > > > > analysis of the = relative merits of the two protocols.
> > > > > > >
> > > > > > > Stewart
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > = Help        mailto:majordomo@net.doit.wi= sc.edu
> and say "help"
> > > > > > > in message = body
> > > > > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> > > > > > > "unsubscribe = ipfix" in message body
> > > > > > > = Archive     http://ipfix.doit.wisc.edu/archive/
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > = Help        mailto:majordomo@net.doit.wi= sc.edu and say
> > > > > "help" in message = body
> > > > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> > > > > > "unsubscribe = ipfix" in message body
> > > > > > = Archive     http://ipfix.doit.wisc.edu/archive/
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > = Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
> > > > in message body
> > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> > > > "unsubscribe ipfix" in = message body
> > > > Archive     = http://ipfix.doit.wisc.edu/archive/
> > > >
> > >
> >
> > --
> > = Help        mailto:majordomo@net.doit.wi= sc.edu and say
> "help" in message body
> > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say "unsubscribe
> > ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
>
>

------_=_NextPart_001_01C38CE5.5571561A-- -- 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 Oct 7 12:01: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 MAA09644 for ; Tue, 7 Oct 2003 12:01:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6tqh-0006X5-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Oct 2003 10:34:07 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A6tqg-0006Ww-00 for ipfix@net.doit.wisc.edu; Tue, 07 Oct 2003 10:34:06 -0500 Received: (qmail 47636 invoked from network); 7 Oct 2003 15:34:05 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 7 Oct 2003 15:34:05 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h97FY5X14308; Tue, 7 Oct 2003 11:34:05 -0400 Reply-To: From: "Carter Bullard" To: Cc: "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , , Subject: RE: [ipfix] STCP as a default transport not Date: Tue, 7 Oct 2003 11:34:02 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6AB@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE029@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Stewart, The default transport for a standards track protocol should at least be an RFC. I'm not against having hooks to jumpstart a PR-STCP association in IPFIX, but not as the default. And those hooks should come after the PR-STCP is described as an RFC and has had some time to bake, and possibly more important, after there is a working IPFIX to find out if you even need its features. As an internet draft its just an idea. Carter > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, October 07, 2003 10:13 AM > To: alex.audu@alcatel.com > Cc: carter@qosient.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > > I think that the interest is in using PR-SCTP as described in > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > rather than RFC 2960 SCTP. > > This claims the following benefits: > > > 1.3 Benefits of PR-SCTP > > Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > protocol extended as defined in this document. > > The following are some of the advantages for integrating partially > reliable data service into SCTP, i.e., benefits of PR-SCTP: > > 1. Some application layer protocols may benefit from > being able to > use a single SCTP association to carry both reliable > content, -- > such as text pages, billing and accounting information, setup > signaling -- and unreliable content, e.g. state that is highly > sensitive to timeliness, where generating a new packet is more > advantageous than transmitting an old one [1]. > > 2. Partially reliable data traffic carried by PR-SCTP > will enjoy the > same communication failure detection and protection > capabilities > as the normal reliable SCTP data traffic does. This > includes the > ability to: - quickly detect a failed destination address; - > fail-over to an alternate destination address, and; - > be notified > if the data receiver becomes unreachable. > > 3. In addition to providing unordered unreliable data transfer as > UDP does, PR-SCTP can provide ordered unreliable data transfer > service. > > 4. PR-SCTP employs the same congestion control and congestion > avoidance for all data traffic, whether reliable or partially > reliable - this is very desirable since SCTP enforces > TCP-friendliness (unlike UDP.) > > 5. Because of the chunk bundling function of SCTP, reliable and > unreliable messages can be multiplexed over a single PR-SCTP > association. Therefore, the number of IP datagrams (and hence > the network overhead) can be reduced versus having to > send these > different types of data using separate protocols. > Additionally, > this multiplexing allows for port savings versus > using different > ports for reliable and unreliable connections. > > ---------- > > PR-SCTP has the option of being able to configure the > exporter to work on a > best effort data export basis, rather than being constrained > to work on a > reliable basis. > > We should spend some time thinking about the behaviour we want in the > exporter when the network is congested, perhaps due to an > attack. PR-SCTP > gives us the option of running a best effort data collection > to gleen what > is going on, when a TCP based exporter would otherwise collapse due to > backlog on the exporter. > > Stewart > > > -- 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 Oct 7 12:16:47 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 MAA10363 for ; Tue, 7 Oct 2003 12:16:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6uKn-0007eB-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Oct 2003 11:05:13 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A6uKm-0007dy-00 for ipfix@net.doit.wisc.edu; Tue, 07 Oct 2003 11:05:12 -0500 Received: (qmail 66484 invoked from network); 7 Oct 2003 16:05:11 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 7 Oct 2003 16:05:11 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h97G5BX14338; Tue, 7 Oct 2003 12:05:11 -0400 Reply-To: From: "Carter Bullard" To: , Cc: "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , , Subject: RE: [ipfix] STCP as a default transport not Date: Tue, 7 Oct 2003 12:05:08 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6AC@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE02A@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Stewart, > > We should spend some time thinking about the behavior we want in the > exporter when the network is congested, perhaps due to an > attack. PR-SCTP > gives us the option of running a best effort data collection > to gleen what > is going on, when a TCP based exporter would otherwise collapse due to > backlog on the exporter. This is a real engineering issue to talk about. Issues in producer/consumer dynamics are real problems for IPFIX, especially when the flow record source is generating 1M records per second, which my probes are capable of doing. In my experience, the reader/collector not keeping up is never a network congestion problem, it is almost always a reader/collector resource problem, slow disks, not enough memory, competing processes, whatever. It happens in SMP multi-threaded environments where the flow generator and its collector are on the same machine, it happens when the consumer is on the other end of a dedicated ATM, hyper-channel or infiniband links. Its not an issue of reliable vs unreliable transport, its more an issue of what does the probe do when it finds it has 1M records that aren't being consumed, and another 1M records are coming very soon. Does it store them, drop them with an indication? Does it proactively seek an alternate association, the same association or does it wait for the multiple readers to come back when they are ready. Are there going to be multiple readers? Usually the monitor is being attacked, or its generating twice the load because something else is being attacked in the network. No congestion, just a lot of records. I don't think PR-SCTP touches these problems. If you want the record generator to have a proactive role in failover and recover, maybe RTP/RTCP would be a better choice. Explicit feedback control channel provides enough to decide if it should fail over. Carter > > Stewart > > > > > -- > 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 Tue Oct 7 13:01: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 NAA11719 for ; Tue, 7 Oct 2003 13:01:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6v3Y-0001l6-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Oct 2003 11:51:28 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6v3W-0001ku-00; Tue, 07 Oct 2003 11:51:26 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h97GovXU010205; Tue, 7 Oct 2003 11:50:57 -0500 (CDT) Message-ID: <3F82EEEF.FEFC7942@alcatel.com> Date: Tue, 07 Oct 2003 11:50:55 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: carter@qosient.com, "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , stbryant@cisco.com, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <0A11633F61BD9F40B43ABCC694004F930218F28A@zsc3c026.us.nortel.com> Content-Type: multipart/alternative; boundary="------------F01B2FABBE8CDC163C4D83E5" Precedence: bulk Sender: majordomo listserver --------------F01B2FABBE8CDC163C4D83E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Reinaldo, Redundancy can be archieved in many ways. One simple way is to have a "Collector box" containing mutiple collector processes. The collector processes may be running on different processors. You can also have two different collector boxes (devices) on the same network. with different addresses, with one address being used by the Exporter. What multi-homing provides is the ability for the Exporter to reach the other collector address if the default (collector) address is unreachable. Now, if you mirror the two collectors with an internal link, then you have a multi-homed network and a fully redundant system. Of course, we are talking about implementation details. The key is SCTP enables you to do this much more easily. If you are collecting billing information with IPFIX, I think issues like this it become important. Regards, Alex. Reinaldo Penno wrote: > > > I have a question in - multi-homing support. > > My original idea is that SCTP would bring value in reliability because > a exporter could make a connection to exporter A and if it finds that > connection has problems, switch to a totally separate collector B. > > Reading the excerpt below, it seems SCTP can only make the failover > when the two interfaces are on the same device, i.e., under the > control of the same SCTP stack I guess. > > "This capability can be used to build redundant paths between two SCTP > endpoints....Achieving path redundancy between two SCTP endpoints > normally requires that the two endpoints being equipped with multiple > interfaces assigned with multiple addresses and that routing is > configured appropriately" > > In this case it seems to me SCTP would not bring real value at least > in reliability) since the main concern is being able to switch from > collector A to collector B, where A and B are different devices > altogether. > > Could you clarify? > > Thanks, > > Reinaldo > > > -----Original Message----- > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > Sent: Tuesday, October 07, 2003 10:56 AM > > To: carter@qosient.com > > Cc: Penno, Reinaldo [BL60:SF30:EXCH]; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; stbryant@cisco.com; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Hello Carter, > > > > This excerpt from rfc 3257 indicates SCTP can be used in > > place of TCP. Moreover, SCTP makes it easier to design a more > > reliable system due to its multi-homing and multiple > > streams-per-assoication features. This works well for a > > redundant (carrier grade) IPFIX architecture. Also, its > > message oriented feature makes it easier for the application > > to detect application message boundaries. > > > > It would be appreciated if you could point out technical > > reasons why SCTP is not a good solution for IPFIX. Otherwise, > > I vote for SCTP for IPFIX. > > > > Regards, > > Alex. > > > > ==================================================== > > > > 2.2 SCTP service model > > > > SCTP is also connection-oriented and provides all the transport > > services that TCP provides. Many Internet applications therefore > > > should find that either TCP or SCTP will meet their transport > > requirements. Note, for applications conscious about processing > > cost, there might be a difference in processing cost > > associated with > > running SCTP with only a single ordered stream and one address > pair > > in comparison to running TCP. > > > > However, SCTP has some additional capabilities that TCP lacks and > > > This can make SCTP a better choice for some applications and > > environments: > > > > - multi-streams support: > > > > SCTP supports the delivery of multiple independent user message > > streams within a single SCTP association. This capability, when > > properly used, can alleviate the so-called head-of-line-blocking > > problem caused by the strict sequence delivery constraint > > imposed to > > the user data by TCP. > > > > This can be particularly useful for applications that need to > > exchange multiple, logically separate message streams between two > > > endpoints. > > > > - multi-homing support: > > > > SCTP provides transparent support for communications between two > > endpoints of which one or both is multi-homed. > > > > SCTP provides monitoring of the reachability of the > > addresses on the > > remote endpoint and in the case of failure can > > transparently failover > > from the primary address to an alternate address, without > > upper layer > > intervention. > > > > This capability can be used to build redundant paths > > between two SCTP > > endpoints and can be particularly useful for applications that > seek > > transport-level fault tolerance. > > > > Achieving path redundancy between two SCTP endpoints normally > > requires that the two endpoints being equipped with multiple > > interfaces assigned with multiple addresses and that routing is > > configured appropriately (see Section 3). > > > > - preservation of message boundaries: > > > > SCTP preserves application messages boundaries. This is > > useful when > > the application data is not a continuous byte stream but comes in > > > logical chunks that the receiver handles separately. > > > > In contrast, TCP offers a reliable data stream that has no > > indication > > of what an application may consider logical chunks of the data. > > > > - unordered reliable message delivery: > > > > SCTP supports the transportation of user messages that have no > > application-specified order, yet need guaranteed reliable > delivery. > > > > Applications that need to send un-ordered reliable > > messages or prefer > > using their own message sequencing and ordering mechanisms may > find > > this SCTP capability useful. > > > > ===================================================== > > > > Carter Bullard wrote: > > > > > I am emphatically against any mention of SCTP, unless someone can > > > point out how the SCTP applicability statement, RFC 3257, > > applies to > > > IPFIX. > > > > > > Carter > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] > > > Sent: Monday, October 06, 2003 11:34 AM > > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; > > > 'alex.audu@alcatel.com' > > > Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; > > > 'ipfix@net.doit.wisc.edu' > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Okay... > > > It seems we haven't reached a (firm) conclusion, but we need to > get > > > the draft going and this is a big piece of it. Jeff seems > > to propose > > > specifying both (TCP and SCTP). Anyone opposes this? Or should we > > > stick with one protocol mapping? We need to start > > converging on this > > > really soon. Thanks, > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > > [mailto:jeff.meyer2@hp.com] > > > > Sent: Thursday, October 02, 2003 5:05 PM > > > > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > > > > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > > > > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > > > > I'd be interested in knowing what the specific aspects of > > SCTP are > > > > that the IPFIX protocol authors want to use, and how they > > do or do > > > > not conflict in some way with a parallel mapping to TCP. > > > > > > > > Taking the Diameter approach of specifying both TCP and > > SCTP would > > > > allow for the market to decide if ubiquity of availability or > the > > > > special capabilities of SCTP are more important. > > > > > > > > -- Jeff > > > > > > > > > -----Original Message----- > > > > > From: Carter Bullard [mailto:carter@qosient.com] > > > > > Sent: Thursday, October 02, 2003 1:00 PM > > > > > To: alex.audu@alcatel.com > > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > > > > > > > Hey Alex, > > > > > Did I say something wrong? I firmly believe that > > people adopt > > > > > technology when it solves problems. STCP will get around > > > > as its found > > > > > to be a real solution. But with regard to STCP and IPFIX, > > > > I read RFC > > > > > 3257, the SCTP Applicability Statement, and I don't see where > > > > > IPFIX fits. Benefits of SCTP over TCP are: > > > > > > > > > > multi-streams support > > > > > multi-homing support > > > > > preservation of message boundaries > > > > > unordered reliable message delivery > > > > > > > > > > The first three I don't see as requirements for IPFIX. > > > > > I actually believe the last one to be a problem for > > IPFIX. STCP is > > > > > less efficient that TCP, and so if IPFIX doesn't need any > > > > of these 4 > > > > > items, then I don't see the applicability. > > > > > > > > > > Carter > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > > > > > Sent: Thursday, October 02, 2003 2:51 PM > > > > > > To: carter@qosient.com > > > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > > > > > > > Hello Carter, > > > > > > > > > > > > If it is true that SCTP hasn't been widely deployed, it > > > > is probably > > > > > > because of statements like you have made below. Look, we all > > > > > > > know SCTP has a lot of benefits over TCP. If folks like you > > > > > don't drive > > > > > > its deployement > > > > > > by specifying it as default transport, how will it be > > > > > > ubiquitous? It is a self fulfilling prophesy. > > > > > > > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc > > > > > > 3057, rfc 3331 and rfc 3332 just to name a few. > > > > > > > > > > > > Regards, > > > > > > Alex. > > > > > > > > > > > > Carter Bullard wrote: > > > > > > > > > > > > > I believe that SCTP-PR is not deployed widely enough to be > > > > > > > > considered a default for any IETF technology. It is > > not on my > > > > > > > Linux RedHat 9.0 distribution, nor my Mac OS-X or > > my Windows > > > > > > > XP system. I don't see it > > > > available on > > > > > > > any Solaris machine that I have access to. > > > > > > > > > > > > > > What IETF technology is currently using SCTP as a default > > > > > > > transport? > > > > > > > > > > > > > > Carter > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: majordomo listserver > > > > [mailto:majordomo@mil.doit.wisc.edu] > > > > > > > > On Behalf Of Stewart Bryant > > > > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > > > > To: Reinaldo Penno > > > > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; > > ipfix@net.doit.wisc.edu > > > > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > > > > SCTP-PR or > > > > > > > > > something else? > > > > > > > > > > > > > > > > > > I need to write something to explain how > > Netflow runs over > > > > > > > > TCP, but it > > > > > > > > > seems to me somewhat of a lower priority if this is > not > > > > > > > > going to be the > > > > > > > > > default protocol. We should focus on explaning how > this > > > > > > > > should work on > > > > > > > > > the "choosen one". > > > > > > > > > > > > > > > > I think that perhaps the question should be put another > > > > > > way. There are > > > > > > > > WG members who propose SCTP-PR as the default, and > > > > SCTP-PR has > > > > > > > > advantage because of its better flexibility in coping > > > > > > with congestion. > > > > > > > > > > > > > > > > So the real question is whether there are WG members who > > > > > > > think that > > > > > > > > the default should be TCP. If no group comes forward, > > > > > then we have > > > > > > > > our answer. If there is support then we need to perform > > > > > a detailed > > > > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > 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/ > > > > --------------F01B2FABBE8CDC163C4D83E5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Reinaldo,

Redundancy can be archieved in many ways. One simple way is to have a
"Collector box" containing mutiple collector processes. The collector processes
may be running on different processors.

You can also have two different collector boxes (devices) on the same network.
with different addresses, with one address being used by the Exporter. What multi-homing provides is the ability for the Exporter to reach the other collector
address if the default (collector) address is unreachable. Now, if you mirror the two collectors with an internal link, then you have a multi-homed network and a fully redundant system.

Of course, we are talking about implementation details. The key is SCTP
enables you to do this much more easily.  If you are collecting billing information
with IPFIX, I think issues like this it become important.

Regards,
Alex.

Reinaldo Penno wrote:

 

I have a question in - multi-homing support.

My original idea is that SCTP would bring value in reliability because a exporter could make a connection to exporter A and if it finds that connection has problems, switch to a totally separate collector B.

Reading the excerpt below, it seems SCTP can only make the failover when the two interfaces are on the same device, i.e., under the control of the same SCTP stack I guess.

"This capability can be used to build redundant paths between two SCTP endpoints....Achieving path redundancy between two SCTP endpoints normally requires that the two endpoints being equipped with multiple interfaces assigned with multiple addresses and that routing is configured appropriately"

In this case it seems to me SCTP would not bring real value at least in reliability) since the main concern is being able to switch from collector A to collector B, where A and B are different devices altogether.

Could you clarify?

Thanks,

Reinaldo

> -----Original Message-----
> From: Alex Audu [mailto:alex.audu@alcatel.com]
> Sent: Tuesday, October 07, 2003 10:56 AM
> To: carter@qosient.com
> Cc: Penno, Reinaldo [BL60:SF30:EXCH]; 'MEYER,JEFFREY D
> (HP-Cupertino,ex1)'; stbryant@cisco.com;
> ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] STCP as a default transport not
>
>
> Hello Carter,
>
> This excerpt from rfc 3257 indicates SCTP can be used in
> place of TCP. Moreover, SCTP makes it easier to design a more
> reliable system due to its multi-homing and multiple
> streams-per-assoication features. This works well for a
> redundant (carrier grade) IPFIX architecture.  Also, its
> message oriented feature makes it easier for the application
> to detect application message boundaries.
>
> It would be appreciated if you could point out technical
> reasons why SCTP is not a good solution for IPFIX. Otherwise,
> I vote for SCTP for IPFIX.
>
> Regards,
> Alex.
>
> ====================================================
>
> 2.2 SCTP service model
>
>    SCTP is also connection-oriented and provides all the transport
>    services that TCP provides.  Many Internet applications therefore
>    should find that either TCP or SCTP will meet their transport
>    requirements.  Note, for applications conscious about processing
>    cost, there might be a difference in processing cost
> associated with
>    running SCTP with only a single ordered stream and one address pair
>    in comparison to running TCP.
>
>    However, SCTP has some additional capabilities that TCP lacks and
>    This can make SCTP a better choice for some applications and
>    environments:
>
>    - multi-streams support:
>
>    SCTP supports the delivery of multiple independent user message
>    streams within a single SCTP association.  This capability, when
>    properly used, can alleviate the so-called head-of-line-blocking
>    problem caused by the strict sequence delivery constraint
> imposed to
>    the user data by TCP.
>
>    This can be particularly useful for applications that need to
>    exchange multiple, logically separate message streams between two
>    endpoints.
>
>    - multi-homing support:
>
>    SCTP provides transparent support for communications between two
>    endpoints of which one or both is multi-homed.
>
>    SCTP provides monitoring of the reachability of the
> addresses on the
>    remote endpoint and in the case of failure can
> transparently failover
>    from the primary address to an alternate address, without
> upper layer
>    intervention.
>
>    This capability can be used to build redundant paths
> between two SCTP
>    endpoints and can be particularly useful for applications that seek
>    transport-level fault tolerance.
>
>    Achieving path redundancy between two SCTP endpoints normally
>    requires that the two endpoints being equipped with multiple
>    interfaces assigned with multiple addresses and that routing is
>    configured appropriately (see Section 3).
>
>    - preservation of message boundaries:
>
>    SCTP preserves application messages boundaries.  This is
> useful when
>    the application data is not a continuous byte stream but comes in
>    logical chunks that the receiver handles separately.
>
>    In contrast, TCP offers a reliable data stream that has no
> indication
>    of what an application may consider logical chunks of the data.
>
>    - unordered reliable message delivery:
>
>    SCTP supports the transportation of user messages that have no
>    application-specified order, yet need guaranteed reliable delivery.
>
>    Applications that need to send un-ordered reliable
> messages or prefer
>    using their own message sequencing and ordering mechanisms may find
>    this SCTP capability useful.
>
> =====================================================
>
> Carter Bullard wrote:
>
> > I am emphatically against any mention of SCTP, unless someone can
> > point out how the SCTP applicability statement, RFC 3257,
> applies to
> > IPFIX.
> >
> > Carter
> >
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com]
> > Sent: Monday, October 06, 2003 11:34 AM
> > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com';
> > 'alex.audu@alcatel.com'
> > Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu';
> > 'ipfix@net.doit.wisc.edu'
> > Subject: RE: [ipfix] STCP as a default transport not
> >
> > Okay...
> > It seems we haven't reached a (firm) conclusion, but we need to get
> > the draft going and this is a big piece of it. Jeff seems
> to propose
> > specifying both (TCP and SCTP). Anyone opposes this? Or should we
> > stick with one protocol mapping? We need to start
> converging on this
> > really soon. Thanks,
> > Reinaldo
> >
> > > -----Original Message-----
> > > From: MEYER,JEFFREY D (HP-Cupertino,ex1)
> [mailto:jeff.meyer2@hp.com]
> > > Sent: Thursday, October 02, 2003 5:05 PM
> > > To: 'carter@qosient.com'; 'alex.audu@alcatel.com'
> > > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH];
> > > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu'
> > > Subject: RE: [ipfix] STCP as a default transport not
> > >
> > >
> > > I'd be interested in knowing what the specific aspects of
> SCTP are
> > > that the IPFIX protocol authors want to use, and how they
> do or do
> > > not conflict in some way with a parallel mapping to TCP.
> > >
> > > Taking the Diameter approach of specifying both TCP and
> SCTP would
> > > allow for the market to decide if ubiquity of availability or the
> > > special capabilities of SCTP are more important.
> > >
> > > -- Jeff
> > >
> > > > -----Original Message-----
> > > > From: Carter Bullard [mailto:carter@qosient.com]
> > > > Sent: Thursday, October 02, 2003 1:00 PM
> > > > To: alex.audu@alcatel.com
> > > > Cc: stbryant@cisco.com; 'Reinaldo Penno';
> > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > > Subject: RE: [ipfix] STCP as a default transport not
> > > >
> > > >
> > > > Hey Alex,
> > > >    Did I say something wrong?  I firmly believe that
> people adopt
> > > > technology when it solves problems.  STCP will get around
> > > as its found
> > > > to be a real solution.  But with regard to STCP and IPFIX,
> > > I read RFC
> > > > 3257, the SCTP Applicability Statement, and I don't see where
> > > > IPFIX fits.  Benefits of SCTP over TCP are:
> > > >
> > > >    multi-streams support
> > > >    multi-homing support
> > > >    preservation of message boundaries
> > > >    unordered reliable message delivery
> > > >
> > > > The first three I don't see as requirements for IPFIX.
> > > > I actually believe the last one to be a problem for
> IPFIX. STCP is
> > > > less efficient that TCP, and so if IPFIX doesn't need any
> > > of these 4
> > > > items, then I don't see the applicability.
> > > >
> > > > Carter
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Alex Audu [mailto:alex.audu@alcatel.com]
> > > > > Sent: Thursday, October 02, 2003 2:51 PM
> > > > > To: carter@qosient.com
> > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno';
> > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > > > Subject: Re: [ipfix] STCP as a default transport not
> > > > >
> > > > >
> > > > > Hello Carter,
> > > > >
> > > > > If it is true that SCTP hasn't been widely deployed, it
> > > is probably
> > > > > because of statements like you have made below. Look, we all
> > > > > know SCTP has a lot of benefits over TCP.  If folks like you
> > > don't drive
> > > > > its deployement
> > > > > by specifying it as default transport, how will it be
> > > > > ubiquitous? It is a self fulfilling prophesy.
> > > > >
> > > > > For IETF protocols that recommend SCTP as defaults, see rfc
> > > > > 3057, rfc 3331 and rfc 3332 just to name a few.
> > > > >
> > > > > Regards,
> > > > > Alex.
> > > > >
> > > > > Carter Bullard wrote:
> > > > >
> > > > > > I believe that SCTP-PR is not deployed widely enough to be
> > > > > > considered a default for any IETF technology. It is
> not on my
> > > > > > Linux RedHat 9.0 distribution, nor my Mac OS-X or
> my Windows
> > > > > > XP system.  I don't see it
> > > available on
> > > > > > any Solaris machine that I have access to.
> > > > > >
> > > > > > What IETF technology is currently using SCTP as a default
> > > > > > transport?
> > > > > >
> > > > > > Carter
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: majordomo listserver
> > > [mailto:majordomo@mil.doit.wisc.edu]
> > > > > > > On Behalf Of Stewart Bryant
> > > > > > > Sent: Thursday, October 02, 2003 12:14 PM
> > > > > > > To: Reinaldo Penno
> > > > > > > Cc: ipfix-chairs@net.doit.wisc.edu;
> ipfix@net.doit.wisc.edu
> > > > > > > Subject: Re: [ipfix] Ipfix Protocol open items
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Reinaldo Penno wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > Have we zeroed in a certain transport protocol? TCP,
> > > > SCTP-PR or
> > > > > > > > something else?
> > > > > > > >
> > > > > > > > I need to write something to explain how
> Netflow runs over
> > > > > > > TCP, but it
> > > > > > > > seems to me somewhat of a lower priority if this is not
> > > > > > > going to be the
> > > > > > > > default protocol. We should focus on explaning how this
> > > > > > > should work on
> > > > > > > > the "choosen one".
> > > > > > >
> > > > > > > I think that perhaps the question should be put another
> > > > > way. There are
> > > > > > > WG members who propose SCTP-PR as the default, and
> > > SCTP-PR has
> > > > > > > advantage because of its better flexibility in coping
> > > > > with congestion.
> > > > > > >
> > > > > > > So the real question is whether there are WG members who
> > > > > think that
> > > > > > > the default should be TCP. If no group comes forward,
> > > > then we have
> > > > > > > our answer. If there is support then we need to perform
> > > > a detailed
> > > > > > > analysis of the relative merits of the two protocols.
> > > > > > >
> > > > > > > Stewart
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 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/
>
>

--------------F01B2FABBE8CDC163C4D83E5-- -- 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 Oct 8 08:58: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 IAA12591 for ; Wed, 8 Oct 2003 08:58:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7DR1-0006rA-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 07:28:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7DQz-0006r0-00; Wed, 08 Oct 2003 07:28:53 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2003 14:27:10 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h98CSl7I023644; Wed, 8 Oct 2003 14:28:47 +0200 (MET DST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-151.cisco.com [64.103.65.151]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA09952; Wed, 8 Oct 2003 13:28:48 +0100 (BST) Message-ID: <3F840300.4040304@cisco.com> Date: Wed, 08 Oct 2003 13:28:48 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6AB@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6AB@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: > Hey Stewart, > The default transport for a standards track protocol should > at least be an RFC. No. The transport needs to be the right transport for the job. If IPFIX has to wait in some intrim state, whilst the transport also gains standards status, then so be it. This waiting does not stop the deployment of IPFIX with some intrim status. Stewart -- 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 Oct 8 09:35: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 JAA14290 for ; Wed, 8 Oct 2003 09:35:41 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7E3o-0000TG-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 08:09:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7E3m-0000T5-00; Wed, 08 Oct 2003 08:08:58 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2003 15:07:16 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h98D8q8R003141; Wed, 8 Oct 2003 15:08:52 +0200 (MET DST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-151.cisco.com [64.103.65.151]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA11332; Wed, 8 Oct 2003 14:08:56 +0100 (BST) Message-ID: <3F840C68.5010406@cisco.com> Date: Wed, 08 Oct 2003 14:08:56 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: alex.audu@alcatel.com, "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6AC@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6AC@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: > Hey Stewart, > >>We should spend some time thinking about the behavior we want in the >>exporter when the network is congested, perhaps due to an >>attack. PR-SCTP >>gives us the option of running a best effort data collection >>to gleen what >>is going on, when a TCP based exporter would otherwise collapse due to >>backlog on the exporter. > > > This is a real engineering issue to talk about. Issues in producer/consumer > dynamics are real problems for IPFIX, especially when the flow record > source is generating 1M records per second, which my probes are capable > of doing. In my experience, the reader/collector not keeping up is > never a network congestion problem, it is almost always a reader/collector > resource problem, slow disks, not enough memory, competing processes, > whatever. The critical issue is which side of TCP does it occur. If TCP has accepted the data then the collector application had better do some intelligent. My concern is with the exporter or probe having a backlog for any reason. > It happens in SMP multi-threaded environments where the flow > generator and its collector are on the same machine, it happens when the > consumer is on the other end of a dedicated ATM, hyper-channel or > infiniband links. Its not an issue of reliable vs unreliable transport, > its more an issue of what does the probe do when it finds it has 1M records > that aren't being consumed, and another 1M records are coming very soon. On this point we absolutely agree. > Does it store them, drop them with an indication? I think that we have to assume that it does not have the storage. From the PR_SCTP draft: One example of partially reliable service is specified in this document, namely a "timed reliability" service. This service allows the service user to indicate a limit on the duration of time that the sender should try to transmit/retransmit the message (this is a natural extension of the "lifetime" parameter already in the base protocol). This seems to have the right properties > Does it proactively seek > an alternate association, the same association or does it wait for the > multiple readers to come back when they are ready. Are there going to be > multiple readers? > > Usually the monitor is being attacked, or its generating twice the load > because something else is being attacked in the network. No congestion, > just a lot of records. Anything that means that the exporter has a bunch of data wedged in its output queues waiting for an ACK looks like congestion to the exporter. > I don't think PR-SCTP touches these problems. > > If you want the record generator to have a proactive role in > failover and recover, maybe RTP/RTCP would be a better choice. > Explicit feedback control channel provides enough to decide if > it should fail over. As I recall RTP requires the application to define its own approach to congestion, and we do have to have a congestion strategy. It would be better to use a congestion aware transport that has a build-in strategy to bail-out if there is a problem, and PR-SCTP has just those properties. Stewart > > Carter > > >>Stewart >> >> >> >> >>-- >>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 Oct 8 09:38:05 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 JAA14404 for ; Wed, 8 Oct 2003 09:38:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7E7Y-0000cX-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 08:12:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7E7X-0000cP-00; Wed, 08 Oct 2003 08:12:51 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2003 15:11:09 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h98DCj90004195; Wed, 8 Oct 2003 15:12:45 +0200 (MET DST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-151.cisco.com [64.103.65.151]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA11525; Wed, 8 Oct 2003 14:12:49 +0100 (BST) Message-ID: <3F840D51.5020508@cisco.com> Date: Wed, 08 Oct 2003 14:12:49 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <0A11633F61BD9F40B43ABCC694004F930218F28A@zsc3c026.us.nortel.com> <3F82EEEF.FEFC7942@alcatel.com> In-Reply-To: <3F82EEEF.FEFC7942@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit From the discussions on this thread, the selection of the default transport clearly needs to be on the agenda for Minneapolis. The current agenda does not have IPFIX. Have the chairs requested a meeting slot? Stewart -- 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 Oct 8 10:47: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 KAA18608 for ; Wed, 8 Oct 2003 10:47:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7FNo-0003LY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 09:33:44 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7FNn-0003LN-00 for ipfix@net.doit.wisc.edu; Wed, 08 Oct 2003 09:33:43 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h98EXfev091558 for ; Wed, 8 Oct 2003 16:33:41 +0200 (CEST) Received: from ccrle.nec.de (molina.office [10.1.1.126]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DC3ACCDBA5 for ; Wed, 8 Oct 2003 16:01:26 +0200 (CEST) Message-ID: <3F842044.1090001@ccrle.nec.de> Date: Wed, 08 Oct 2003 16:33:40 +0200 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ipfix@net.doit.wisc.edu'" Subject: [ipfix] bytes and packet counters, tstamp of last report Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, the IPFIX info model states (sec. 6.10) that The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. (There's the same statement for byte counts in 6.11). To me, this doesn't clarify wheter it is both...and (2 counters) or either .... or (1 counter). Moreover, there is currently no room for a field containing the timestamp of the last report of a flow. I think that keeping this timestamp is helpful for many applications and the info model should support it. Regards, Maurizio -- 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 Oct 8 10:53:24 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 KAA19003 for ; Wed, 8 Oct 2003 10:53:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7FZX-0003ij-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 09:45:52 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7FZW-0003ic-00; Wed, 08 Oct 2003 09:45:50 -0500 Date: Wed, 8 Oct 2003 09:45:50 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Cc: Stewart Bryant Subject: IPFIX meeting slot has been requested for the 58th meeting (was "Re: [ipfix] STCP as a default transport not") Message-ID: <20031008094550.B8889@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <0A11633F61BD9F40B43ABCC694004F930218F28A@zsc3c026.us.nortel.com> <3F82EEEF.FEFC7942@alcatel.com> <3F840D51.5020508@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3F840D51.5020508@cisco.com>; from stbryant@cisco.com on Wed, Oct 08, 2003 at 02:12:49PM +0100 X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-W-NODETACH, operation requires DETACH privilege X-Shakespearean-Insult: Thou roguish tickle-brained haggard Precedence: bulk Sender: majordomo listserver On Wed, Oct 08, 2003 at 02:12:49PM +0100, Stewart Bryant wrote: > From the discussions on this thread, the selection of the > default transport clearly needs to be on the agenda for > Minneapolis. noted ;^) > The current agenda does not have IPFIX. Have the chairs > requested a meeting slot? Yes, and it has AD approval. We're just waiting for it to appear on the agenda. Dave -- "This is only temporary, unless it works." - Red Green -- 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 Oct 8 11:21: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 LAA22036 for ; Wed, 8 Oct 2003 11:21:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7Fw5-0004ag-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 10:09:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7Fw4-0004aa-00 for ipfix@net.doit.wisc.edu; Wed, 08 Oct 2003 10:09:08 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2003 17:07:27 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h98F92Vo005218; Wed, 8 Oct 2003 17:09:03 +0200 (MET DST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-151.cisco.com [64.103.65.151]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA16558; Wed, 8 Oct 2003 16:09:06 +0100 (BST) Message-ID: <3F842892.8070007@cisco.com> Date: Wed, 08 Oct 2003 16:09:06 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maurizio Molina CC: "'ipfix@net.doit.wisc.edu'" Subject: Re: [ipfix] bytes and packet counters, tstamp of last report References: <3F842044.1090001@ccrle.nec.de> In-Reply-To: <3F842044.1090001@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Maurizio Molina wrote: > Hi, > the IPFIX info model states (sec. 6.10) that > > The packet count can be a running counter and is the count from the > beginning of the flow establishment. > > The packet count can be a delta counter and is the count since the > last report for this flow. > I would prefer that we only supported running counters because: a) Supporting two types is more scope for non-interworking, and you can always convert from one to the other at the collector. b) Running counters also work over an unreliable transport whereas delta counters mandate the use of a reliable transport. c) Running counters are most likely what the hardware is keeping anyway, therefore delta counters are more work and more storage at the exporter. If we decide that we need both then we have to represent them as two different information elements because the info model does not support sub-typing. Stewart > (There's the same statement for byte counts in 6.11). > > To me, this doesn't clarify wheter it is both...and (2 counters) or > either .... or (1 counter). > > Moreover, there is currently no room for a field containing the > timestamp of the last report of a flow. I think that keeping this > timestamp is helpful for many applications and the info model should > support it. > Regards, > Maurizio > > > > -- > 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 Oct 8 12:23:19 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 MAA25959 for ; Wed, 8 Oct 2003 12:23:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7Gx2-0006sw-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 11:14:12 -0500 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7Gx1-0006sr-00 for ipfix@net.doit.wisc.edu; Wed, 08 Oct 2003 11:14:11 -0500 Received: from Givoly ([192.168.0.2]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h98GNMC26565; Wed, 8 Oct 2003 09:23:23 -0700 From: "Tal Givoly" To: , "Maurizio Molina" Cc: Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Date: Wed, 8 Oct 2003 09:13:56 -0700 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.2800.1165 In-Reply-To: <3F842892.8070007@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Both counters have value (running and delta). Obviously, they must be kept discrete from an information model perspective as they represent different information. Devices sometimes maintain one, sometimes the other, and sometimes both. Just as an example, as far as I recall, NetFlow v5-8 doesn't maintain running counters (counter to your suggestion) EVEN THOUGH it operates over a non-reliable and non-congestion-aware transport. Our probe product emits both for various different purposes. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Stewart Bryant Sent: Wednesday, October 08, 2003 8:09 AM To: Maurizio Molina Cc: 'ipfix@net.doit.wisc.edu' Subject: Re: [ipfix] bytes and packet counters, tstamp of last report Maurizio Molina wrote: > Hi, > the IPFIX info model states (sec. 6.10) that > > The packet count can be a running counter and is the count from the > beginning of the flow establishment. > > The packet count can be a delta counter and is the count since the > last report for this flow. > I would prefer that we only supported running counters because: a) Supporting two types is more scope for non-interworking, and you can always convert from one to the other at the collector. b) Running counters also work over an unreliable transport whereas delta counters mandate the use of a reliable transport. c) Running counters are most likely what the hardware is keeping anyway, therefore delta counters are more work and more storage at the exporter. If we decide that we need both then we have to represent them as two different information elements because the info model does not support sub-typing. Stewart > (There's the same statement for byte counts in 6.11). > > To me, this doesn't clarify wheter it is both...and (2 counters) or > either .... or (1 counter). > > Moreover, there is currently no room for a field containing the > timestamp of the last report of a flow. I think that keeping this > timestamp is helpful for many applications and the info model should > support it. > Regards, > Maurizio > > > > -- > 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 Oct 8 13:35: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 NAA28661 for ; Wed, 8 Oct 2003 13:35:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7I1t-0001Va-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 12:23:17 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7I1r-0001VQ-00; Wed, 08 Oct 2003 12:23:15 -0500 Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel11.hp.com (Postfix) with ESMTP id E81271C01CBE; Wed, 8 Oct 2003 10:23:14 -0700 (PDT) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id D8D781004BA9; Wed, 8 Oct 2003 10:23:14 -0700 (PDT) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <43X0WDB5>; Wed, 8 Oct 2003 10:23:14 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960365@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'stbryant@cisco.com'" , carter@qosient.com Cc: alex.audu@alcatel.com, "'Reinaldo Penno'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Wed, 8 Oct 2003 10:23:03 -0700 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 guess there is a concern of whether we are approaching this from the "optimize for the usual case" or "optimize for the worst case". The former is usually preferred. The general concern seems to be appropriate "capacity" on the collector side so that little to no back pressure occurs on the sender. UDP's fire and forget model makes this trivial, but its lack of congestion aware behavior is apparently a no no. From the discussion it sounds like PR_SCTP has similar properties on overflow, where things just get tossed, like the behavior of the input UDP socket buffer when the collector is falling behind. However, in a mode where the collector is sufficiently endowed to consume over TCP, which would hopefully be the majority of situations, taking advantage of TCP's ubiquity and reliability properties makes a lot of sense to me. I'm still dubious of whether disallowing UDP (which happens to be the only current concrete binding of NFv9) in favor of SCTP-PR is really the best approach. Personally I'd recommend: o bindings over TCP for reliable communication while accomodating for some failover mechanism if the collector becomes congested or disabled; o bindings of UDP for best effort (i.e. no exporter back pressure) in configurations where exporter and collector are coresident and congestion aware behavior is not a concern; o binding of PR_SCTP where congestion aware behavior and best effort are desired. Regards, Jeff Meyer > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, October 08, 2003 6:09 AM > To: carter@qosient.com > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > > > Carter Bullard wrote: > > > Hey Stewart, > > > >>We should spend some time thinking about the behavior we want in the > >>exporter when the network is congested, perhaps due to an > >>attack. PR-SCTP > >>gives us the option of running a best effort data collection > >>to gleen what > >>is going on, when a TCP based exporter would otherwise > collapse due to > >>backlog on the exporter. > > > > > > This is a real engineering issue to talk about. Issues in > producer/consumer > > dynamics are real problems for IPFIX, especially when the > flow record > > source is generating 1M records per second, which my probes > are capable > > of doing. In my experience, the reader/collector not keeping up is > > never a network congestion problem, it is almost always a > reader/collector > > resource problem, slow disks, not enough memory, competing > processes, > > whatever. > > The critical issue is which side of TCP does it occur. If TCP > has accepted > the data then the collector application had better do some > intelligent. > My concern is with the exporter or probe having a backlog for > any reason. > > > It happens in SMP multi-threaded environments where the flow > > generator and its collector are on the same machine, it > happens when the > > consumer is on the other end of a dedicated ATM, hyper-channel or > > infiniband links. Its not an issue of reliable vs > unreliable transport, > > its more an issue of what does the probe do when it finds > it has 1M records > > that aren't being consumed, and another 1M records are > coming very soon. > > On this point we absolutely agree. > > > Does it store them, drop them with an indication? > > I think that we have to assume that it does not have the storage. > > From the PR_SCTP draft: > > One example of partially reliable service is specified in this > document, namely a "timed reliability" service. This > service allows > the service user to indicate a limit on the duration of > time that the > sender should try to transmit/retransmit the message (this is a > natural extension of the "lifetime" parameter already in the base > protocol). > > This seems to have the right properties > > > Does it proactively seek > > an alternate association, the same association or does it > wait for the > > multiple readers to come back when they are ready. Are > there going to be > > multiple readers? > > > > Usually the monitor is being attacked, or its generating > twice the load > > because something else is being attacked in the network. > No congestion, > > just a lot of records. > > Anything that means that the exporter has a bunch of data wedged in > its output queues waiting for an ACK looks like congestion to > the exporter. > > > I don't think PR-SCTP touches these problems. > > > > If you want the record generator to have a proactive role in > > failover and recover, maybe RTP/RTCP would be a better choice. > > Explicit feedback control channel provides enough to decide if > > it should fail over. > > As I recall RTP requires the application to define its own approach to > congestion, and we do have to have a congestion strategy. It would > be better to use a congestion aware transport that has a build-in > strategy to bail-out if there is a problem, and PR-SCTP has just those > properties. > > Stewart > > > > > > Carter > > > > > >>Stewart > >> > >> > >> > >> > >>-- > >>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 Oct 8 15:55:51 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 PAA06528 for ; Wed, 8 Oct 2003 15:55:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7KFu-0006B4-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 14:45:54 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7KFt-0006Ay-00 for ipfix@net.doit.wisc.edu; Wed, 08 Oct 2003 14:45:53 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 6AD9C1C01ACA; Wed, 8 Oct 2003 15:45:52 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 63B831C000B4; Wed, 8 Oct 2003 15:45:52 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id <42JR51LA>; Wed, 8 Oct 2003 15:45:52 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960367@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Tal Givoly'" , stbryant@cisco.com, Maurizio Molina Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Date: Wed, 8 Oct 2003 15:45:44 -0400 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, In some use cases counters may have desirable properties as Tal has described. But like many things, counters also have their limitations and downsides. In the basic Flow Export scenario which is exemplified by existing Netflow implementations, a flow record indicates a summary of observed behavior. Consider two flow events: sourceAddress=1.2.3.4 destinationAddress=1.2.3.5 packetCount=1000 byteCount=100000 flowCreationTime=2003-10-08T10:00:00Z flowEndTime=2003-10-08T10:00:05Z TcpControlBits=0x13 sourceAddress=1.2.3.4 destinationAddress=1.2.3.6 packetCount=1000 byteCount=200000 flowCreationTime=2003-10-08T10:00:02Z flowEndTime=2003-10-08T10:00:06Z TcpControlBits=0x13 Each of these completely describes a conversation, as it includes both the fin and syn TCP flags. Start time, end time and absolute counts. Given the large percentage of flows which when exported, describe a complete conversation, I don't see the advantage of using counters. I'm not even sure how one would propose the use of counters as an alternative. Would you require two records be sent for each flow (one with byteCounter and packetCounter=0 and another with the final value?) Since most flows can be represented by a single record, doubling the number of records to accomodate counters seems a bit odd. Counters also require the holding of state, which produces a much greater burden on the collector. Since the necessary state must be held by the observer, why double the workload? I.e. a single counter is pretty useless. I need to delta it against a previously observed matching counter to arrive at a quantity. For information models such as PSAMP, there may be a compelling use case. So I imagine adding an explicit annotation in the information model for counters would be worthwile. However, I think that counter behavior such as when it is zeroed out and its rollover behavior need to be appropriately documented and thought out. (e.g. on restart, the counters presumably reset to zero, so here is additional state a collector may need to monitor to reconcile (if possible) existing observations). For IPFIX's base information model, I would strongly discourage "fixing" something which isn't broken. Regards, Jeff Meyer _________________________________________________________________ Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Tal Givoly > Sent: Wednesday, October 08, 2003 9:14 AM > To: stbryant@cisco.com; Maurizio Molina > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] bytes and packet counters, tstamp of last report > > > Both counters have value (running and delta). Obviously, they > must be kept > discrete from an information model perspective as they > represent different > information. Devices sometimes maintain one, sometimes the other, and > sometimes both. Just as an example, as far as I recall, > NetFlow v5-8 doesn't > maintain running counters (counter to your suggestion) EVEN THOUGH it > operates over a non-reliable and non-congestion-aware > transport. Our probe > product emits both for various different purposes. > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Stewart Bryant > Sent: Wednesday, October 08, 2003 8:09 AM > To: Maurizio Molina > Cc: 'ipfix@net.doit.wisc.edu' > Subject: Re: [ipfix] bytes and packet counters, tstamp of last report > > > > > Maurizio Molina wrote: > > > Hi, > > the IPFIX info model states (sec. 6.10) that > > > > The packet count can be a running counter and is the > count from the > > beginning of the flow establishment. > > > > The packet count can be a delta counter and is the count since the > > last report for this flow. > > > > I would prefer that we only supported running counters because: > > a) Supporting two types is more scope for non-interworking, and > you can always convert from one to the other at the collector. > > b) Running counters also work over an unreliable transport > whereas delta counters mandate the use of a reliable transport. > > c) Running counters are most likely what the hardware is keeping > anyway, therefore delta counters are more work and more storage > at the exporter. > > If we decide that we need both then we have to represent them > as two different information elements because the info model does > not support sub-typing. > > Stewart > > > (There's the same statement for byte counts in 6.11). > > > > To me, this doesn't clarify wheter it is both...and (2 counters) or > > either .... or (1 counter). > > > > Moreover, there is currently no room for a field containing the > > timestamp of the last report of a flow. I think that keeping this > > timestamp is helpful for many applications and the info model should > > support it. > > Regards, > > Maurizio > > > > > > > > -- > > 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 Oct 8 17:07:11 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 RAA09357 for ; Wed, 8 Oct 2003 17:07:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7LLp-0000mK-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 15:56:05 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7LLn-0000mC-00; Wed, 08 Oct 2003 15:56:03 -0500 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id DD6571C01321; Wed, 8 Oct 2003 16:56:02 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id D0B981C000A6; Wed, 8 Oct 2003 16:56:02 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <433YFRWY>; Wed, 8 Oct 2003 16:56:02 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296036F@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Reinaldo Penno'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'carter@qosient.com'" , "'alex.audu@alcatel.com'" Cc: "'stbryant@cisco.com'" , "'ipfix-chairs@net.doit.wisc.edu'" , "'ipfix@net.doit.wisc.edu'" Subject: RE: [ipfix] STCP as a default transport not Date: Wed, 8 Oct 2003 16:55:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38DDE.2D42F5C8" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38DDE.2D42F5C8 Content-Type: text/plain; charset="iso-8859-1" Hi, Does this mean UDP gets taken out? Or will there be 3 bindings for different environmental requirements? [That would be my suggestion] o bindings over TCP for reliable communication while accomodating for some failover mechanism if the collector becomes congested or disabled; o bindings of UDP for best effort (i.e. no exporter back pressure) in configurations where exporter and collector are colocated and congestion aware behavior is not a concern; o binding of PR_SCTP where congestion aware behavior and best effort are desired. -- Jeff -----Original Message----- From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] Sent: Monday, October 06, 2003 9:34 AM To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; 'alex.audu@alcatel.com' Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' Subject: RE: [ipfix] STCP as a default transport not Okay... It seems we haven't reached a (firm) conclusion, but we need to get the draft going and this is a big piece of it. Jeff seems to propose specifying both (TCP and SCTP). Anyone opposes this? Or should we stick with one protocol mapping? We need to start converging on this really soon. Thanks, Reinaldo > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [ mailto:jeff.meyer2@hp.com ] > Sent: Thursday, October 02, 2003 5:05 PM > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > Subject: RE: [ipfix] STCP as a default transport not > > > I'd be interested in knowing what the specific aspects of > SCTP are that the IPFIX protocol authors want to use, and how > they do or do not conflict in some way with a parallel mapping to TCP. > > Taking the Diameter approach of specifying both TCP and SCTP > would allow for the market to decide if ubiquity of > availability or the special capabilities of SCTP are more important. > > -- Jeff > > > -----Original Message----- > > From: Carter Bullard [ mailto:carter@qosient.com ] > > Sent: Thursday, October 02, 2003 1:00 PM > > To: alex.audu@alcatel.com > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Hey Alex, > > Did I say something wrong? I firmly believe that people adopt > > technology when it solves problems. STCP will get around > as its found > > to be a real solution. But with regard to STCP and IPFIX, > I read RFC > > 3257, the SCTP Applicability Statement, and I don't see where IPFIX > > fits. Benefits of SCTP over TCP are: > > > > multi-streams support > > multi-homing support > > preservation of message boundaries > > unordered reliable message delivery > > > > The first three I don't see as requirements for IPFIX. > > I actually believe the last one to be a problem for IPFIX. STCP is > > less efficient that TCP, and so if IPFIX doesn't need any > of these 4 > > items, then I don't see the applicability. > > > > Carter > > > > > > > -----Original Message----- > > > From: Alex Audu [ mailto:alex.audu@alcatel.com ] > > > Sent: Thursday, October 02, 2003 2:51 PM > > > To: carter@qosient.com > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Hello Carter, > > > > > > If it is true that SCTP hasn't been widely deployed, it > is probably > > > because of statements like you have made below. Look, we all know > > > SCTP has a lot of benefits over TCP. If folks like you > don't drive > > > its deployement > > > by specifying it as default transport, how will it be > > > ubiquitous? It is a > > > self fulfilling prophesy. > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, > > > rfc 3331 and rfc 3332 just to name a few. > > > > > > Regards, > > > Alex. > > > > > > Carter Bullard wrote: > > > > > > > I believe that SCTP-PR is not deployed widely enough > > > > to be considered a default for any IETF technology. > > > > It is not on my Linux RedHat 9.0 distribution, nor > > > > my Mac OS-X or my Windows XP system. I don't see it > available on > > > > any Solaris machine that I have access to. > > > > > > > > What IETF technology is currently using SCTP as a > > > > default transport? > > > > > > > > Carter > > > > > > > > > -----Original Message----- > > > > > From: majordomo listserver > [ mailto:majordomo@mil.doit.wisc.edu ] > > > > > On Behalf Of Stewart Bryant > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > To: Reinaldo Penno > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > SCTP-PR or > > > > > > something else? > > > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > > TCP, but it > > > > > > seems to me somewhat of a lower priority if this is not > > > > > going to be the > > > > > > default protocol. We should focus on explaning how this > > > > > should work on > > > > > > the "choosen one". > > > > > > > > > > I think that perhaps the question should be put another > > > way. There are > > > > > WG members who propose SCTP-PR as the default, and > SCTP-PR has > > > > > advantage because of its better flexibility in coping > > > with congestion. > > > > > > > > > > So the real question is whether there are WG members who > > > think that > > > > > the default should be TCP. If no group comes forward, > > then we have > > > > > our answer. If there is support then we need to perform > > a detailed > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > Stewart > > > > > > > > > > > > > > > -- > > > > > 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/ > > > ------_=_NextPart_001_01C38DDE.2D42F5C8 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix] STCP as a default transport not
Hi,
 
  Does this mean UDP gets taken out?  Or will there be 3 bindings for different environmental requirements? [That would be my suggestion]
 

o bindings over TCP for reliable communication while accomodating for  some failover mechanism if the collector becomes congested or disabled;

o bindings of UDP for best effort (i.e. no exporter back pressure) in configurations where exporter and collector are colocated and congestion aware behavior is not a concern;

o binding of PR_SCTP where congestion aware behavior and best effort are desired.

 
-- Jeff
-----Original Message-----
From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com]
Sent: Monday, October 06, 2003 9:34 AM
To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; 'alex.audu@alcatel.com'
Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu'
Subject: RE: [ipfix] STCP as a default transport not

Okay...

It seems we haven't reached a (firm) conclusion, but we need to get the draft going and this is a big piece of it. Jeff seems to propose specifying both (TCP and SCTP). Anyone opposes this? Or should we stick with one protocol mapping?

We need to start converging on this really soon.

Thanks,

Reinaldo



> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
> Sent: Thursday, October 02, 2003 5:05 PM
> To: 'carter@qosient.com'; 'alex.audu@alcatel.com'
> Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH];
> 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu'
> Subject: RE: [ipfix] STCP as a default transport not
>
>
> I'd be interested in knowing what the specific aspects of
> SCTP are that the IPFIX protocol authors want to use, and how
> they do or do not conflict in some way with a parallel mapping to TCP.
>
> Taking the Diameter approach of specifying both TCP and SCTP
> would allow for the market to decide if ubiquity of
> availability or the special capabilities of SCTP are more important.
>
> -- Jeff
>
> > -----Original Message-----
> > From: Carter Bullard [mailto:carter@qosient.com]
> > Sent: Thursday, October 02, 2003 1:00 PM
> > To: alex.audu@alcatel.com
> > Cc: stbryant@cisco.com; 'Reinaldo Penno';
> > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] STCP as a default transport not
> >
> >
> > Hey Alex,
> >    Did I say something wrong?  I firmly believe that people adopt
> > technology when it solves problems.  STCP will get around
> as its found
> > to be a real solution.  But with regard to STCP and IPFIX,
> I read RFC
> > 3257, the SCTP Applicability Statement, and I don't see where IPFIX
> > fits.  Benefits of SCTP over TCP are:
> >
> >    multi-streams support
> >    multi-homing support
> >    preservation of message boundaries
> >    unordered reliable message delivery
> >
> > The first three I don't see as requirements for IPFIX.
> > I actually believe the last one to be a problem for IPFIX. STCP is
> > less efficient that TCP, and so if IPFIX doesn't need any
> of these 4
> > items, then I don't see the applicability.
> >
> > Carter
> >
> >
> > > -----Original Message-----
> > > From: Alex Audu [mailto:alex.audu@alcatel.com]
> > > Sent: Thursday, October 02, 2003 2:51 PM
> > > To: carter@qosient.com
> > > Cc: stbryant@cisco.com; 'Reinaldo Penno';
> > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > Subject: Re: [ipfix] STCP as a default transport not
> > >
> > >
> > > Hello Carter,
> > >
> > > If it is true that SCTP hasn't been widely deployed, it
> is probably
> > > because of statements like you have made below. Look, we all know
> > > SCTP has a lot of benefits over TCP.  If folks like you
> don't drive
> > > its deployement
> > > by specifying it as default transport, how will it be
> > > ubiquitous? It is a
> > > self fulfilling prophesy.
> > >
> > > For IETF protocols that recommend SCTP as defaults, see rfc 3057,
> > > rfc 3331 and rfc 3332 just to name a few.
> > >
> > > Regards,
> > > Alex.
> > >
> > > Carter Bullard wrote:
> > >
> > > > I believe that SCTP-PR is not deployed widely enough
> > > > to be considered a default for any IETF technology.
> > > > It is not on my Linux RedHat 9.0 distribution, nor
> > > > my Mac OS-X or my Windows XP system.  I don't see it
> available on
> > > > any Solaris machine that I have access to.
> > > >
> > > > What IETF technology is currently using SCTP as a
> > > > default transport?
> > > >
> > > > Carter
> > > >
> > > > > -----Original Message-----
> > > > > From: majordomo listserver
> [mailto:majordomo@mil.doit.wisc.edu]
> > > > > On Behalf Of Stewart Bryant
> > > > > Sent: Thursday, October 02, 2003 12:14 PM
> > > > > To: Reinaldo Penno
> > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > > > Subject: Re: [ipfix] Ipfix Protocol open items
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Reinaldo Penno wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Have we zeroed in a certain transport protocol? TCP,
> > SCTP-PR or
> > > > > > something else?
> > > > > >
> > > > > > I need to write something to explain how Netflow runs over
> > > > > TCP, but it
> > > > > > seems to me somewhat of a lower priority if this is not
> > > > > going to be the
> > > > > > default protocol. We should focus on explaning how this
> > > > > should work on
> > > > > > the "choosen one".
> > > > >
> > > > > I think that perhaps the question should be put another
> > > way. There are
> > > > > WG members who propose SCTP-PR as the default, and
> SCTP-PR has
> > > > > advantage because of its better flexibility in coping
> > > with congestion.
> > > > >
> > > > > So the real question is whether there are WG members who
> > > think that
> > > > > the default should be TCP. If no group comes forward,
> > then we have
> > > > > our answer. If there is support then we need to perform
> > a detailed
> > > > > analysis of the relative merits of the two protocols.
> > > > >
> > > > > Stewart
> > > > >
> > > > >
> > > > > --
> > > > > 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/
> >
>

------_=_NextPart_001_01C38DDE.2D42F5C8-- -- 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 Oct 8 17:22:28 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 RAA09956 for ; Wed, 8 Oct 2003 17:22:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7Lcp-0001N0-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Oct 2003 16:13:39 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7Lcn-0001Mt-00; Wed, 08 Oct 2003 16:13:37 -0500 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98LBkX20788; Wed, 8 Oct 2003 14:11:46 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 14:11:47 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F930218F2A5@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'carter@qosient.com'" , "'alex.audu@alcatel.com'" Cc: "'stbryant@cisco.com'" , "'ipfix-chairs@net.doit.wisc.edu'" , "'ipfix@net.doit.wisc.edu'" Subject: RE: [ipfix] STCP as a default transport not Date: Wed, 8 Oct 2003 14:11:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38DE0.C769096A" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38DE0.C769096A Content-Type: text/plain; charset="ISO-8859-1" The UDP binding was dropped a long time ago due to the fact that the selected protocol needed to be congestion friendly. That's why SCTP-PR came to be. It can be unreliable, yet congestion aware. -----Original Message----- From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] Sent: Wednesday, October 08, 2003 4:56 PM To: Penno, Reinaldo [BL60:SF30:EXCH]; MEYER,JEFFREY D (HP-Cupertino,ex1); 'carter@qosient.com'; 'alex.audu@alcatel.com' Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' Subject: RE: [ipfix] STCP as a default transport not Hi, Does this mean UDP gets taken out? Or will there be 3 bindings for different environmental requirements? [That would be my suggestion] o bindings over TCP for reliable communication while accomodating for some failover mechanism if the collector becomes congested or disabled; o bindings of UDP for best effort (i.e. no exporter back pressure) in configurations where exporter and collector are colocated and congestion aware behavior is not a concern; o binding of PR_SCTP where congestion aware behavior and best effort are desired. -- Jeff -----Original Message----- From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] Sent: Monday, October 06, 2003 9:34 AM To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; 'alex.audu@alcatel.com' Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' Subject: RE: [ipfix] STCP as a default transport not Okay... It seems we haven't reached a (firm) conclusion, but we need to get the draft going and this is a big piece of it. Jeff seems to propose specifying both (TCP and SCTP). Anyone opposes this? Or should we stick with one protocol mapping? We need to start converging on this really soon. Thanks, Reinaldo > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com ] > Sent: Thursday, October 02, 2003 5:05 PM > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > Subject: RE: [ipfix] STCP as a default transport not > > > I'd be interested in knowing what the specific aspects of > SCTP are that the IPFIX protocol authors want to use, and how > they do or do not conflict in some way with a parallel mapping to TCP. > > Taking the Diameter approach of specifying both TCP and SCTP > would allow for the market to decide if ubiquity of > availability or the special capabilities of SCTP are more important. > > -- Jeff > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com ] > > Sent: Thursday, October 02, 2003 1:00 PM > > To: alex.audu@alcatel.com > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Hey Alex, > > Did I say something wrong? I firmly believe that people adopt > > technology when it solves problems. STCP will get around > as its found > > to be a real solution. But with regard to STCP and IPFIX, > I read RFC > > 3257, the SCTP Applicability Statement, and I don't see where IPFIX > > fits. Benefits of SCTP over TCP are: > > > > multi-streams support > > multi-homing support > > preservation of message boundaries > > unordered reliable message delivery > > > > The first three I don't see as requirements for IPFIX. > > I actually believe the last one to be a problem for IPFIX. STCP is > > less efficient that TCP, and so if IPFIX doesn't need any > of these 4 > > items, then I don't see the applicability. > > > > Carter > > > > > > > -----Original Message----- > > > From: Alex Audu [mailto:alex.audu@alcatel.com ] > > > Sent: Thursday, October 02, 2003 2:51 PM > > > To: carter@qosient.com > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Hello Carter, > > > > > > If it is true that SCTP hasn't been widely deployed, it > is probably > > > because of statements like you have made below. Look, we all know > > > SCTP has a lot of benefits over TCP. If folks like you > don't drive > > > its deployement > > > by specifying it as default transport, how will it be > > > ubiquitous? It is a > > > self fulfilling prophesy. > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, > > > rfc 3331 and rfc 3332 just to name a few. > > > > > > Regards, > > > Alex. > > > > > > Carter Bullard wrote: > > > > > > > I believe that SCTP-PR is not deployed widely enough > > > > to be considered a default for any IETF technology. > > > > It is not on my Linux RedHat 9.0 distribution, nor > > > > my Mac OS-X or my Windows XP system. I don't see it > available on > > > > any Solaris machine that I have access to. > > > > > > > > What IETF technology is currently using SCTP as a > > > > default transport? > > > > > > > > Carter > > > > > > > > > -----Original Message----- > > > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu ] > > > > > On Behalf Of Stewart Bryant > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > To: Reinaldo Penno > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > SCTP-PR or > > > > > > something else? > > > > > > > > > > > > I need to write something to explain how Netflow runs over > > > > > TCP, but it > > > > > > seems to me somewhat of a lower priority if this is not > > > > > going to be the > > > > > > default protocol. We should focus on explaning how this > > > > > should work on > > > > > > the "choosen one". > > > > > > > > > > I think that perhaps the question should be put another > > > way. There are > > > > > WG members who propose SCTP-PR as the default, and > SCTP-PR has > > > > > advantage because of its better flexibility in coping > > > with congestion. > > > > > > > > > > So the real question is whether there are WG members who > > > think that > > > > > the default should be TCP. If no group comes forward, > > then we have > > > > > our answer. If there is support then we need to perform > > a detailed > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > Stewart > > > > > > > > > > > > > > > -- > > > > > 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/ > > > ------_=_NextPart_001_01C38DE0.C769096A Content-Type: text/html; charset="ISO-8859-1" Message
The UDP binding was dropped a long time ago due to the fact that the selected protocol needed to be congestion friendly. 
 
That's why SCTP-PR came to be. It can be unreliable, yet congestion aware.
-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
Sent: Wednesday, October 08, 2003 4:56 PM
To: Penno, Reinaldo [BL60:SF30:EXCH]; MEYER,JEFFREY D (HP-Cupertino,ex1); 'carter@qosient.com'; 'alex.audu@alcatel.com'
Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu'
Subject: RE: [ipfix] STCP as a default transport not

Hi,
 
  Does this mean UDP gets taken out?  Or will there be 3 bindings for different environmental requirements? [That would be my suggestion]
 

o bindings over TCP for reliable communication while accomodating for  some failover mechanism if the collector becomes congested or disabled;

o bindings of UDP for best effort (i.e. no exporter back pressure) in configurations where exporter and collector are colocated and congestion aware behavior is not a concern;

o binding of PR_SCTP where congestion aware behavior and best effort are desired.

 
-- Jeff
-----Original Message-----
From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com]
Sent: Monday, October 06, 2003 9:34 AM
To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; 'alex.audu@alcatel.com'
Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu'
Subject: RE: [ipfix] STCP as a default transport not

Okay...

It seems we haven't reached a (firm) conclusion, but we need to get the draft going and this is a big piece of it. Jeff seems to propose specifying both (TCP and SCTP). Anyone opposes this? Or should we stick with one protocol mapping?

We need to start converging on this really soon.

Thanks,

Reinaldo



> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
> Sent: Thursday, October 02, 2003 5:05 PM
> To: 'carter@qosient.com'; 'alex.audu@alcatel.com'
> Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH];
> 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu'
> Subject: RE: [ipfix] STCP as a default transport not
>
>
> I'd be interested in knowing what the specific aspects of
> SCTP are that the IPFIX protocol authors want to use, and how
> they do or do not conflict in some way with a parallel mapping to TCP.
>
> Taking the Diameter approach of specifying both TCP and SCTP
> would allow for the market to decide if ubiquity of
> availability or the special capabilities of SCTP are more important.
>
> -- Jeff
>
> > -----Original Message-----
> > From: Carter Bullard [mailto:carter@qosient.com]
> > Sent: Thursday, October 02, 2003 1:00 PM
> > To: alex.audu@alcatel.com
> > Cc: stbryant@cisco.com; 'Reinaldo Penno';
> > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] STCP as a default transport not
> >
> >
> > Hey Alex,
> >    Did I say something wrong?  I firmly believe that people adopt
> > technology when it solves problems.  STCP will get around
> as its found
> > to be a real solution.  But with regard to STCP and IPFIX,
> I read RFC
> > 3257, the SCTP Applicability Statement, and I don't see where IPFIX
> > fits.  Benefits of SCTP over TCP are:
> >
> >    multi-streams support
> >    multi-homing support
> >    preservation of message boundaries
> >    unordered reliable message delivery
> >
> > The first three I don't see as requirements for IPFIX.
> > I actually believe the last one to be a problem for IPFIX. STCP is
> > less efficient that TCP, and so if IPFIX doesn't need any
> of these 4
> > items, then I don't see the applicability.
> >
> > Carter
> >
> >
> > > -----Original Message-----
> > > From: Alex Audu [mailto:alex.audu@alcatel.com]
> > > Sent: Thursday, October 02, 2003 2:51 PM
> > > To: carter@qosient.com
> > > Cc: stbryant@cisco.com; 'Reinaldo Penno';
> > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > Subject: Re: [ipfix] STCP as a default transport not
> > >
> > >
> > > Hello Carter,
> > >
> > > If it is true that SCTP hasn't been widely deployed, it
> is probably
> > > because of statements like you have made below. Look, we all know
> > > SCTP has a lot of benefits over TCP.  If folks like you
> don't drive
> > > its deployement
> > > by specifying it as default transport, how will it be
> > > ubiquitous? It is a
> > > self fulfilling prophesy.
> > >
> > > For IETF protocols that recommend SCTP as defaults, see rfc 3057,
> > > rfc 3331 and rfc 3332 just to name a few.
> > >
> > > Regards,
> > > Alex.
> > >
> > > Carter Bullard wrote:
> > >
> > > > I believe that SCTP-PR is not deployed widely enough
> > > > to be considered a default for any IETF technology.
> > > > It is not on my Linux RedHat 9.0 distribution, nor
> > > > my Mac OS-X or my Windows XP system.  I don't see it
> available on
> > > > any Solaris machine that I have access to.
> > > >
> > > > What IETF technology is currently using SCTP as a
> > > > default transport?
> > > >
> > > > Carter
> > > >
> > > > > -----Original Message-----
> > > > > From: majordomo listserver
> [mailto:majordomo@mil.doit.wisc.edu]
> > > > > On Behalf Of Stewart Bryant
> > > > > Sent: Thursday, October 02, 2003 12:14 PM
> > > > > To: Reinaldo Penno
> > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
> > > > > Subject: Re: [ipfix] Ipfix Protocol open items
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Reinaldo Penno wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Have we zeroed in a certain transport protocol? TCP,
> > SCTP-PR or
> > > > > > something else?
> > > > > >
> > > > > > I need to write something to explain how Netflow runs over
> > > > > TCP, but it
> > > > > > seems to me somewhat of a lower priority if this is not
> > > > > going to be the
> > > > > > default protocol. We should focus on explaning how this
> > > > > should work on
> > > > > > the "choosen one".
> > > > >
> > > > > I think that perhaps the question should be put another
> > > way. There are
> > > > > WG members who propose SCTP-PR as the default, and
> SCTP-PR has
> > > > > advantage because of its better flexibility in coping
> > > with congestion.
> > > > >
> > > > > So the real question is whether there are WG members who
> > > think that
> > > > > the default should be TCP. If no group comes forward,
> > then we have
> > > > > our answer. If there is support then we need to perform
> > a detailed
> > > > > analysis of the relative merits of the two protocols.
> > > > >
> > > > > Stewart
> > > > >
> > > > >
> > > > > --
> > > > > 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/
> >
>

------_=_NextPart_001_01C38DE0.C769096A-- -- 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 Oct 9 06:12: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 GAA14356 for ; Thu, 9 Oct 2003 06:12:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7XBH-0002jN-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 04:33:59 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7XBB-0002in-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 04:33:57 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h999Xexu015904 for ; Thu, 9 Oct 2003 11:33:42 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h999Soig015739 for ; Thu, 9 Oct 2003 11:28:50 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h999Sfxs015734; Thu, 09 Oct 2003 11:28:50 +0200 (CEST) Received: from ccrle.nec.de (molina.office [10.1.1.126]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 49D1B14EE5; Thu, 9 Oct 2003 10:56:19 +0200 (CEST) Message-ID: <3F852A48.4010108@ccrle.nec.de> Date: Thu, 09 Oct 2003 11:28:40 +0200 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Tal Givoly'" , stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] bytes and packet counters, tstamp of last report References: <1D3D2C371FCBD947A7897FABBD3533A502960367@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, I posted my original message because I think that the interpretation of an information model should be univoque, and therefore a statement like "this counter can be this or that..." doesn't make sense (and in this respect, I think that the info model is actually broken). My guess is that this "ambiguity" was put on purpose waiting for an agreement about what the counters should really reperesent (absolute or delta). From the replies on the ML, it seems that this is still a subject of discussion. Therefore, I think the correct way to do is to provide support, in the information model, for both type of counters as separate information elements (because sub-typing s not allowed, as Stewart pointed out). Then the discussion on the merits of absolute and delta counters should turn out in indications (in the protocol specification) about whether these counters SHOULD, MAY, MUST, etc.... be exported. Ah, BTW, there's also the same issue for the droppedPacketCount (6.22) and droppedByteCount (6.26). Regards, Maurizio MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >Hi, > > > In some use cases counters may have desirable properties as Tal >has described. But like many things, counters also have their >limitations and downsides. > > In the basic Flow Export scenario which is exemplified by existing >Netflow implementations, a flow record indicates a summary of >observed behavior. > > Consider two flow events: > > sourceAddress=1.2.3.4 > destinationAddress=1.2.3.5 > packetCount=1000 > byteCount=100000 > flowCreationTime=2003-10-08T10:00:00Z > flowEndTime=2003-10-08T10:00:05Z > TcpControlBits=0x13 > > > sourceAddress=1.2.3.4 > destinationAddress=1.2.3.6 > packetCount=1000 > byteCount=200000 > flowCreationTime=2003-10-08T10:00:02Z > flowEndTime=2003-10-08T10:00:06Z > TcpControlBits=0x13 > > Each of these completely describes a conversation, as it includes both > the fin and syn TCP flags. Start time, end time and absolute counts. > > Given the large percentage of flows which when exported, describe a > complete conversation, I don't see the advantage of using counters. > > I'm not even sure how one would propose the use of counters as an > alternative. Would you require two records be sent for each > flow (one with byteCounter and packetCounter=0 and another with > the final value?) > > Since most flows can be represented by a single record, doubling > the number of records to accomodate counters seems a bit odd. > Counters also require the holding of state, which produces > a much greater burden on the collector. Since the necessary > state must be held by the observer, why double the workload? > I.e. a single counter is pretty useless. I need to delta it > against a previously observed matching counter to arrive at a > quantity. > > > For information models such as PSAMP, there may be a compelling > use case. > > So I imagine adding an explicit annotation in the information > model for counters would be worthwile. However, I think that > counter behavior such as when it is zeroed out and its rollover > behavior need to be appropriately documented and thought out. > (e.g. on restart, the counters presumably reset to zero, so > here is additional state a collector may need to monitor to > reconcile (if possible) existing observations). > > For IPFIX's base information model, I would strongly discourage > "fixing" something which isn't broken. > > >Regards, > > Jeff Meyer > >_________________________________________________________________ >Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- > >sign up now! http://join.msn.com/?page=dept/dialup > > > >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu]On Behalf >>Of Tal Givoly >>Sent: Wednesday, October 08, 2003 9:14 AM >>To: stbryant@cisco.com; Maurizio Molina >>Cc: ipfix@net.doit.wisc.edu >>Subject: RE: [ipfix] bytes and packet counters, tstamp of last report >> >> >>Both counters have value (running and delta). Obviously, they >>must be kept >>discrete from an information model perspective as they >>represent different >>information. Devices sometimes maintain one, sometimes the other, and >>sometimes both. Just as an example, as far as I recall, >>NetFlow v5-8 doesn't >>maintain running counters (counter to your suggestion) EVEN THOUGH it >>operates over a non-reliable and non-congestion-aware >>transport. Our probe >>product emits both for various different purposes. >> >>Tal >> >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu]On Behalf >>Of Stewart Bryant >>Sent: Wednesday, October 08, 2003 8:09 AM >>To: Maurizio Molina >>Cc: 'ipfix@net.doit.wisc.edu' >>Subject: Re: [ipfix] bytes and packet counters, tstamp of last report >> >> >> >> >>Maurizio Molina wrote: >> >> >> >>>Hi, >>>the IPFIX info model states (sec. 6.10) that >>> >>> The packet count can be a running counter and is the >>> >>> >>count from the >> >> >>> beginning of the flow establishment. >>> >>> The packet count can be a delta counter and is the count since the >>> last report for this flow. >>> >>> >>> >>I would prefer that we only supported running counters because: >> >>a) Supporting two types is more scope for non-interworking, and >> you can always convert from one to the other at the collector. >> >>b) Running counters also work over an unreliable transport >> whereas delta counters mandate the use of a reliable transport. >> >>c) Running counters are most likely what the hardware is keeping >> anyway, therefore delta counters are more work and more storage >> at the exporter. >> >>If we decide that we need both then we have to represent them >>as two different information elements because the info model does >>not support sub-typing. >> >>Stewart >> >> >> >>>(There's the same statement for byte counts in 6.11). >>> >>>To me, this doesn't clarify wheter it is both...and (2 counters) or >>>either .... or (1 counter). >>> >>>Moreover, there is currently no room for a field containing the >>>timestamp of the last report of a flow. I think that keeping this >>>timestamp is helpful for many applications and the info model should >>>support it. >>>Regards, >>>Maurizio >>> >>> >>> >>>-- >>>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 Oct 9 11:44: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 LAA25003 for ; Thu, 9 Oct 2003 11:44:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7cm7-0007BL-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 10:32:23 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7cm6-0007BE-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 10:32:22 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id E0AFA1C00C7C; Thu, 9 Oct 2003 11:32:21 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id D83471C000A2; Thu, 9 Oct 2003 11:32:21 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id <42JR8XFQ>; Thu, 9 Oct 2003 11:32:21 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296037F@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Maurizio Molina'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Tal Givoly'" , stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Date: Thu, 9 Oct 2003 11:32:13 -0400 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 Maurizio, Thanks for your comment. You are correct, the current wording in the Info Model was lifted from previous content and is ambiguous. This is a problem. Following the existing widely deployed Netflow v2,5,7 behavior out there, the wording should be: The packet count is the count since the last report for this flow if any. Wording about "running counter" should be removed. The unidirectional vs. bidirectional statement is also somewhat ambiguous, but may be acceptable. Whether or not a separate "PacketCounter" info element is required for IPFIX I think is open, since it hasn't been required up to now. But if it is introduced, the info model should include an additional annotation to distinguish "counters" from "counts". Regards, Jeff Meyer > -----Original Message----- > From: Maurizio Molina [mailto:molina@ccrle.nec.de] > Sent: Thursday, October 09, 2003 2:29 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Tal Givoly'; stbryant@cisco.com; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] bytes and packet counters, tstamp of last report > > > Jeff, > I posted my original message because I think that the > interpretation of > an information model should be univoque, and therefore a > statement like > "this counter can be this or that..." doesn't make sense (and in this > respect, I think that the info model is actually broken). > My guess is that this "ambiguity" was put on purpose waiting for an > agreement about what the counters should really reperesent > (absolute or > delta). > From the replies on the ML, it seems that this is still a subject of > discussion. > Therefore, I think the correct way to do is to provide > support, in the > information model, for both type of counters as separate information > elements (because sub-typing s not allowed, as Stewart pointed out). > Then the discussion on the merits of absolute and delta > counters should > turn out in indications (in the protocol specification) about whether > these counters SHOULD, MAY, MUST, etc.... be exported. > Ah, BTW, there's also the same issue for the > droppedPacketCount (6.22) > and droppedByteCount (6.26). > Regards, > Maurizio > > MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > >Hi, > > > > > > In some use cases counters may have desirable properties as Tal > >has described. But like many things, counters also have their > >limitations and downsides. > > > > In the basic Flow Export scenario which is exemplified by existing > >Netflow implementations, a flow record indicates a summary of > >observed behavior. > > > > Consider two flow events: > > > > sourceAddress=1.2.3.4 > > destinationAddress=1.2.3.5 > > packetCount=1000 > > byteCount=100000 > > flowCreationTime=2003-10-08T10:00:00Z > > flowEndTime=2003-10-08T10:00:05Z > > TcpControlBits=0x13 > > > > > > sourceAddress=1.2.3.4 > > destinationAddress=1.2.3.6 > > packetCount=1000 > > byteCount=200000 > > flowCreationTime=2003-10-08T10:00:02Z > > flowEndTime=2003-10-08T10:00:06Z > > TcpControlBits=0x13 > > > > Each of these completely describes a conversation, as it > includes both > > the fin and syn TCP flags. Start time, end time and > absolute counts. > > > > Given the large percentage of flows which when exported, describe a > > complete conversation, I don't see the advantage of using counters. > > > > I'm not even sure how one would propose the use of counters as an > > alternative. Would you require two records be sent for each > > flow (one with byteCounter and packetCounter=0 and another with > > the final value?) > > > > Since most flows can be represented by a single record, doubling > > the number of records to accomodate counters seems a bit odd. > > Counters also require the holding of state, which produces > > a much greater burden on the collector. Since the necessary > > state must be held by the observer, why double the workload? > > I.e. a single counter is pretty useless. I need to delta it > > against a previously observed matching counter to arrive at a > > quantity. > > > > > > For information models such as PSAMP, there may be a compelling > > use case. > > > > So I imagine adding an explicit annotation in the information > > model for counters would be worthwile. However, I think that > > counter behavior such as when it is zeroed out and its rollover > > behavior need to be appropriately documented and thought out. > > (e.g. on restart, the counters presumably reset to zero, so > > here is additional state a collector may need to monitor to > > reconcile (if possible) existing observations). > > > > For IPFIX's base information model, I would strongly discourage > > "fixing" something which isn't broken. > > > > > >Regards, > > > > Jeff Meyer > > > >_________________________________________________________________ > >Get MSN 8 Dial-up Internet Service FREE for one month. > Limited time offer-- > > > >sign up now! http://join.msn.com/?page=dept/dialup > > > > > > > >>-----Original Message----- > >>From: majordomo listserver > >>[mailto:majordomo@mil.doit.wisc.edu]On Behalf > >>Of Tal Givoly > >>Sent: Wednesday, October 08, 2003 9:14 AM > >>To: stbryant@cisco.com; Maurizio Molina > >>Cc: ipfix@net.doit.wisc.edu > >>Subject: RE: [ipfix] bytes and packet counters, tstamp of > last report > >> > >> > >>Both counters have value (running and delta). Obviously, they > >>must be kept > >>discrete from an information model perspective as they > >>represent different > >>information. Devices sometimes maintain one, sometimes the > other, and > >>sometimes both. Just as an example, as far as I recall, > >>NetFlow v5-8 doesn't > >>maintain running counters (counter to your suggestion) EVEN > THOUGH it > >>operates over a non-reliable and non-congestion-aware > >>transport. Our probe > >>product emits both for various different purposes. > >> > >>Tal > >> > >>-----Original Message----- > >>From: majordomo listserver > >>[mailto:majordomo@mil.doit.wisc.edu]On Behalf > >>Of Stewart Bryant > >>Sent: Wednesday, October 08, 2003 8:09 AM > >>To: Maurizio Molina > >>Cc: 'ipfix@net.doit.wisc.edu' > >>Subject: Re: [ipfix] bytes and packet counters, tstamp of > last report > >> > >> > >> > >> > >>Maurizio Molina wrote: > >> > >> > >> > >>>Hi, > >>>the IPFIX info model states (sec. 6.10) that > >>> > >>> The packet count can be a running counter and is the > >>> > >>> > >>count from the > >> > >> > >>> beginning of the flow establishment. > >>> > >>> The packet count can be a delta counter and is the count > since the > >>> last report for this flow. > >>> > >>> > >>> > >>I would prefer that we only supported running counters because: > >> > >>a) Supporting two types is more scope for non-interworking, and > >> you can always convert from one to the other at the collector. > >> > >>b) Running counters also work over an unreliable transport > >> whereas delta counters mandate the use of a reliable transport. > >> > >>c) Running counters are most likely what the hardware is keeping > >> anyway, therefore delta counters are more work and more storage > >> at the exporter. > >> > >>If we decide that we need both then we have to represent them > >>as two different information elements because the info model does > >>not support sub-typing. > >> > >>Stewart > >> > >> > >> > >>>(There's the same statement for byte counts in 6.11). > >>> > >>>To me, this doesn't clarify wheter it is both...and (2 > counters) or > >>>either .... or (1 counter). > >>> > >>>Moreover, there is currently no room for a field containing the > >>>timestamp of the last report of a flow. I think that keeping this > >>>timestamp is helpful for many applications and the info > model should > >>>support it. > >>>Regards, > >>>Maurizio > >>> > >>> > >>> > >>>-- > >>>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 Oct 9 12:25:28 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 MAA26753 for ; Thu, 9 Oct 2003 12:25:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7dRw-0000jj-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 11:15:36 -0500 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 1A7dRv-0000jb-00; Thu, 09 Oct 2003 11:15:35 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-79.cisco.com [144.254.7.79]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h99GFFU15803; Thu, 9 Oct 2003 18:15:15 +0200 (CEST) Message-ID: <3F858993.4040001@cisco.com> Date: Thu, 09 Oct 2003 18:15:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960365@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960365@xsun01.ptp.hp.com> Content-Type: multipart/alternative; boundary="------------080403050508030700020902" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080403050508030700020902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jeff, I would like to comment on your recommendations. >Hi, > > I guess there is a concern of whether we are approaching this from >the "optimize for the usual case" or "optimize for the worst case". > > The former is usually preferred. > > The general concern seems to be appropriate "capacity" on the >collector side so that little to no back pressure occurs on the >sender. > > UDP's fire and forget model makes this trivial, but its lack of >congestion aware behavior is apparently a no no. From the discussion >it sounds like PR_SCTP has similar properties on overflow, where >things just get tossed, like the behavior of the input UDP socket >buffer when the collector is falling behind. > > However, in a mode where the collector is sufficiently endowed >to consume over TCP, which would hopefully be the majority of >situations, taking advantage of TCP's ubiquity and reliability >properties makes a lot of sense to me. > > I'm still dubious of whether disallowing UDP (which happens to >be the only current concrete binding of NFv9) in favor of SCTP-PR >is really the best approach. > > Personally I'd recommend: > > o bindings over TCP for reliable communication while accomodating for > some failover mechanism if the collector becomes congested or >disabled; > But if there is no congestion, I assume that SCTP_PR would do the same good job as TCP in term of reliability. And we know that TCP would have too big memory requirements in case of congestion. Hence you propose to failover mechanism. So why have TCP at all? > o bindings of UDP for best effort (i.e. no exporter back pressure) in > > configurations where exporter and collector are coresident and >congestion > aware behavior is not a concern; > We tried very hard this path. It's a NO from the area director, even for coresident exporter/collector. > o binding of PR_SCTP where congestion aware behavior and best effort >are > desired. > So I conclude that there is only solution left that makes sense! PR_SCTP. Regards, Benoit. > > >Regards, > > Jeff Meyer > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Wednesday, October 08, 2003 6:09 AM >>To: carter@qosient.com >>Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D >>(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] STCP as a default transport not >> >> >> >> >>Carter Bullard wrote: >> >> >> >>>Hey Stewart, >>> >>> >>> >>>>We should spend some time thinking about the behavior we want in the >>>>exporter when the network is congested, perhaps due to an >>>>attack. PR-SCTP >>>>gives us the option of running a best effort data collection >>>>to gleen what >>>>is going on, when a TCP based exporter would otherwise >>>> >>>> >>collapse due to >> >> >>>>backlog on the exporter. >>>> >>>> >>>This is a real engineering issue to talk about. Issues in >>> >>> >>producer/consumer >> >> >>>dynamics are real problems for IPFIX, especially when the >>> >>> >>flow record >> >> >>>source is generating 1M records per second, which my probes >>> >>> >>are capable >> >> >>>of doing. In my experience, the reader/collector not keeping up is >>>never a network congestion problem, it is almost always a >>> >>> >>reader/collector >> >> >>>resource problem, slow disks, not enough memory, competing >>> >>> >>processes, >> >> >>>whatever. >>> >>> >>The critical issue is which side of TCP does it occur. If TCP >>has accepted >>the data then the collector application had better do some >>intelligent. >>My concern is with the exporter or probe having a backlog for >>any reason. >> >> >> >>>It happens in SMP multi-threaded environments where the flow >>>generator and its collector are on the same machine, it >>> >>> >>happens when the >> >> >>>consumer is on the other end of a dedicated ATM, hyper-channel or >>>infiniband links. Its not an issue of reliable vs >>> >>> >>unreliable transport, >> >> >>>its more an issue of what does the probe do when it finds >>> >>> >>it has 1M records >> >> >>>that aren't being consumed, and another 1M records are >>> >>> >>coming very soon. >> >>On this point we absolutely agree. >> >> >> >>>Does it store them, drop them with an indication? >>> >>> >>I think that we have to assume that it does not have the storage. >> >> From the PR_SCTP draft: >> >> One example of partially reliable service is specified in this >> document, namely a "timed reliability" service. This >>service allows >> the service user to indicate a limit on the duration of >>time that the >> sender should try to transmit/retransmit the message (this is a >> natural extension of the "lifetime" parameter already in the base >> protocol). >> >>This seems to have the right properties >> >> >> >>>Does it proactively seek >>>an alternate association, the same association or does it >>> >>> >>wait for the >> >> >>>multiple readers to come back when they are ready. Are >>> >>> >>there going to be >> >> >>>multiple readers? >>> >>>Usually the monitor is being attacked, or its generating >>> >>> >>twice the load >> >> >>>because something else is being attacked in the network. >>> >>> >>No congestion, >> >> >>>just a lot of records. >>> >>> >>Anything that means that the exporter has a bunch of data wedged in >>its output queues waiting for an ACK looks like congestion to >>the exporter. >> >> >> >>>I don't think PR-SCTP touches these problems. >>> >>>If you want the record generator to have a proactive role in >>>failover and recover, maybe RTP/RTCP would be a better choice. >>>Explicit feedback control channel provides enough to decide if >>>it should fail over. >>> >>> >>As I recall RTP requires the application to define its own approach to >>congestion, and we do have to have a congestion strategy. It would >>be better to use a congestion aware transport that has a build-in >>strategy to bail-out if there is a problem, and PR-SCTP has just those >>properties. >> >>Stewart >> >> >> >> >>>Carter >>> >>> >>> >>> >>>>Stewart >>>> >>>> >>>> >>>> >>>>-- >>>>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/ > > --------------080403050508030700020902 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff,

I would like to comment on your recommendations.
Hi,

  I guess there is a concern of whether we are approaching this from
the "optimize for the usual case" or "optimize for the worst case".

  The former is usually preferred.

  The general concern seems to be appropriate "capacity" on the 
collector side so that little to no back pressure occurs on the
sender.

  UDP's fire and forget model makes this trivial, but its lack of
congestion aware behavior is apparently a no no.  From the discussion
it sounds like PR_SCTP has similar properties on overflow, where
things just get tossed, like the behavior of the input UDP socket
buffer when the collector is falling behind.

  However, in a mode where the collector is sufficiently endowed
to consume over TCP, which would hopefully be the majority of
situations, taking advantage of TCP's ubiquity and reliability
properties makes a lot of sense to me.

  I'm still dubious of whether disallowing UDP (which happens to 
be the only current concrete binding of NFv9) in favor of SCTP-PR
is really the best approach.

  Personally I'd recommend:

     o bindings over TCP for reliable communication while accomodating for 
       some failover mechanism if the collector becomes congested or
disabled;
But if there is no congestion, I assume that SCTP_PR would do the same good job as TCP in term of reliability.
And we know that TCP would have too big memory requirements in case of congestion. Hence you propose to failover mechanism.
So why have TCP at all?
     o bindings of UDP for best effort (i.e. no exporter back pressure) in

       configurations where exporter and collector are coresident and
congestion 
       aware behavior is not a concern;
We tried very hard this path. It's a NO from the area director, even for coresident exporter/collector.
     o binding of PR_SCTP where congestion aware behavior and best effort
are 
       desired.
So I conclude that there is only solution left that makes sense! PR_SCTP.

Regards, Benoit.



Regards,

  Jeff Meyer

  
-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, October 08, 2003 6:09 AM
To: carter@qosient.com
Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D
(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu;
ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] STCP as a default transport not




Carter Bullard wrote:

    
Hey Stewart,

      
We should spend some time thinking about the behavior we want in the
exporter when the network is congested, perhaps due to an
attack. PR-SCTP
gives us the option of running a best effort data collection
to gleen what
is going on, when a TCP based exporter would otherwise 
        
collapse due to
    
backlog on the exporter.
        
This is a real engineering issue to talk about.  Issues in 
      
producer/consumer
    
dynamics are real problems for IPFIX, especially when the 
      
flow record
    
source is generating 1M records per second, which my probes 
      
are capable
    
of doing.  In my experience, the reader/collector not keeping up is
never a network congestion problem,  it is almost always a 
      
reader/collector
    
resource problem, slow disks, not enough memory, competing 
      
processes,
    
whatever.  
      
The critical issue is which side of TCP does it occur. If TCP 
has accepted
the data then the collector application had better do some 
intelligent.
My concern is with the exporter or probe having a backlog for 
any reason.

    
It happens in SMP multi-threaded environments where the flow
generator and its collector are on the same machine, it 
      
happens when the
    
consumer is on the other end of a dedicated ATM, hyper-channel or
infiniband links.  Its not an issue of reliable vs 
      
unreliable transport,
    
its more an issue of what does the probe do when it finds 
      
it has 1M records
    
that aren't being consumed, and another 1M records are 
      
coming very soon.

On this point we absolutely agree.

    
Does it store them, drop them with an indication?  
      
I think that we have to assume that it does not have the storage.

 From the PR_SCTP draft:

    One example of partially reliable service is specified in this
    document, namely a "timed reliability" service.  This 
service allows
    the service user to indicate a limit on the duration of 
time that the
    sender should try to transmit/retransmit the message (this is a
    natural extension of the "lifetime" parameter already in the base
    protocol).

This seems to have the right properties

    
Does it proactively seek
an alternate association, the same association or does it 
      
wait for the
    
multiple readers to come back when they are ready.  Are 
      
there going to be
    
multiple readers?

Usually the monitor is being attacked, or its generating 
      
twice the load
    
because something else is being attacked in the network.  
      
No congestion,
    
just a lot of records.  
      
Anything that means that the exporter has a bunch of data wedged in
its output queues waiting for an ACK looks like congestion to 
the exporter.

    
I don't think PR-SCTP touches these problems.

If you want the record generator to have a proactive role in
failover and recover, maybe RTP/RTCP would be a better choice.
Explicit feedback control channel provides enough to decide if
it should fail over.
      
As I recall RTP requires the application to define its own approach to
congestion, and we do have to have a congestion strategy. It would
be better to use a congestion aware transport that has a build-in
strategy to bail-out if there is a problem, and PR-SCTP has just those
properties.

Stewart


    
Carter


      
Stewart




--
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/

--------------080403050508030700020902-- -- 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 Oct 9 12:26: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 MAA26828 for ; Thu, 9 Oct 2003 12:26:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7dRn-0000jJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 11:15:27 -0500 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 1A7dRl-0000j9-00; Thu, 09 Oct 2003 11:15:25 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-79.cisco.com [144.254.7.79]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h99GF1U15578; Thu, 9 Oct 2003 18:15:01 +0200 (CEST) Message-ID: <3F858985.3000907@cisco.com> Date: Thu, 09 Oct 2003 18:15:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stbryant@cisco.com CC: alex.audu@alcatel.com, carter@qosient.com, "'Reinaldo Penno'" , "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6A9@ptah.newyork.qosient.com> <3F82D3EB.39B16507@alcatel.com> <3F82D7EB.1010101@cisco.com> In-Reply-To: <3F82D7EB.1010101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, There are advantages regarding the use of SCTP versus TCP (discussed already on the list) but I think that the biggest advantage of SCTP is actually the extension SCTP-PR. And I'm surprised to see no reactions on the email below. Yes, I know that the SCTP-PR is not a standard yet but I think that we should just take the right protocol instead of just using what exists because it exists! I remember the heated discussions maybe one year ago about using IPFIX for billing, about high availability, etc... And one of the solution that could make everybody happy is: SCTP-PR. We know that we do have some memory issues with TCP on the high-end routers. But, for the smaller exporter OR if you can afford/if it's possible to pack the exporter with the appropriate amount of memory, SCTP-PR would work perfectly well! Now, in the majority of cases (no billing, no enough memory/too many flow records, etc...) SCTP-PR would drop the flow records excess if any, which I think is the right thing to do. Regards, Benoit. > > I think that the interest is in using PR-SCTP as described in > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > rather than RFC 2960 SCTP. > > This claims the following benefits: > > > 1.3 Benefits of PR-SCTP > > Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > protocol extended as defined in this document. > > The following are some of the advantages for integrating partially > reliable data service into SCTP, i.e., benefits of PR-SCTP: > > 1. Some application layer protocols may benefit from being able to > use a single SCTP association to carry both reliable content, -- > such as text pages, billing and accounting information, setup > signaling -- and unreliable content, e.g. state that is highly > sensitive to timeliness, where generating a new packet is more > advantageous than transmitting an old one [1]. > > 2. Partially reliable data traffic carried by PR-SCTP will enjoy the > same communication failure detection and protection capabilities > as the normal reliable SCTP data traffic does. This includes the > ability to: - quickly detect a failed destination address; - > fail-over to an alternate destination address, and; - be notified > if the data receiver becomes unreachable. > > 3. In addition to providing unordered unreliable data transfer as > UDP does, PR-SCTP can provide ordered unreliable data transfer > service. > > 4. PR-SCTP employs the same congestion control and congestion > avoidance for all data traffic, whether reliable or partially > reliable - this is very desirable since SCTP enforces > TCP-friendliness (unlike UDP.) > > 5. Because of the chunk bundling function of SCTP, reliable and > unreliable messages can be multiplexed over a single PR-SCTP > association. Therefore, the number of IP datagrams (and hence > the network overhead) can be reduced versus having to send these > different types of data using separate protocols. Additionally, > this multiplexing allows for port savings versus using different > ports for reliable and unreliable connections. > > ---------- > > PR-SCTP has the option of being able to configure the exporter to work > on a > best effort data export basis, rather than being constrained to work on a > reliable basis. > > We should spend some time thinking about the behaviour we want in the > exporter when the network is congested, perhaps due to an attack. PR-SCTP > gives us the option of running a best effort data collection to gleen > what > is going on, when a TCP based exporter would otherwise collapse due to > backlog on the exporter. > > Stewart > > > > > -- > 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 Oct 9 12:57:19 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 MAA29257 for ; Thu, 9 Oct 2003 12:57:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7dwV-0001i4-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 11:47:11 -0500 Received: from web80405.mail.yahoo.com ([66.218.79.60]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7dwT-0001hs-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 11:47:09 -0500 Message-ID: <20031009164706.44712.qmail@web80405.mail.yahoo.com> Received: from [216.145.61.174] by web80405.mail.yahoo.com via HTTP; Thu, 09 Oct 2003 09:47:06 PDT Date: Thu, 9 Oct 2003 09:47:06 -0700 (PDT) From: Peter Ludemann Subject: Re: [ipfix] STCP as a default transport not To: Benoit Claise , "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" Cc: "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu In-Reply-To: <3F858993.4040001@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver I want to correct one misunderstanding about TCP/IP ... Benoit Claise wrote: > And we know that TCP would have too big memory requirements > in case of congestion. Hence you propose to failover > mechanism. > So why have TCP at all? The "too big memory requirements" has nothing to do with TCP/IP and is solely a function of the desired over-all reliability and granularity of the data transfer. In most implementations of TCP, you can do blocking or non-blocking I/O. In the blocking case, your write is blocked as soon as the TCP buffer is full (typically, the buffer is 256K or smaller but you can make it as small as 8K or so if you want). So, you probably won't do things this way (you can handle this properly with multi-threading; but the net result is very similar to non-blocking I/O [next paragraph]). In the non-blocking case, you get a return code that the buffer is full. You can then decide whether or not to queue the data or do something else with it (you have to implement this queuing yourself). So, the "big memory requirements" has *nothing* to do with TCP and is only to do with how granular and reliable you want the information transmission. If you want to throw data away when the network is congested, TCP will cooperate very nicely with you. The difference from using UDP is that the transmitter actually knows what is being thrown away. Alternatively, TCP/IP (or another reliable transport) allows the data transmitter to observe congestion or network outage and then aggregating statistics until the congestion or outage goes away. -- 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 Oct 9 13:13:53 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 NAA29880 for ; Thu, 9 Oct 2003 13:13:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7eC1-0002HQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 12:03:13 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7eC0-0002HL-00; Thu, 09 Oct 2003 12:03:12 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id F1E6A1C02B10; Thu, 9 Oct 2003 13:03:11 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id E6E4C1C000B5; Thu, 9 Oct 2003 13:03:11 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4SN0V3T2>; Thu, 9 Oct 2003 13:03:11 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960380@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Benoit Claise'" , stbryant@cisco.com Cc: alex.audu@alcatel.com, carter@qosient.com, "'Reinaldo Penno'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 13:03:02 -0400 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 Benoit, SCTP-PR does not make me happy, nor do the previous decisions around reliability as it regards to billing. Dropping packets under congestion is already done by UDP, and UDP is ubiquitous in all OS's. Is there some challenge in defining IPFIX over TCP? It seems to me that this is the easier case, there are less things to map to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP your proposal, i.e. force the use of SCTP-PR? As with the experience of Diameter, specifying both transports will enable a migration to SCTP-PR for everyone if it actually proves to have the values espoused and it is readily available. In the interim having a TCP mapping (and UDP) would address the requirements which I've encountered (billing issues aside). As Peter pointed out the resource constraints on the exporter imposed by TCP can be mitigated in the implementation. Regards, Jeff Meyer > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Thursday, October 09, 2003 9:15 AM > To: stbryant@cisco.com > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: Re: [ipfix] STCP as a default transport not > > > Dear all, > > There are advantages regarding the use of SCTP versus TCP (discussed > already on the list) but I think that the biggest advantage > of SCTP is > actually the extension SCTP-PR. And I'm surprised to see no > reactions on > the email below. > Yes, I know that the SCTP-PR is not a standard yet but I > think that we > should just take the right protocol instead of just using what exists > because it exists! > > I remember the heated discussions maybe one year ago about > using IPFIX > for billing, about high availability, etc... > And one of the solution that could make everybody happy is: SCTP-PR. > We know that we do have some memory issues with TCP on the > high-end routers. > But, for the smaller exporter OR if you can afford/if it's > possible to > pack the exporter with the appropriate amount of memory, > SCTP-PR would > work perfectly well! > Now, in the majority of cases (no billing, no enough memory/too many > flow records, etc...) SCTP-PR would drop the flow records > excess if any, > which I think is the right thing to do. > > Regards, Benoit. > > > > > > I think that the interest is in using PR-SCTP as described in > > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > > > rather than RFC 2960 SCTP. > > > > This claims the following benefits: > > > > > > 1.3 Benefits of PR-SCTP > > > > Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > > protocol extended as defined in this document. > > > > The following are some of the advantages for integrating > partially > > reliable data service into SCTP, i.e., benefits of PR-SCTP: > > > > 1. Some application layer protocols may benefit from > being able to > > use a single SCTP association to carry both reliable > content, -- > > such as text pages, billing and accounting information, setup > > signaling -- and unreliable content, e.g. state that > is highly > > sensitive to timeliness, where generating a new > packet is more > > advantageous than transmitting an old one [1]. > > > > 2. Partially reliable data traffic carried by PR-SCTP > will enjoy the > > same communication failure detection and protection > capabilities > > as the normal reliable SCTP data traffic does. This > includes the > > ability to: - quickly detect a failed destination address; - > > fail-over to an alternate destination address, and; > - be notified > > if the data receiver becomes unreachable. > > > > 3. In addition to providing unordered unreliable data > transfer as > > UDP does, PR-SCTP can provide ordered unreliable > data transfer > > service. > > > > 4. PR-SCTP employs the same congestion control and congestion > > avoidance for all data traffic, whether reliable or partially > > reliable - this is very desirable since SCTP enforces > > TCP-friendliness (unlike UDP.) > > > > 5. Because of the chunk bundling function of SCTP, reliable and > > unreliable messages can be multiplexed over a single PR-SCTP > > association. Therefore, the number of IP datagrams > (and hence > > the network overhead) can be reduced versus having > to send these > > different types of data using separate protocols. > Additionally, > > this multiplexing allows for port savings versus > using different > > ports for reliable and unreliable connections. > > > > ---------- > > > > PR-SCTP has the option of being able to configure the > exporter to work > > on a > > best effort data export basis, rather than being > constrained to work on a > > reliable basis. > > > > We should spend some time thinking about the behaviour we > want in the > > exporter when the network is congested, perhaps due to an > attack. PR-SCTP > > gives us the option of running a best effort data > collection to gleen > > what > > is going on, when a TCP based exporter would otherwise > collapse due to > > backlog on the exporter. > > > > Stewart > > > > > > > > > > -- > > 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 Oct 9 13:39:02 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 NAA00811 for ; Thu, 9 Oct 2003 13:39:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7eVP-0002rk-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 12:23:15 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7eVO-0002rd-00; Thu, 09 Oct 2003 12:23:14 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7eVM-00026b-Te; Thu, 09 Oct 2003 17:23:13 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7eVJ-000Kaj-6F; Thu, 09 Oct 2003 10:23:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Oct 2003 10:23:07 -0700 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Benoit Claise'" , stbryant@cisco.com, alex.audu@alcatel.com, carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: RE: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960380@xsun01.ptp.hp.com> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Dropping packets under congestion is already done by UDP, and > UDP is ubiquitous in all OS's. congestion control is not about you losing your data. it is about your damaging the data of others. randy -- 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 Oct 9 13:40: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 NAA00928 for ; Thu, 9 Oct 2003 13:40:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7eb8-0002yJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 12:29:10 -0500 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7eb7-0002xV-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 12:29:09 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h99HEbVA030554 for ; Thu, 9 Oct 2003 12:28:49 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C0118898E for ipfix@net.doit.wisc.edu; Thu, 9 Oct 2003 13:28:32 -0400 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 12:28:50 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA2378B5@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [ipfix] STCP as a default transport not Thread-Index: AcOOhnTQwTzHKpt8Qui0D+fAboG8kAAAcNHw From: "Brown, Mark R, ALABS" To: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Peter Ludemann wrote: >Alternatively, TCP/IP (or another reliable transport) allows >the data transmitter to observe congestion or network outage >and then aggregating statistics until the congestion or >outage goes away. I agree that it would be desireable to have a mechanism in IPFIX to to report to the collector on the amount of data tossed by the exporter due to buffer overflow (e.g., total flows, bytes, start and end times) once the congestion period has cleared. Could such a mechanism be defined so that it would require a fixed maximum amount of memory (ignoring possible counter wrap) regardless of the length of the congestion period(s) or the amount of data loss?=20 Mark Brown AT&T=20 -----Original Message----- From: Peter Ludemann [mailto:p_ludemann@yahoo.com] Sent: Thursday, October 09, 2003 12:47 PM To: Benoit Claise; MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not I want to correct one misunderstanding about TCP/IP ... Benoit Claise wrote: > And we know that TCP would have too big memory requirements > in case of congestion. Hence you propose to failover > mechanism. > So why have TCP at all? The "too big memory requirements" has nothing to do with TCP/IP and is solely a function of the desired over-all reliability and granularity of the data transfer. In most implementations of TCP, you can do blocking or non-blocking I/O. In the blocking case, your write is blocked as soon as the TCP buffer is full (typically, the buffer is 256K or smaller but you can make it as small as 8K or so if you want). So, you probably won't do things this way (you can handle this properly with multi-threading; but the net result is very similar to non-blocking I/O [next paragraph]). In the non-blocking case, you get a return code that the buffer is full. You can then decide whether or not to queue the data or do something else with it (you have to implement this queuing yourself). So, the "big memory requirements" has *nothing* to do with TCP and is only to do with how granular and reliable you want the information transmission. If you want to throw data away when the network is congested, TCP will cooperate very nicely with you. The difference from using UDP is that the transmitter actually knows what is being thrown away. Alternatively, TCP/IP (or another reliable transport) allows the data transmitter to observe congestion or network outage and then aggregating statistics until the congestion or outage goes away. -- 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 Oct 9 14:04: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 OAA01849 for ; Thu, 9 Oct 2003 14:04:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7ewE-0003fi-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 12:50:58 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7ewD-0003fa-00; Thu, 09 Oct 2003 12:50:57 -0500 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id 97FA21C01964; Thu, 9 Oct 2003 13:50:56 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 8850A1C000A2; Thu, 9 Oct 2003 13:50:56 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4SN0VYR8>; Thu, 9 Oct 2003 13:50:56 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960382@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Randy Bush'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Benoit Claise'" , stbryant@cisco.com, alex.audu@alcatel.com, carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 13:49:34 -0400 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 In the IPFIX space there are two aspects to congestion control. As you cite, consuming an unfair percentage of resources is something which TCP avoids and UDP does not. However many Netflow deployments have switched direct connections between the exporter and the collector. I.e. there's nobody else's traffic to damage. At that point, congestion becomes an issue of whether the exporter can "keep up" with the exporter. The main concern I hear around TCP/IP is that the stack will be sitting on unacknowledged packets and ultimately apply back pressure to the exporter if the collector slows down. Not acknowledging that the UDP over dedicated connection is a common and valid use case AND that in this use case, the "congestion aware" aspect of fairness is a moot point is poor engineering. -- Jeff > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, October 09, 2003 10:23 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Benoit Claise'; stbryant@cisco.com; alex.audu@alcatel.com; > carter@qosient.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: RE: [ipfix] STCP as a default transport not > > > > Dropping packets under congestion is already done by UDP, and > > UDP is ubiquitous in all OS's. > > congestion control is not about you losing your data. it is about > your damaging the data of others. > > randy > -- 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 Oct 9 14:09: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 OAA01980 for ; Thu, 9 Oct 2003 14:09:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7f3S-0003vo-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 12:58:26 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7f3R-0003vh-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 12:58:25 -0500 Received: (qmail 37032 invoked from network); 9 Oct 2003 17:58:24 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 17:58:24 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99HwNX16202; Thu, 9 Oct 2003 13:58:23 -0400 Reply-To: From: "Carter Bullard" To: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Benoit Claise'" , Cc: , "'Reinaldo Penno'" , , , Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 13:58:17 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6AE@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE170@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver I'm unhappy that the only apparent considerations are connection oriented and unicast. I'm going to use multicast to move flow data in some situations, and at this point, no candidate IPFIX transport is going to make it. When I mentioned RTP earlier, I was not being facetious. The IESG seems to think that RTP/UDP is not verboten, from a congestion perspective, regardless of the speeds, so I believe that that should be on a discussion list. Carter > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Thursday, October 09, 2003 12:03 PM > To: 'Benoit Claise'; stbryant@cisco.com > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo > Penno'; MEYER,JEFFREY D (HP-Cupertino,ex1); > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: RE: [ipfix] STCP as a default transport not > > > Benoit, > > SCTP-PR does not make me happy, nor do the previous decisions > around reliability as it regards to billing. > > Dropping packets under congestion is already done by UDP, and > UDP is ubiquitous in all OS's. > > Is there some challenge in defining IPFIX over TCP? It seems > to me that this is the easier case, there are less things to map > to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > your proposal, i.e. force the use of SCTP-PR? > > As with the experience of Diameter, specifying both transports > will enable a migration to SCTP-PR for everyone if it actually > proves to have the values espoused and it is readily available. > In the interim having a TCP mapping (and UDP) would address the > requirements which I've encountered (billing issues aside). > > As Peter pointed out the resource constraints on the exporter > imposed by TCP can be mitigated in the implementation. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Thursday, October 09, 2003 9:15 AM > > To: stbryant@cisco.com > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > > 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > ipfix-chairs@net.doit.wisc.edu; > > ipfix@net.doit.wisc.edu; rrs@cisco.com > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Dear all, > > > > There are advantages regarding the use of SCTP versus TCP > (discussed > > already on the list) but I think that the biggest advantage > > of SCTP is > > actually the extension SCTP-PR. And I'm surprised to see no > > reactions on > > the email below. > > Yes, I know that the SCTP-PR is not a standard yet but I > > think that we > > should just take the right protocol instead of just using > what exists > > because it exists! > > > > I remember the heated discussions maybe one year ago about > > using IPFIX > > for billing, about high availability, etc... > > And one of the solution that could make everybody happy is: SCTP-PR. > > We know that we do have some memory issues with TCP on the > > high-end routers. > > But, for the smaller exporter OR if you can afford/if it's > > possible to > > pack the exporter with the appropriate amount of memory, > > SCTP-PR would > > work perfectly well! > > Now, in the majority of cases (no billing, no enough > memory/too many > > flow records, etc...) SCTP-PR would drop the flow records > > excess if any, > > which I think is the right thing to do. > > > > Regards, Benoit. > > > > > > > > > > I think that the interest is in using PR-SCTP as described in > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > > > > > rather than RFC 2960 SCTP. > > > > > > This claims the following benefits: > > > > > > > > > 1.3 Benefits of PR-SCTP > > > > > > Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > > > protocol extended as defined in this document. > > > > > > The following are some of the advantages for integrating > > partially > > > reliable data service into SCTP, i.e., benefits of PR-SCTP: > > > > > > 1. Some application layer protocols may benefit from > > being able to > > > use a single SCTP association to carry both reliable > > content, -- > > > such as text pages, billing and accounting > information, setup > > > signaling -- and unreliable content, e.g. state that > > is highly > > > sensitive to timeliness, where generating a new > > packet is more > > > advantageous than transmitting an old one [1]. > > > > > > 2. Partially reliable data traffic carried by PR-SCTP > > will enjoy the > > > same communication failure detection and protection > > capabilities > > > as the normal reliable SCTP data traffic does. This > > includes the > > > ability to: - quickly detect a failed destination > address; - > > > fail-over to an alternate destination address, and; > > - be notified > > > if the data receiver becomes unreachable. > > > > > > 3. In addition to providing unordered unreliable data > > transfer as > > > UDP does, PR-SCTP can provide ordered unreliable > > data transfer > > > service. > > > > > > 4. PR-SCTP employs the same congestion control and congestion > > > avoidance for all data traffic, whether reliable > or partially > > > reliable - this is very desirable since SCTP enforces > > > TCP-friendliness (unlike UDP.) > > > > > > 5. Because of the chunk bundling function of SCTP, > reliable and > > > unreliable messages can be multiplexed over a > single PR-SCTP > > > association. Therefore, the number of IP datagrams > > (and hence > > > the network overhead) can be reduced versus having > > to send these > > > different types of data using separate protocols. > > Additionally, > > > this multiplexing allows for port savings versus > > using different > > > ports for reliable and unreliable connections. > > > > > > ---------- > > > > > > PR-SCTP has the option of being able to configure the > > exporter to work > > > on a > > > best effort data export basis, rather than being > > constrained to work on a > > > reliable basis. > > > > > > We should spend some time thinking about the behaviour we > > want in the > > > exporter when the network is congested, perhaps due to an > > attack. PR-SCTP > > > gives us the option of running a best effort data > > collection to gleen > > > what > > > is going on, when a TCP based exporter would otherwise > > collapse due to > > > backlog on the exporter. > > > > > > Stewart > > > > > > > > > > > > > > > -- > > > 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 Oct 9 14:12: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 OAA02094 for ; Thu, 9 Oct 2003 14:12:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7f8D-00047Y-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 13:03:21 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7f8B-00047T-00; Thu, 09 Oct 2003 13:03:19 -0500 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel10.hp.com (Postfix) with ESMTP id BC2C01C00E10; Thu, 9 Oct 2003 11:03:18 -0700 (PDT) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id A1E391C000AC; Thu, 9 Oct 2003 11:03:18 -0700 (PDT) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <43X0695G>; Thu, 9 Oct 2003 11:03:18 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960383@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Benoit Claise'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 11:03:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38E8F.98BC938E" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38E8F.98BC938E Content-Type: text/plain; charset="iso-8859-1" Benoit, In answer to your question "So why have TCP at all?" I'll repeat, ready availability of implementations on common platforms. The cost of packaging and certifying a collector solution on TCP vs. SCTP is going to be SIGNIFICANTLY less expensive. Because SCTP belongs in kernel vs. user space, this is not going to just magically become ubiquitous. I guess if your goal is to limit collectors to C implementations on Linux or BSD then one could argue that "we have it now". However if Windows or Java are targets for collection platforms, you're kinda stuck at the moment. I don't think these are insignificant considerations. -- Jeff -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Thursday, October 09, 2003 9:15 AM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not Jeff, I would like to comment on your recommendations. Hi, I guess there is a concern of whether we are approaching this from the "optimize for the usual case" or "optimize for the worst case". The former is usually preferred. The general concern seems to be appropriate "capacity" on the collector side so that little to no back pressure occurs on the sender. UDP's fire and forget model makes this trivial, but its lack of congestion aware behavior is apparently a no no. From the discussion it sounds like PR_SCTP has similar properties on overflow, where things just get tossed, like the behavior of the input UDP socket buffer when the collector is falling behind. However, in a mode where the collector is sufficiently endowed to consume over TCP, which would hopefully be the majority of situations, taking advantage of TCP's ubiquity and reliability properties makes a lot of sense to me. I'm still dubious of whether disallowing UDP (which happens to be the only current concrete binding of NFv9) in favor of SCTP-PR is really the best approach. Personally I'd recommend: o bindings over TCP for reliable communication while accomodating for some failover mechanism if the collector becomes congested or disabled; But if there is no congestion, I assume that SCTP_PR would do the same good job as TCP in term of reliability. And we know that TCP would have too big memory requirements in case of congestion. Hence you propose to failover mechanism. So why have TCP at all? o bindings of UDP for best effort (i.e. no exporter back pressure) in configurations where exporter and collector are coresident and congestion aware behavior is not a concern; We tried very hard this path. It's a NO from the area director, even for coresident exporter/collector. o binding of PR_SCTP where congestion aware behavior and best effort are desired. So I conclude that there is only solution left that makes sense! PR_SCTP. Regards, Benoit. Regards, Jeff Meyer -----Original Message----- From: Stewart Bryant [ mailto:stbryant@cisco.com ] Sent: Wednesday, October 08, 2003 6:09 AM To: carter@qosient.com Cc: alex.audu@alcatel.com ; 'Reinaldo Penno'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu ; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not Carter Bullard wrote: Hey Stewart, We should spend some time thinking about the behavior we want in the exporter when the network is congested, perhaps due to an attack. PR-SCTP gives us the option of running a best effort data collection to gleen what is going on, when a TCP based exporter would otherwise collapse due to backlog on the exporter. This is a real engineering issue to talk about. Issues in producer/consumer dynamics are real problems for IPFIX, especially when the flow record source is generating 1M records per second, which my probes are capable of doing. In my experience, the reader/collector not keeping up is never a network congestion problem, it is almost always a reader/collector resource problem, slow disks, not enough memory, competing processes, whatever. The critical issue is which side of TCP does it occur. If TCP has accepted the data then the collector application had better do some intelligent. My concern is with the exporter or probe having a backlog for any reason. It happens in SMP multi-threaded environments where the flow generator and its collector are on the same machine, it happens when the consumer is on the other end of a dedicated ATM, hyper-channel or infiniband links. Its not an issue of reliable vs unreliable transport, its more an issue of what does the probe do when it finds it has 1M records that aren't being consumed, and another 1M records are coming very soon. On this point we absolutely agree. Does it store them, drop them with an indication? I think that we have to assume that it does not have the storage. From the PR_SCTP draft: One example of partially reliable service is specified in this document, namely a "timed reliability" service. This service allows the service user to indicate a limit on the duration of time that the sender should try to transmit/retransmit the message (this is a natural extension of the "lifetime" parameter already in the base protocol). This seems to have the right properties Does it proactively seek an alternate association, the same association or does it wait for the multiple readers to come back when they are ready. Are there going to be multiple readers? Usually the monitor is being attacked, or its generating twice the load because something else is being attacked in the network. No congestion, just a lot of records. Anything that means that the exporter has a bunch of data wedged in its output queues waiting for an ACK looks like congestion to the exporter. I don't think PR-SCTP touches these problems. If you want the record generator to have a proactive role in failover and recover, maybe RTP/RTCP would be a better choice. Explicit feedback control channel provides enough to decide if it should fail over. As I recall RTP requires the application to define its own approach to congestion, and we do have to have a congestion strategy. It would be better to use a congestion aware transport that has a build-in strategy to bail-out if there is a problem, and PR-SCTP has just those properties. Stewart Carter Stewart -- 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/ ------_=_NextPart_001_01C38E8F.98BC938E Content-Type: text/html; charset="iso-8859-1"
Benoit,
 
  In answer to your question "So why have TCP at all?"
 
  I'll repeat, ready availability of implementations on common platforms.
 
  The cost of packaging and certifying a collector solution on TCP vs. SCTP is going to be SIGNIFICANTLY less expensive.  Because SCTP belongs in kernel vs. user space, this is not going to just magically become ubiquitous.
 
  I guess if your goal is to limit collectors to C implementations on Linux or BSD then one could argue that "we have it now".  However if Windows or Java are targets for collection platforms, you're kinda stuck at the moment.  I don't think these are insignificant considerations.
 
-- Jeff
-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, October 09, 2003 9:15 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] STCP as a default transport not

Jeff,

I would like to comment on your recommendations.
Hi,

  I guess there is a concern of whether we are approaching this from
the "optimize for the usual case" or "optimize for the worst case".

  The former is usually preferred.

  The general concern seems to be appropriate "capacity" on the 
collector side so that little to no back pressure occurs on the
sender.

  UDP's fire and forget model makes this trivial, but its lack of
congestion aware behavior is apparently a no no.  From the discussion
it sounds like PR_SCTP has similar properties on overflow, where
things just get tossed, like the behavior of the input UDP socket
buffer when the collector is falling behind.

  However, in a mode where the collector is sufficiently endowed
to consume over TCP, which would hopefully be the majority of
situations, taking advantage of TCP's ubiquity and reliability
properties makes a lot of sense to me.

  I'm still dubious of whether disallowing UDP (which happens to 
be the only current concrete binding of NFv9) in favor of SCTP-PR
is really the best approach.

  Personally I'd recommend:

     o bindings over TCP for reliable communication while accomodating for 
       some failover mechanism if the collector becomes congested or
disabled;
But if there is no congestion, I assume that SCTP_PR would do the same good job as TCP in term of reliability.
And we know that TCP would have too big memory requirements in case of congestion. Hence you propose to failover mechanism.
So why have TCP at all?
     o bindings of UDP for best effort (i.e. no exporter back pressure) in

       configurations where exporter and collector are coresident and
congestion 
       aware behavior is not a concern;
We tried very hard this path. It's a NO from the area director, even for coresident exporter/collector.
     o binding of PR_SCTP where congestion aware behavior and best effort
are 
       desired.
So I conclude that there is only solution left that makes sense! PR_SCTP.

Regards, Benoit.


Regards,

  Jeff Meyer

  
-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, October 08, 2003 6:09 AM
To: carter@qosient.com
Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D
(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu;
ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] STCP as a default transport not




Carter Bullard wrote:

    
Hey Stewart,

      
We should spend some time thinking about the behavior we want in the
exporter when the network is congested, perhaps due to an
attack. PR-SCTP
gives us the option of running a best effort data collection
to gleen what
is going on, when a TCP based exporter would otherwise 
        
collapse due to
    
backlog on the exporter.
        
This is a real engineering issue to talk about.  Issues in 
      
producer/consumer
    
dynamics are real problems for IPFIX, especially when the 
      
flow record
    
source is generating 1M records per second, which my probes 
      
are capable
    
of doing.  In my experience, the reader/collector not keeping up is
never a network congestion problem,  it is almost always a 
      
reader/collector
    
resource problem, slow disks, not enough memory, competing 
      
processes,
    
whatever.  
      
The critical issue is which side of TCP does it occur. If TCP 
has accepted
the data then the collector application had better do some 
intelligent.
My concern is with the exporter or probe having a backlog for 
any reason.

    
It happens in SMP multi-threaded environments where the flow
generator and its collector are on the same machine, it 
      
happens when the
    
consumer is on the other end of a dedicated ATM, hyper-channel or
infiniband links.  Its not an issue of reliable vs 
      
unreliable transport,
    
its more an issue of what does the probe do when it finds 
      
it has 1M records
    
that aren't being consumed, and another 1M records are 
      
coming very soon.

On this point we absolutely agree.

    
Does it store them, drop them with an indication?  
      
I think that we have to assume that it does not have the storage.

 From the PR_SCTP draft:

    One example of partially reliable service is specified in this
    document, namely a "timed reliability" service.  This 
service allows
    the service user to indicate a limit on the duration of 
time that the
    sender should try to transmit/retransmit the message (this is a
    natural extension of the "lifetime" parameter already in the base
    protocol).

This seems to have the right properties

    
Does it proactively seek
an alternate association, the same association or does it 
      
wait for the
    
multiple readers to come back when they are ready.  Are 
      
there going to be
    
multiple readers?

Usually the monitor is being attacked, or its generating 
      
twice the load
    
because something else is being attacked in the network.  
      
No congestion,
    
just a lot of records.  
      
Anything that means that the exporter has a bunch of data wedged in
its output queues waiting for an ACK looks like congestion to 
the exporter.

    
I don't think PR-SCTP touches these problems.

If you want the record generator to have a proactive role in
failover and recover, maybe RTP/RTCP would be a better choice.
Explicit feedback control channel provides enough to decide if
it should fail over.
      
As I recall RTP requires the application to define its own approach to
congestion, and we do have to have a congestion strategy. It would
be better to use a congestion aware transport that has a build-in
strategy to bail-out if there is a problem, and PR-SCTP has just those
properties.

Stewart


    
Carter


      
Stewart




--
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/

------_=_NextPart_001_01C38E8F.98BC938E-- -- 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 Oct 9 14:40: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 OAA03055 for ; Thu, 9 Oct 2003 14:40:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7fOS-0004me-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 13:20:08 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7fOR-0004mX-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 13:20:07 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7fOQ-0005Ff-M2 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 18:20:06 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7fOQ-000KeM-8r for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 11:20:06 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Oct 2003 11:20:05 -0700 To: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960383@xsun01.ptp.hp.com> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit it is interesting that folk seem to have enough free time on their hands to be willing to go around the same discussion for the Nth time. randy -- 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 Oct 9 14:44: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 OAA03234 for ; Thu, 9 Oct 2003 14:44:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7fY4-0004x2-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 13:30:04 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7fY0-0004wB-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 13:30:00 -0500 Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by comcast.net (rwcrmhc11) with SMTP id <2003100918295801300qnopke>; Thu, 9 Oct 2003 18:29:58 +0000 Message-ID: <3F85A925.7090807@ieee.org> Date: Thu, 09 Oct 2003 13:29:57 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I don't really understand this UDP thread... I thought that it was essentially "mandated" that the transport protocol used MUST be congestion aware. That ruled UDP out long ago, no?? Or is that going to be debated again?! I didn't see anyone point this out yet, but PR-SCTP is not just "best effort" w/congestion control... it is an extension to SCTP such that you can do any reliability level from best effort (UDP-like) to fully reliable (SCTP or TCP like), and anywhere in between. So with SCTP and the PR-SCTP extension as transport, you can do both the reliable and unreliable export with the same transport stack... and it's all congestion controlled. The application layer decides what reliability needed when it does the send() call. The PR-SCTP draft has completed working group review and last call in tsvwg and is supposed to be under IESG review right now. If you look at the draft, it is a very straightforward and "simple" extenstion to SCTP. regards, --peter > Hi, > > Does this mean UDP gets taken out? Or will there be 3 bindings for > different environmental requirements? [That would be my suggestion] > > o bindings over TCP for reliable communication while accomodating for some > failover mechanism if the collector becomes congested or disabled; > > o bindings of UDP for best effort (i.e. no exporter back pressure) in > configurations where exporter and collector are colocated and congestion > aware behavior is not a concern; > > o binding of PR_SCTP where congestion aware behavior and best effort are > desired. > > > -- Jeff > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] > Sent: Monday, October 06, 2003 9:34 AM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; > 'alex.audu@alcatel.com' > Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; > 'ipfix@net.doit.wisc.edu' > Subject: RE: [ipfix] STCP as a default transport not > > > > Okay... > > It seems we haven't reached a (firm) conclusion, but we need to get the > draft going and this is a big piece of it. Jeff seems to propose specifying > both (TCP and SCTP). Anyone opposes this? Or should we stick with one > protocol mapping? > > We need to start converging on this really soon. > > Thanks, > > Reinaldo > > > >> -----Original Message----- >> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [ mailto:jeff.meyer2@hp.com > ] >> Sent: Thursday, October 02, 2003 5:05 PM >> To: 'carter@qosient.com'; 'alex.audu@alcatel.com' >> Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; >> 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' >> Subject: RE: [ipfix] STCP as a default transport not >> >> >> I'd be interested in knowing what the specific aspects of >> SCTP are that the IPFIX protocol authors want to use, and how >> they do or do not conflict in some way with a parallel mapping to TCP. >> >> Taking the Diameter approach of specifying both TCP and SCTP >> would allow for the market to decide if ubiquity of >> availability or the special capabilities of SCTP are more important. >> >> -- Jeff >> >> > -----Original Message----- >> > From: Carter Bullard [ mailto:carter@qosient.com > ] >> > Sent: Thursday, October 02, 2003 1:00 PM >> > To: alex.audu@alcatel.com >> > Cc: stbryant@cisco.com; 'Reinaldo Penno'; >> > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu >> > Subject: RE: [ipfix] STCP as a default transport not >> > >> > >> > Hey Alex, >> > Did I say something wrong? I firmly believe that people adopt >> > technology when it solves problems. STCP will get around >> as its found >> > to be a real solution. But with regard to STCP and IPFIX, >> I read RFC >> > 3257, the SCTP Applicability Statement, and I don't see where IPFIX >> > fits. Benefits of SCTP over TCP are: >> > >> > multi-streams support >> > multi-homing support >> > preservation of message boundaries >> > unordered reliable message delivery >> > >> > The first three I don't see as requirements for IPFIX. >> > I actually believe the last one to be a problem for IPFIX. STCP is >> > less efficient that TCP, and so if IPFIX doesn't need any >> of these 4 >> > items, then I don't see the applicability. >> > >> > Carter >> > >> > >> > > -----Original Message----- >> > > From: Alex Audu [ mailto:alex.audu@alcatel.com > ] >> > > Sent: Thursday, October 02, 2003 2:51 PM >> > > To: carter@qosient.com >> > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; >> > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu >> > > Subject: Re: [ipfix] STCP as a default transport not >> > > >> > > >> > > Hello Carter, >> > > >> > > If it is true that SCTP hasn't been widely deployed, it >> is probably >> > > because of statements like you have made below. Look, we all know >> > > SCTP has a lot of benefits over TCP. If folks like you >> don't drive >> > > its deployement >> > > by specifying it as default transport, how will it be >> > > ubiquitous? It is a >> > > self fulfilling prophesy. >> > > >> > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, >> > > rfc 3331 and rfc 3332 just to name a few. >> > > >> > > Regards, >> > > Alex. >> > > >> > > Carter Bullard wrote: >> > > >> > > > I believe that SCTP-PR is not deployed widely enough >> > > > to be considered a default for any IETF technology. >> > > > It is not on my Linux RedHat 9.0 distribution, nor >> > > > my Mac OS-X or my Windows XP system. I don't see it >> available on >> > > > any Solaris machine that I have access to. >> > > > >> > > > What IETF technology is currently using SCTP as a >> > > > default transport? >> > > > >> > > > Carter >> > > > >> > > > > -----Original Message----- >> > > > > From: majordomo listserver >> [ mailto:majordomo@mil.doit.wisc.edu > ] >> > > > > On Behalf Of Stewart Bryant >> > > > > Sent: Thursday, October 02, 2003 12:14 PM >> > > > > To: Reinaldo Penno >> > > > > Cc: ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu >> > > > > Subject: Re: [ipfix] Ipfix Protocol open items >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > Reinaldo Penno wrote: >> > > > > >> > > > > > Hello, >> > > > > > >> > > > > > Have we zeroed in a certain transport protocol? TCP, >> > SCTP-PR or >> > > > > > something else? >> > > > > > >> > > > > > I need to write something to explain how Netflow runs over >> > > > > TCP, but it >> > > > > > seems to me somewhat of a lower priority if this is not >> > > > > going to be the >> > > > > > default protocol. We should focus on explaning how this >> > > > > should work on >> > > > > > the "choosen one". >> > > > > >> > > > > I think that perhaps the question should be put another >> > > way. There are >> > > > > WG members who propose SCTP-PR as the default, and >> SCTP-PR has >> > > > > advantage because of its better flexibility in coping >> > > with congestion. >> > > > > >> > > > > So the real question is whether there are WG members who >> > > think that >> > > > > the default should be TCP. If no group comes forward, >> > then we have >> > > > > our answer. If there is support then we need to perform >> > a detailed >> > > > > analysis of the relative merits of the two protocols. >> > > > > >> > > > > Stewart >> > > > > >> > > > > >> > > > > -- >> > > > > 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 Oct 9 15:07:13 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 PAA04270 for ; Thu, 9 Oct 2003 15:07:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7fpw-0005RQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 13:48:32 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7fpv-0005RI-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 13:48:31 -0500 Received: (qmail 73864 invoked from network); 9 Oct 2003 18:48:30 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 18:48:30 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99ImUX16226; Thu, 9 Oct 2003 14:48:30 -0400 Reply-To: From: "Carter Bullard" To: "'Peter Lei'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 14:48:28 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB3A9@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE187@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Is RTP/UDP congestion aware? If so, then how did UDP get tossed out defacto? Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Peter Lei > Sent: Thursday, October 09, 2003 1:30 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] STCP as a default transport not > > > I don't really understand this UDP thread... I thought that it > was essentially "mandated" that the transport protocol used MUST > be congestion aware. That ruled UDP out long ago, no?? Or is > that going to be debated again?! > > I didn't see anyone point this out yet, but PR-SCTP is not just > "best effort" w/congestion control... it is an extension to SCTP > such that you can do any reliability level from best effort > (UDP-like) to fully reliable (SCTP or TCP like), and anywhere in > between. > > So with SCTP and the PR-SCTP extension as transport, you can do > both the reliable and unreliable export with the same transport > stack... and it's all congestion controlled. The application > layer decides what reliability needed when it does the send() > call. > > The PR-SCTP draft has completed working group review and last > call in tsvwg and is supposed to be under IESG review right now. > If you look at the draft, it is a very straightforward and > "simple" extenstion to SCTP. > > regards, > --peter > > > Hi, > > > > Does this mean UDP gets taken out? Or will there be 3 > bindings for > > different environmental requirements? [That would be my suggestion] > > > > o bindings over TCP for reliable communication while > accomodating for some > > failover mechanism if the collector becomes congested or disabled; > > > > o bindings of UDP for best effort (i.e. no exporter back > pressure) in > > configurations where exporter and collector are colocated > and congestion > > aware behavior is not a concern; > > > > o binding of PR_SCTP where congestion aware behavior and > best effort are > > desired. > > > > > > -- Jeff > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] > > Sent: Monday, October 06, 2003 9:34 AM > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; > > 'alex.audu@alcatel.com' > > Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; > > 'ipfix@net.doit.wisc.edu' > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > Okay... > > > > It seems we haven't reached a (firm) conclusion, but we > need to get the > > draft going and this is a big piece of it. Jeff seems to > propose specifying > > both (TCP and SCTP). Anyone opposes this? Or should we > stick with one > > protocol mapping? > > > > We need to start converging on this really soon. > > > > Thanks, > > > > Reinaldo > > > > > > > >> -----Original Message----- > >> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [ > mailto:jeff.meyer2@hp.com > > ] > >> Sent: Thursday, October 02, 2003 5:05 PM > >> To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > >> Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > >> 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > >> Subject: RE: [ipfix] STCP as a default transport not > >> > >> > >> I'd be interested in knowing what the specific aspects of > >> SCTP are that the IPFIX protocol authors want to use, and how > >> they do or do not conflict in some way with a parallel > mapping to TCP. > >> > >> Taking the Diameter approach of specifying both TCP and SCTP > >> would allow for the market to decide if ubiquity of > >> availability or the special capabilities of SCTP are more > important. > >> > >> -- Jeff > >> > >> > -----Original Message----- > >> > From: Carter Bullard [ mailto:carter@qosient.com > > ] > >> > Sent: Thursday, October 02, 2003 1:00 PM > >> > To: alex.audu@alcatel.com > >> > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > >> > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > >> > Subject: RE: [ipfix] STCP as a default transport not > >> > > >> > > >> > Hey Alex, > >> > Did I say something wrong? I firmly believe that > people adopt > >> > technology when it solves problems. STCP will get around > >> as its found > >> > to be a real solution. But with regard to STCP and IPFIX, > >> I read RFC > >> > 3257, the SCTP Applicability Statement, and I don't see > where IPFIX > >> > fits. Benefits of SCTP over TCP are: > >> > > >> > multi-streams support > >> > multi-homing support > >> > preservation of message boundaries > >> > unordered reliable message delivery > >> > > >> > The first three I don't see as requirements for IPFIX. > >> > I actually believe the last one to be a problem for > IPFIX. STCP is > >> > less efficient that TCP, and so if IPFIX doesn't need any > >> of these 4 > >> > items, then I don't see the applicability. > >> > > >> > Carter > >> > > >> > > >> > > -----Original Message----- > >> > > From: Alex Audu [ mailto:alex.audu@alcatel.com > > ] > >> > > Sent: Thursday, October 02, 2003 2:51 PM > >> > > To: carter@qosient.com > >> > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > >> > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > >> > > Subject: Re: [ipfix] STCP as a default transport not > >> > > > >> > > > >> > > Hello Carter, > >> > > > >> > > If it is true that SCTP hasn't been widely deployed, it > >> is probably > >> > > because of statements like you have made below. Look, > we all know > >> > > SCTP has a lot of benefits over TCP. If folks like you > >> don't drive > >> > > its deployement > >> > > by specifying it as default transport, how will it be > >> > > ubiquitous? It is a > >> > > self fulfilling prophesy. > >> > > > >> > > For IETF protocols that recommend SCTP as defaults, > see rfc 3057, > >> > > rfc 3331 and rfc 3332 just to name a few. > >> > > > >> > > Regards, > >> > > Alex. > >> > > > >> > > Carter Bullard wrote: > >> > > > >> > > > I believe that SCTP-PR is not deployed widely enough > >> > > > to be considered a default for any IETF technology. > >> > > > It is not on my Linux RedHat 9.0 distribution, nor > >> > > > my Mac OS-X or my Windows XP system. I don't see it > >> available on > >> > > > any Solaris machine that I have access to. > >> > > > > >> > > > What IETF technology is currently using SCTP as a > >> > > > default transport? > >> > > > > >> > > > Carter > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: majordomo listserver > >> [ mailto:majordomo@mil.doit.wisc.edu > > > ] > >> > > > > On Behalf Of Stewart Bryant > >> > > > > Sent: Thursday, October 02, 2003 12:14 PM > >> > > > > To: Reinaldo Penno > >> > > > > Cc: ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu > >> > > > > Subject: Re: [ipfix] Ipfix Protocol open items > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > Reinaldo Penno wrote: > >> > > > > > >> > > > > > Hello, > >> > > > > > > >> > > > > > Have we zeroed in a certain transport protocol? TCP, > >> > SCTP-PR or > >> > > > > > something else? > >> > > > > > > >> > > > > > I need to write something to explain how Netflow > runs over > >> > > > > TCP, but it > >> > > > > > seems to me somewhat of a lower priority if this is not > >> > > > > going to be the > >> > > > > > default protocol. We should focus on explaning how this > >> > > > > should work on > >> > > > > > the "choosen one". > >> > > > > > >> > > > > I think that perhaps the question should be put another > >> > > way. There are > >> > > > > WG members who propose SCTP-PR as the default, and > >> SCTP-PR has > >> > > > > advantage because of its better flexibility in coping > >> > > with congestion. > >> > > > > > >> > > > > So the real question is whether there are WG members who > >> > > think that > >> > > > > the default should be TCP. If no group comes forward, > >> > then we have > >> > > > > our answer. If there is support then we need to perform > >> > a detailed > >> > > > > analysis of the relative merits of the two protocols. > >> > > > > > >> > > > > Stewart > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > 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 Oct 9 15:11:51 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 PAA04772 for ; Thu, 9 Oct 2003 15:11:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7ft0-0005Ym-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 13:51:42 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7fsz-0005Yd-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 13:51:41 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2003 11:59:56 -0700 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h99IpbXg027547; Thu, 9 Oct 2003 11:51:38 -0700 (PDT) Received: from cisco.com (dhcp-171-71-204-253.cisco.com [171.71.204.253]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA26291; Thu, 9 Oct 2003 11:51:37 -0700 (PDT) Message-ID: <3F85AE38.50402@cisco.com> Date: Thu, 09 Oct 2003 11:51:36 -0700 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stbryant@cisco.com CC: Maurizio Molina , "'ipfix@net.doit.wisc.edu'" Subject: Re: [ipfix] bytes and packet counters, tstamp of last report References: <3F842044.1090001@ccrle.nec.de> <3F842892.8070007@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit IMHO, we should have running (or cumulative) and delta counters as separate IE as they feed different apps and implementations. This is true for all counters. Both these are applicable when a flow is persistent or sticky in the exporter . In such a case one may wish to sent the running counter if they have enough memory to store a big counter value or may prefer to sent the delta, clearing the counts every time it is exported. -Ganesh Stewart Bryant wrote: > > > Maurizio Molina wrote: > >> Hi, >> the IPFIX info model states (sec. 6.10) that >> >> The packet count can be a running counter and is the count from the >> beginning of the flow establishment. >> >> The packet count can be a delta counter and is the count since the >> last report for this flow. >> > > I would prefer that we only supported running counters because: > > a) Supporting two types is more scope for non-interworking, and > you can always convert from one to the other at the collector. > > b) Running counters also work over an unreliable transport > whereas delta counters mandate the use of a reliable transport. > > c) Running counters are most likely what the hardware is keeping > anyway, therefore delta counters are more work and more storage > at the exporter. > > If we decide that we need both then we have to represent them > as two different information elements because the info model does > not support sub-typing. > > Stewart > >> (There's the same statement for byte counts in 6.11). >> >> To me, this doesn't clarify wheter it is both...and (2 counters) or >> either .... or (1 counter). >> >> Moreover, there is currently no room for a field containing the >> timestamp of the last report of a flow. I think that keeping this >> timestamp is helpful for many applications and the info model should >> support it. >> Regards, >> Maurizio >> >> >> >> -- >> 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 Oct 9 15:32:19 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 PAA06316 for ; Thu, 9 Oct 2003 15:32:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7g5f-00060Z-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 14:04:47 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7g5e-00060T-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 14:04:46 -0500 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id 6AEC21C01C34; Thu, 9 Oct 2003 15:04:46 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 640961C00095; Thu, 9 Oct 2003 15:04:46 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4SN0WGX7>; Thu, 9 Oct 2003 15:04:46 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960384@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Randy Bush'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 15:04:36 -0400 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 I'm sorry, perhaps I missed the well reasoned argument against the use of UDP on point to point connections? Could you direct me to that. Thanks, Jeff > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Randy Bush > Sent: Thursday, October 09, 2003 11:20 AM > To: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] STCP as a default transport not > > > it is interesting that folk seem to have enough free time on > their hands to be willing to go around the same discussion > for the Nth time. > > randy > > > -- > 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 Oct 9 15:36:11 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 PAA06490 for ; Thu, 9 Oct 2003 15:36:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7gA7-00066X-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 14:09:23 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7gA5-00066O-00; Thu, 09 Oct 2003 14:09:22 -0500 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 7CA621C00E70; Thu, 9 Oct 2003 15:09:21 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 519831C000A6; Thu, 9 Oct 2003 15:09:21 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id <42JR0BTN>; Thu, 9 Oct 2003 15:09:21 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960385@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'carter@qosient.com'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'Benoit Claise'" , stbryant@cisco.com Cc: alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 15:09:10 -0400 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'm guessing the RTP/UDP waiver is due to some expectation that RTP streams in applications such as voice and video have some upper bound on their consumption of resources. E.g. a fixed 500Kb/sec pump. In the case of Netflow, there are no guarantees of what the upper bound may be. The whole point of the discussion seems centered around the inability of the exporter to handle back pressure. So things like the RTP control protocol for reporting observed dropped rates etc. wouldn't really help. Or maybe I'm missing something. But hey, if all it takes is slapping 12 bytes on the front of the IPFIX packet to make it allowable, I'm all for it! -- Jeff > -----Original Message----- > From: Carter Bullard [mailto:carter@qosient.com] > Sent: Thursday, October 09, 2003 10:58 AM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise'; > stbryant@cisco.com > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: RE: [ipfix] STCP as a default transport not > > > I'm unhappy that the only apparent considerations are > connection oriented and unicast. I'm going to use multicast > to move flow data in some situations, and at this point, > no candidate IPFIX transport is going to make it. > > When I mentioned RTP earlier, I was not being facetious. > The IESG seems to think that RTP/UDP is not verboten, > from a congestion perspective, regardless of the speeds, > so I believe that that should be on a discussion list. > > Carter > > > > > > -----Original Message----- > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > > Sent: Thursday, October 09, 2003 12:03 PM > > To: 'Benoit Claise'; stbryant@cisco.com > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo > > Penno'; MEYER,JEFFREY D (HP-Cupertino,ex1); > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > rrs@cisco.com > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Benoit, > > > > SCTP-PR does not make me happy, nor do the previous decisions > > around reliability as it regards to billing. > > > > Dropping packets under congestion is already done by UDP, and > > UDP is ubiquitous in all OS's. > > > > Is there some challenge in defining IPFIX over TCP? It seems > > to me that this is the easier case, there are less things to map > > to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > > your proposal, i.e. force the use of SCTP-PR? > > > > As with the experience of Diameter, specifying both transports > > will enable a migration to SCTP-PR for everyone if it actually > > proves to have the values espoused and it is readily available. > > In the interim having a TCP mapping (and UDP) would address the > > requirements which I've encountered (billing issues aside). > > > > As Peter pointed out the resource constraints on the exporter > > imposed by TCP can be mitigated in the implementation. > > > > Regards, > > > > Jeff Meyer > > > > > -----Original Message----- > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > Sent: Thursday, October 09, 2003 9:15 AM > > > To: stbryant@cisco.com > > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > > > 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > > ipfix-chairs@net.doit.wisc.edu; > > > ipfix@net.doit.wisc.edu; rrs@cisco.com > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Dear all, > > > > > > There are advantages regarding the use of SCTP versus TCP > > (discussed > > > already on the list) but I think that the biggest advantage > > > of SCTP is > > > actually the extension SCTP-PR. And I'm surprised to see no > > > reactions on > > > the email below. > > > Yes, I know that the SCTP-PR is not a standard yet but I > > > think that we > > > should just take the right protocol instead of just using > > what exists > > > because it exists! > > > > > > I remember the heated discussions maybe one year ago about > > > using IPFIX > > > for billing, about high availability, etc... > > > And one of the solution that could make everybody happy > is: SCTP-PR. > > > We know that we do have some memory issues with TCP on the > > > high-end routers. > > > But, for the smaller exporter OR if you can afford/if it's > > > possible to > > > pack the exporter with the appropriate amount of memory, > > > SCTP-PR would > > > work perfectly well! > > > Now, in the majority of cases (no billing, no enough > > memory/too many > > > flow records, etc...) SCTP-PR would drop the flow records > > > excess if any, > > > which I think is the right thing to do. > > > > > > Regards, Benoit. > > > > > > > > > > > > > > I think that the interest is in using PR-SCTP as described in > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > > > > > > > rather than RFC 2960 SCTP. > > > > > > > > This claims the following benefits: > > > > > > > > > > > > 1.3 Benefits of PR-SCTP > > > > > > > > Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > > > > protocol extended as defined in this document. > > > > > > > > The following are some of the advantages for integrating > > > partially > > > > reliable data service into SCTP, i.e., benefits of PR-SCTP: > > > > > > > > 1. Some application layer protocols may benefit from > > > being able to > > > > use a single SCTP association to carry both reliable > > > content, -- > > > > such as text pages, billing and accounting > > information, setup > > > > signaling -- and unreliable content, e.g. state that > > > is highly > > > > sensitive to timeliness, where generating a new > > > packet is more > > > > advantageous than transmitting an old one [1]. > > > > > > > > 2. Partially reliable data traffic carried by PR-SCTP > > > will enjoy the > > > > same communication failure detection and protection > > > capabilities > > > > as the normal reliable SCTP data traffic does. This > > > includes the > > > > ability to: - quickly detect a failed destination > > address; - > > > > fail-over to an alternate destination address, and; > > > - be notified > > > > if the data receiver becomes unreachable. > > > > > > > > 3. In addition to providing unordered unreliable data > > > transfer as > > > > UDP does, PR-SCTP can provide ordered unreliable > > > data transfer > > > > service. > > > > > > > > 4. PR-SCTP employs the same congestion control and > congestion > > > > avoidance for all data traffic, whether reliable > > or partially > > > > reliable - this is very desirable since SCTP enforces > > > > TCP-friendliness (unlike UDP.) > > > > > > > > 5. Because of the chunk bundling function of SCTP, > > reliable and > > > > unreliable messages can be multiplexed over a > > single PR-SCTP > > > > association. Therefore, the number of IP datagrams > > > (and hence > > > > the network overhead) can be reduced versus having > > > to send these > > > > different types of data using separate protocols. > > > Additionally, > > > > this multiplexing allows for port savings versus > > > using different > > > > ports for reliable and unreliable connections. > > > > > > > > ---------- > > > > > > > > PR-SCTP has the option of being able to configure the > > > exporter to work > > > > on a > > > > best effort data export basis, rather than being > > > constrained to work on a > > > > reliable basis. > > > > > > > > We should spend some time thinking about the behaviour we > > > want in the > > > > exporter when the network is congested, perhaps due to an > > > attack. PR-SCTP > > > > gives us the option of running a best effort data > > > collection to gleen > > > > what > > > > is going on, when a TCP based exporter would otherwise > > > collapse due to > > > > backlog on the exporter. > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > > > -- > > > > 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 Oct 9 15:40:24 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 PAA06742 for ; Thu, 9 Oct 2003 15:40:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7gHX-0006U3-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 14:17:03 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7gHW-0006Tw-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 14:17:02 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7gHW-0007bd-0p; Thu, 09 Oct 2003 19:17:02 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7gFQ-000Kud-6R; Thu, 09 Oct 2003 12:14:52 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Oct 2003 12:14:51 -0700 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960384@xsun01.ptp.hp.com> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > I'm sorry, perhaps I missed the well reasoned argument against the > use of UDP on point to point connections? > > Could you direct me to that. http://ipfx.doit.wisc.edu/list/ipfix/archive/ and you may want to review RFC 2309, particularly section 4 randy -- 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 Oct 9 15:41:40 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 PAA06818 for ; Thu, 9 Oct 2003 15:41:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7gGC-0006QL-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 14:15:40 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7gGA-0006QA-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 14:15:38 -0500 Received: (qmail 89492 invoked from network); 9 Oct 2003 19:15:37 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 19:15:37 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99JFbX16249; Thu, 9 Oct 2003 15:15:37 -0400 Reply-To: From: "Carter Bullard" To: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Benoit Claise'" , Cc: , "'Reinaldo Penno'" , , , Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 15:15:34 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B0@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE192@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Jeff, Well RTP/UDP is the protocol for handling video, like SMPTE 292M and compressed HDTV (RFC 3497), so it has to be ok to go to minimally, what is it, 1.485 Gbps. Carter > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Thursday, October 09, 2003 2:09 PM > To: 'carter@qosient.com'; MEYER,JEFFREY D (HP-Cupertino,ex1); > 'Benoit Claise'; stbryant@cisco.com > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: RE: [ipfix] STCP as a default transport not > > > Hi, > > I'm guessing the RTP/UDP waiver is due to some expectation that > RTP streams in applications such as voice and video have some > upper bound on their consumption of resources. E.g. a fixed > 500Kb/sec pump. > > In the case of Netflow, there are no guarantees of what the > upper bound may be. The whole point of the discussion seems > centered around the inability of the exporter to handle back > pressure. So things like the RTP control protocol for reporting > observed dropped rates etc. wouldn't really help. Or maybe > I'm missing something. > > But hey, if all it takes is slapping 12 bytes on the front of > the IPFIX packet to make it allowable, I'm all for it! > > -- Jeff > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Thursday, October 09, 2003 10:58 AM > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise'; > > stbryant@cisco.com > > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > rrs@cisco.com > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > I'm unhappy that the only apparent considerations are > > connection oriented and unicast. I'm going to use multicast > > to move flow data in some situations, and at this point, > > no candidate IPFIX transport is going to make it. > > > > When I mentioned RTP earlier, I was not being facetious. > > The IESG seems to think that RTP/UDP is not verboten, > > from a congestion perspective, regardless of the speeds, > > so I believe that that should be on a discussion list. > > > > Carter > > > > > > > > > > > -----Original Message----- > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > [mailto:jeff.meyer2@hp.com] > > > Sent: Thursday, October 09, 2003 12:03 PM > > > To: 'Benoit Claise'; stbryant@cisco.com > > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo > > > Penno'; MEYER,JEFFREY D (HP-Cupertino,ex1); > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > > rrs@cisco.com > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > Benoit, > > > > > > SCTP-PR does not make me happy, nor do the previous decisions > > > around reliability as it regards to billing. > > > > > > Dropping packets under congestion is already done by UDP, and > > > UDP is ubiquitous in all OS's. > > > > > > Is there some challenge in defining IPFIX over TCP? It seems > > > to me that this is the easier case, there are less things to map > > > to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > > > your proposal, i.e. force the use of SCTP-PR? > > > > > > As with the experience of Diameter, specifying both transports > > > will enable a migration to SCTP-PR for everyone if it actually > > > proves to have the values espoused and it is readily available. > > > In the interim having a TCP mapping (and UDP) would address the > > > requirements which I've encountered (billing issues aside). > > > > > > As Peter pointed out the resource constraints on the exporter > > > imposed by TCP can be mitigated in the implementation. > > > > > > Regards, > > > > > > Jeff Meyer > > > > > > > -----Original Message----- > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > Sent: Thursday, October 09, 2003 9:15 AM > > > > To: stbryant@cisco.com > > > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > > > > 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > > > ipfix-chairs@net.doit.wisc.edu; > > > > ipfix@net.doit.wisc.edu; rrs@cisco.com > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > Dear all, > > > > > > > > There are advantages regarding the use of SCTP versus TCP > > > (discussed > > > > already on the list) but I think that the biggest advantage > > > > of SCTP is > > > > actually the extension SCTP-PR. And I'm surprised to see no > > > > reactions on > > > > the email below. > > > > Yes, I know that the SCTP-PR is not a standard yet but I > > > > think that we > > > > should just take the right protocol instead of just using > > > what exists > > > > because it exists! > > > > > > > > I remember the heated discussions maybe one year ago about > > > > using IPFIX > > > > for billing, about high availability, etc... > > > > And one of the solution that could make everybody happy > > is: SCTP-PR. > > > > We know that we do have some memory issues with TCP on the > > > > high-end routers. > > > > But, for the smaller exporter OR if you can afford/if it's > > > > possible to > > > > pack the exporter with the appropriate amount of memory, > > > > SCTP-PR would > > > > work perfectly well! > > > > Now, in the majority of cases (no billing, no enough > > > memory/too many > > > > flow records, etc...) SCTP-PR would drop the flow records > > > > excess if any, > > > > which I think is the right thing to do. > > > > > > > > Regards, Benoit. > > > > > > > > > > > > > > > > > > I think that the interest is in using PR-SCTP as described in > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > > > > > > > > > rather than RFC 2960 SCTP. > > > > > > > > > > This claims the following benefits: > > > > > > > > > > > > > > > 1.3 Benefits of PR-SCTP > > > > > > > > > > Hereafter, we use the notation "PR-SCTP" to refer > to the SCTP > > > > > protocol extended as defined in this document. > > > > > > > > > > The following are some of the advantages for integrating > > > > partially > > > > > reliable data service into SCTP, i.e., benefits of PR-SCTP: > > > > > > > > > > 1. Some application layer protocols may benefit from > > > > being able to > > > > > use a single SCTP association to carry both reliable > > > > content, -- > > > > > such as text pages, billing and accounting > > > information, setup > > > > > signaling -- and unreliable content, e.g. state that > > > > is highly > > > > > sensitive to timeliness, where generating a new > > > > packet is more > > > > > advantageous than transmitting an old one [1]. > > > > > > > > > > 2. Partially reliable data traffic carried by PR-SCTP > > > > will enjoy the > > > > > same communication failure detection and protection > > > > capabilities > > > > > as the normal reliable SCTP data traffic does. This > > > > includes the > > > > > ability to: - quickly detect a failed destination > > > address; - > > > > > fail-over to an alternate destination address, and; > > > > - be notified > > > > > if the data receiver becomes unreachable. > > > > > > > > > > 3. In addition to providing unordered unreliable data > > > > transfer as > > > > > UDP does, PR-SCTP can provide ordered unreliable > > > > data transfer > > > > > service. > > > > > > > > > > 4. PR-SCTP employs the same congestion control and > > congestion > > > > > avoidance for all data traffic, whether reliable > > > or partially > > > > > reliable - this is very desirable since SCTP enforces > > > > > TCP-friendliness (unlike UDP.) > > > > > > > > > > 5. Because of the chunk bundling function of SCTP, > > > reliable and > > > > > unreliable messages can be multiplexed over a > > > single PR-SCTP > > > > > association. Therefore, the number of IP datagrams > > > > (and hence > > > > > the network overhead) can be reduced versus having > > > > to send these > > > > > different types of data using separate protocols. > > > > Additionally, > > > > > this multiplexing allows for port savings versus > > > > using different > > > > > ports for reliable and unreliable connections. > > > > > > > > > > ---------- > > > > > > > > > > PR-SCTP has the option of being able to configure the > > > > exporter to work > > > > > on a > > > > > best effort data export basis, rather than being > > > > constrained to work on a > > > > > reliable basis. > > > > > > > > > > We should spend some time thinking about the behaviour we > > > > want in the > > > > > exporter when the network is congested, perhaps due to an > > > > attack. PR-SCTP > > > > > gives us the option of running a best effort data > > > > collection to gleen > > > > > what > > > > > is going on, when a TCP based exporter would otherwise > > > > collapse due to > > > > > backlog on the exporter. > > > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > 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 Oct 9 15:52: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 PAA07572 for ; Thu, 9 Oct 2003 15:52:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7gT2-0006jv-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 14:28:56 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7gT1-0006jn-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 14:28:55 -0500 Received: (qmail 96617 invoked from network); 9 Oct 2003 19:28:54 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 19:28:54 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99JSsX16254; Thu, 9 Oct 2003 15:28:54 -0400 Reply-To: From: "Carter Bullard" To: "'Randy Bush'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 15:28:51 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB3AB@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE197@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver You know, I've read RFC 2309 about 10 times now, and nowhere does it say that you shouldn't use UDP. I think RFC 3497, section 9 does a good job with congestion control and UDP. Is the A Mankin on the author list of 3497 related to Allison Mankin? Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Randy Bush > Sent: Thursday, October 09, 2003 2:15 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] STCP as a default transport not > > > > I'm sorry, perhaps I missed the well reasoned argument against the > > use of UDP on point to point connections? > > > > Could you direct me to that. > http://ipfx.doit.wisc.edu/list/ipfix/archive/ and you may want to review RFC 2309, particularly section 4 randy -- 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 Oct 9 15:55:19 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 PAA07718 for ; Thu, 9 Oct 2003 15:55:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7gba-00079W-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 14:37:46 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7gbY-00078o-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 14:37:44 -0500 Received: (qmail 1440 invoked from network); 9 Oct 2003 19:37:43 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 19:37:43 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99JbhX16259; Thu, 9 Oct 2003 15:37:43 -0400 Reply-To: From: "Carter Bullard" To: "'Randy Bush'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 15:37:40 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B1@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE197@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver And my recollection on the mailing list, and if anyone is interested, the brief discussion started on Oct 04, 2001, was everyone was pretty much amazed that the charter only mentioned TCP or SCTP, and everyone kept asking why not UDP? There was no consensus, just simple dictation from above. Did anyone very really hear an IESG member say that UDP is verboten? There have been a number of RFC's out in 2003 that use UDP. What's the real story here? Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Randy Bush > Sent: Thursday, October 09, 2003 2:15 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] STCP as a default transport not > > > > I'm sorry, perhaps I missed the well reasoned argument against the > > use of UDP on point to point connections? > > > > Could you direct me to that. > http://ipfx.doit.wisc.edu/list/ipfix/archive/ and you may want to review RFC 2309, particularly section 4 randy -- 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 Oct 9 17:58: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 RAA12646 for ; Thu, 9 Oct 2003 17:58:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7if2-0003Qj-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 16:49:28 -0500 Received: from mx1.narus.com ([208.253.219.210]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7if1-0003Qc-00; Thu, 09 Oct 2003 16:49:27 -0500 Received: from franklin.narus.com (franklin.narus.com [192.168.7.140]) by mx1.narus.com (8.12.8/8.12.8) with ESMTP id h99Ln20F012560; Thu, 9 Oct 2003 14:49:02 -0700 Received: by franklin.narus.com with Internet Mail Service (5.5.2655.55) id ; Thu, 9 Oct 2003 14:49:02 -0700 Message-ID: <580E532D9F7A9B4BAE8A130848E0DDA702084086@franklin.narus.com> From: Stas Khirman To: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , "'carter@qosient.com'" , "'Benoit Claise'" , stbryant@cisco.com Cc: alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 14:48:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) Precedence: bulk Sender: majordomo listserver Gentlemen, Citing my extensive RTP/RTCP experience, I can't resist not to give my 2c to your heated discussion. Sorry...... RTP/RTCP is designed for multimedia streaming applications, where timely delivery of the information is significantly more important then its completeness. Indeed, due human perception capabilities, you can lost a few percent of voice packet without noticing any quality degradation. Video information is even more "lost-sustainable". On the other hand, late multimedia packet is not different from the lost one . As a result, it's assumed than multimedia streaming application will NOT resend lost frame - anyway, it will arrive to late (partial exception for prerecorded video-on-demand applications with a big sender-based buffer). Initially, RTP (data) channel is used to send a multimedia frames ( packets) with some predefined rate. RTCP (control or feedback) channel is used to inform sender about quality of information delivery. Certainly, it includes lost packet ratio, but often inter-packet-delivery jitter is considered as a more sensitive parameter. RTCP information may be used ( or have to be used, if you expect quality) to "adapt" sender application, often by scaling quality/bandwidth codacs parameters ( or replacing codacs on the fly). RTP/RTCP itself has neither rate control, nor congestion avoidance and retransmission functionalities build-in - all these features are left for an application. There are a few interesting RTP extension to support a [semi-]reliable multicast, but I didn't see anything working outside university projects ( my info may be 2-3 years outdated - any corrections are welcome). Considering said above, I do NOT recommend to use RTP/RTCP as a basis for IPFIX - its belongs to totally different domain with [often] different requirements and basic assumptions. regards Stas Khirman > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Thursday, October 09, 2003 12:09 PM > To: 'carter@qosient.com'; MEYER,JEFFREY D (HP-Cupertino,ex1); 'Benoit > Claise'; stbryant@cisco.com > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: RE: [ipfix] STCP as a default transport not > > > Hi, > > I'm guessing the RTP/UDP waiver is due to some expectation that > RTP streams in applications such as voice and video have some > upper bound on their consumption of resources. E.g. a fixed > 500Kb/sec pump. > > In the case of Netflow, there are no guarantees of what the > upper bound may be. The whole point of the discussion seems > centered around the inability of the exporter to handle back > pressure. So things like the RTP control protocol for reporting > observed dropped rates etc. wouldn't really help. Or maybe > I'm missing something. > > But hey, if all it takes is slapping 12 bytes on the front of > the IPFIX packet to make it allowable, I'm all for it! > > -- Jeff > > > -----Original Message----- > > From: Carter Bullard [mailto:carter@qosient.com] > > Sent: Thursday, October 09, 2003 10:58 AM > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise'; > > stbryant@cisco.com > > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > rrs@cisco.com > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > I'm unhappy that the only apparent considerations are > > connection oriented and unicast. I'm going to use multicast > > to move flow data in some situations, and at this point, > > no candidate IPFIX transport is going to make it. > > > > When I mentioned RTP earlier, I was not being facetious. > > The IESG seems to think that RTP/UDP is not verboten, > > from a congestion perspective, regardless of the speeds, > > so I believe that that should be on a discussion list. > > > > Carter > > > > > > > > > > > -----Original Message----- > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > [mailto:jeff.meyer2@hp.com] > > > Sent: Thursday, October 09, 2003 12:03 PM > > > To: 'Benoit Claise'; stbryant@cisco.com > > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo > > > Penno'; MEYER,JEFFREY D (HP-Cupertino,ex1); > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > > rrs@cisco.com > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > Benoit, > > > > > > SCTP-PR does not make me happy, nor do the previous decisions > > > around reliability as it regards to billing. > > > > > > Dropping packets under congestion is already done by UDP, and > > > UDP is ubiquitous in all OS's. > > > > > > Is there some challenge in defining IPFIX over TCP? It seems > > > to me that this is the easier case, there are less things to map > > > to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > > > your proposal, i.e. force the use of SCTP-PR? > > > > > > As with the experience of Diameter, specifying both transports > > > will enable a migration to SCTP-PR for everyone if it actually > > > proves to have the values espoused and it is readily available. > > > In the interim having a TCP mapping (and UDP) would address the > > > requirements which I've encountered (billing issues aside). > > > > > > As Peter pointed out the resource constraints on the exporter > > > imposed by TCP can be mitigated in the implementation. > > > > > > Regards, > > > > > > Jeff Meyer > > > > > > > -----Original Message----- > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > Sent: Thursday, October 09, 2003 9:15 AM > > > > To: stbryant@cisco.com > > > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > > > > 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > > > ipfix-chairs@net.doit.wisc.edu; > > > > ipfix@net.doit.wisc.edu; rrs@cisco.com > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > Dear all, > > > > > > > > There are advantages regarding the use of SCTP versus TCP > > > (discussed > > > > already on the list) but I think that the biggest advantage > > > > of SCTP is > > > > actually the extension SCTP-PR. And I'm surprised to see no > > > > reactions on > > > > the email below. > > > > Yes, I know that the SCTP-PR is not a standard yet but I > > > > think that we > > > > should just take the right protocol instead of just using > > > what exists > > > > because it exists! > > > > > > > > I remember the heated discussions maybe one year ago about > > > > using IPFIX > > > > for billing, about high availability, etc... > > > > And one of the solution that could make everybody happy > > is: SCTP-PR. > > > > We know that we do have some memory issues with TCP on the > > > > high-end routers. > > > > But, for the smaller exporter OR if you can afford/if it's > > > > possible to > > > > pack the exporter with the appropriate amount of memory, > > > > SCTP-PR would > > > > work perfectly well! > > > > Now, in the majority of cases (no billing, no enough > > > memory/too many > > > > flow records, etc...) SCTP-PR would drop the flow records > > > > excess if any, > > > > which I think is the right thing to do. > > > > > > > > Regards, Benoit. > > > > > > > > > > > > > > > > > > I think that the interest is in using PR-SCTP as described in > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > > > > > > > > > rather than RFC 2960 SCTP. > > > > > > > > > > This claims the following benefits: > > > > > > > > > > > > > > > 1.3 Benefits of PR-SCTP > > > > > > > > > > Hereafter, we use the notation "PR-SCTP" to refer > to the SCTP > > > > > protocol extended as defined in this document. > > > > > > > > > > The following are some of the advantages for integrating > > > > partially > > > > > reliable data service into SCTP, i.e., benefits of PR-SCTP: > > > > > > > > > > 1. Some application layer protocols may benefit from > > > > being able to > > > > > use a single SCTP association to carry both reliable > > > > content, -- > > > > > such as text pages, billing and accounting > > > information, setup > > > > > signaling -- and unreliable content, e.g. state that > > > > is highly > > > > > sensitive to timeliness, where generating a new > > > > packet is more > > > > > advantageous than transmitting an old one [1]. > > > > > > > > > > 2. Partially reliable data traffic carried by PR-SCTP > > > > will enjoy the > > > > > same communication failure detection and protection > > > > capabilities > > > > > as the normal reliable SCTP data traffic does. This > > > > includes the > > > > > ability to: - quickly detect a failed destination > > > address; - > > > > > fail-over to an alternate destination address, and; > > > > - be notified > > > > > if the data receiver becomes unreachable. > > > > > > > > > > 3. In addition to providing unordered unreliable data > > > > transfer as > > > > > UDP does, PR-SCTP can provide ordered unreliable > > > > data transfer > > > > > service. > > > > > > > > > > 4. PR-SCTP employs the same congestion control and > > congestion > > > > > avoidance for all data traffic, whether reliable > > > or partially > > > > > reliable - this is very desirable since SCTP enforces > > > > > TCP-friendliness (unlike UDP.) > > > > > > > > > > 5. Because of the chunk bundling function of SCTP, > > > reliable and > > > > > unreliable messages can be multiplexed over a > > > single PR-SCTP > > > > > association. Therefore, the number of IP datagrams > > > > (and hence > > > > > the network overhead) can be reduced versus having > > > > to send these > > > > > different types of data using separate protocols. > > > > Additionally, > > > > > this multiplexing allows for port savings versus > > > > using different > > > > > ports for reliable and unreliable connections. > > > > > > > > > > ---------- > > > > > > > > > > PR-SCTP has the option of being able to configure the > > > > exporter to work > > > > > on a > > > > > best effort data export basis, rather than being > > > > constrained to work on a > > > > > reliable basis. > > > > > > > > > > We should spend some time thinking about the behaviour we > > > > want in the > > > > > exporter when the network is congested, perhaps due to an > > > > attack. PR-SCTP > > > > > gives us the option of running a best effort data > > > > collection to gleen > > > > > what > > > > > is going on, when a TCP based exporter would otherwise > > > > collapse due to > > > > > backlog on the exporter. > > > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > 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 Oct 9 18:00: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 SAA12707 for ; Thu, 9 Oct 2003 18:00:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7iiM-0003Ua-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 16:52:54 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7iiL-0003UV-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 16:52:53 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h99LqjEE000955; Fri, 10 Oct 2003 10:52:50 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BA6A333F5F; Fri, 10 Oct 2003 10:51:31 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16500-01; Fri, 10 Oct 2003 10:51:31 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 996E633F5D; Fri, 10 Oct 2003 10:51:31 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h99Lqi224718; Fri, 10 Oct 2003 10:52:44 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Fri, 10 Oct 2003 10:52:44 +1300 Message-ID: <1065736364.4336dedb83483@hotlava.auckland.ac.nz> Date: Fri, 10 Oct 2003 10:52:44 +1300 From: Nevil Brownlee To: carter@qosient.com Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6B1@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6B1@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 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Carter: > And my recollection on the mailing list, and if anyone is > interested, the brief discussion started on Oct 04, 2001, > was everyone was pretty much amazed that the charter only > mentioned TCP or SCTP, and everyone kept asking why not UDP? > There was no consensus, just simple dictation from above. > > Did anyone very really hear an IESG member say that UDP > is verboten? There have been a number of RFC's out in > 2003 that use UDP. What's the real story here? You're right about that date. The story is that a year or so before before the IPFIX WG got started the IAB were discussing congestion management. That discussion moved to at least one IESG open plenary (I'm sure I was there, but I can't remember which meeting), and the consensus from that was that "new standards-track protocols MUST be congestion-aware." That was written up and published as RFC 2309, which is a very good document about congestion management. The IPFIX charter says IPFIX must "run over IETF approved congestion-aware transport protocol .." and lists TCP and SCTP as examples. UDP on its own is not congestion-aware, we spent more time than I care to remember thrashing that on the mailing list two years ago, let's please not go down that rat-hole again. However, as you pointed out, RTP/UDP is OK, because the RTP part of it provides a limit on a session's data rate. That's fine for streaming audio and video, but IPFIX traffic may well be a lot burstier than that, so I think you need to consider carefully if you're proposing RTP/UDF as an IPFIX transport protocol. For the IPFIX WG, the position is that the protocol draft has sections in it to describe how SCTP and TCP can be used to carry IPFIX, and we're happy to add sections for any other congestion-aware transport. We need people to write text for those sections, now! The WG issue which we opened at the Vienna meeting was "what should we specify as a *default* transport for IPFIX?" We need clear, *technical* arguments for each of the likely protocols, so as to reach WG consensus on this real soon now. 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 Oct 9 19:15: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 TAA16459 for ; Thu, 9 Oct 2003 19:15:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7jpt-0005nK-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 18:04:45 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7jps-0005nE-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 18:04:44 -0500 Received: (qmail 2492 invoked from network); 9 Oct 2003 23:04:43 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 23:04:43 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99N4hX16352; Thu, 9 Oct 2003 19:04:43 -0400 Reply-To: From: "Carter Bullard" To: "'Nevil Brownlee'" Cc: Subject: RE: [ipfix] Congestion management Date: Thu, 9 Oct 2003 19:04:39 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B3@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE1C2@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Nevil, Well its pretty clear to me that there is a huge hole in the transport offerings for IPFIX. Connection-oriented, unicast only transport schemes are pretty limiting, not to mention the huge overhead that the probes have to incur to support them. Not an issue for a simple 10K-100K record per second IP flow monitor, but get much faster and it gets expensive. When you're dealing with 1M+ records per second, the concepts of record loss detection and selective retransmission are just not practical. With these types of monitors, if there is packet loss, there really isn't any way that the probes can slow down, so, like RFC 3497, the concept would have to be to have some type of feedback signal so the probe can stop. So RTP/RTCP sounds good. I'd rather IPFIX send the message, but the concept of IPFIX being congestion aware itself seems to have dropped through a fissure somewhere. I'm not advocating RTP/UDP because I think its the best solution, but since its become more of a political issue than an engineering issue, then one might as well take the lead from the AD's themselves. If the transport area director is the author of a modern connection-less mechanism that supports 1.4 Gbps streams over UDP, surely the same approach should satisfy the transport area directors concerns for high speed IPFIX congestion management. Carter > -----Original Message----- > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Sent: Thursday, October 09, 2003 4:53 PM > To: carter@qosient.com > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] Congestion management > > > Hi Carter: > > > And my recollection on the mailing list, and if anyone is > > interested, the brief discussion started on Oct 04, 2001, > > was everyone was pretty much amazed that the charter only > > mentioned TCP or SCTP, and everyone kept asking why not UDP? > > There was no consensus, just simple dictation from above. > > > > Did anyone very really hear an IESG member say that UDP > > is verboten? There have been a number of RFC's out in > > 2003 that use UDP. What's the real story here? > > You're right about that date. The story is that a year or so before > before the IPFIX WG got started the IAB were discussing congestion > management. That discussion moved to at least one IESG open plenary > (I'm sure I was there, but I can't remember which meeting), and the > consensus from that was that "new standards-track protocols MUST be > congestion-aware." That was written up and published as RFC 2309, > which is a very good document about congestion management. > > The IPFIX charter says IPFIX must "run over IETF approved > congestion-aware > transport protocol .." and lists TCP and SCTP as examples. > > UDP on its own is not congestion-aware, we spent more time than I care > to remember thrashing that on the mailing list two years ago, > let's please > not go down that rat-hole again. > > However, as you pointed out, RTP/UDP is OK, because the RTP part of it > provides a limit on a session's data rate. That's fine for streaming > audio and video, but IPFIX traffic may well be a lot burstier > than that, > so I think you need to consider carefully if you're proposing RTP/UDF > as an IPFIX transport protocol. > > For the IPFIX WG, the position is that the protocol draft has sections > in it to describe how SCTP and TCP can be used to carry > IPFIX, and we're > happy to add sections for any other congestion-aware transport. > We need people to write text for those sections, now! > > The WG issue which we opened at the Vienna meeting was "what should we > specify as a *default* transport for IPFIX?" > We need clear, *technical* arguments for each of the likely protocols, > so as to reach WG consensus on this real soon now. > > 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 Oct 9 19:54:19 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 TAA17719 for ; Thu, 9 Oct 2003 19:54:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7kNk-0006pv-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 18:39:44 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7kNj-0006pe-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 18:39:43 -0500 Received: (qmail 20234 invoked from network); 9 Oct 2003 23:39:19 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 23:39:19 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99NdJX16368; Thu, 9 Oct 2003 19:39:19 -0400 Reply-To: From: "Carter Bullard" To: "'Stas Khirman'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Benoit Claise'" , Cc: , "'Reinaldo Penno'" , , , Subject: RE: [ipfix] STCP as a default transport not Date: Thu, 9 Oct 2003 19:39:15 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B4@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE1C1@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Stas, I'm not advocating RTP/UDP as the basis of IPFIX, just one of the transports available. The reasoning is two fold. The first, many IP flow monitors today use simple UDP. RTP/RTCP would be a simple addition for these devices in order for them to get some congestion awareness, which is all the IESG is asking for. I can't think of any other IETF standard protocol more perfect for these applications, since the modification for these devices would/could be trivial compared to converting to a connection-oriented strategy. The second, when building very high speed flow monitors to support a specific class of network monitoring applications, the transport goals are not any different than those of streaming video. No need to go back, we do want to know if there is loss and if there is toooo much loss maybe do something drastic, and we'd like the other side to be a bit adaptive, but basically just keep it coming. RTP/RTCP seems ideal for that. When RTP was in its infancy, the discussion was that it was the go to protocol if you wanted something in-between TCP and UDP. Signaling and control are out-of-band so you get all the benefits of a pure connection-less protocol, but you can get feedback if you want it. Did that change somewhere along the way? Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Stas Khirman > Sent: Thursday, October 09, 2003 4:49 PM > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > 'carter@qosient.com'; 'Benoit Claise'; stbryant@cisco.com > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: RE: [ipfix] STCP as a default transport not > > > Gentlemen, > > Citing my extensive RTP/RTCP experience, I can't resist not > to give my 2c to > your heated discussion. Sorry...... > > RTP/RTCP is designed for multimedia streaming applications, > where timely > delivery of the information is significantly more important then its > completeness. Indeed, due human perception capabilities, you > can lost a few > percent of voice packet without noticing any quality > degradation. Video > information is even more "lost-sustainable". On the other hand, late > multimedia packet is not different from the lost one . As a > result, it's > assumed than multimedia streaming application will NOT resend > lost frame - > anyway, it will arrive to late (partial exception for prerecorded > video-on-demand applications with a big sender-based buffer). > > Initially, RTP (data) channel is used to send a multimedia > frames ( packets) > with some predefined rate. RTCP (control or feedback) channel > is used to > inform sender about quality of information delivery. > Certainly, it includes > lost packet ratio, but often inter-packet-delivery jitter is > considered as a > more sensitive parameter. RTCP information may be used ( or > have to be used, > if you expect quality) to "adapt" sender application, often by scaling > quality/bandwidth codacs parameters ( or replacing codacs on the fly). > > RTP/RTCP itself has neither rate control, nor congestion avoidance and > retransmission functionalities build-in - all these features > are left for an > application. > > There are a few interesting RTP extension to support a [semi-]reliable > multicast, but I didn't see anything working outside > university projects ( > my info may be 2-3 years outdated - any corrections are welcome). > > Considering said above, I do NOT recommend to use RTP/RTCP as > a basis for > IPFIX - its belongs to totally different domain with [often] different > requirements and basic assumptions. > > regards > Stas Khirman > > > > > > -----Original Message----- > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > > Sent: Thursday, October 09, 2003 12:09 PM > > To: 'carter@qosient.com'; MEYER,JEFFREY D > (HP-Cupertino,ex1); 'Benoit > > Claise'; stbryant@cisco.com > > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > rrs@cisco.com > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Hi, > > > > I'm guessing the RTP/UDP waiver is due to some expectation that > > RTP streams in applications such as voice and video have some > > upper bound on their consumption of resources. E.g. a fixed > > 500Kb/sec pump. > > > > In the case of Netflow, there are no guarantees of what the > > upper bound may be. The whole point of the discussion seems > > centered around the inability of the exporter to handle back > > pressure. So things like the RTP control protocol for reporting > > observed dropped rates etc. wouldn't really help. Or maybe > > I'm missing something. > > > > But hey, if all it takes is slapping 12 bytes on the front of > > the IPFIX packet to make it allowable, I'm all for it! > > > > -- Jeff > > > > > -----Original Message----- > > > From: Carter Bullard [mailto:carter@qosient.com] > > > Sent: Thursday, October 09, 2003 10:58 AM > > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise'; > > > stbryant@cisco.com > > > Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > > rrs@cisco.com > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > I'm unhappy that the only apparent considerations are > > > connection oriented and unicast. I'm going to use multicast > > > to move flow data in some situations, and at this point, > > > no candidate IPFIX transport is going to make it. > > > > > > When I mentioned RTP earlier, I was not being facetious. > > > The IESG seems to think that RTP/UDP is not verboten, > > > from a congestion perspective, regardless of the speeds, > > > so I believe that that should be on a discussion list. > > > > > > Carter > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > > [mailto:jeff.meyer2@hp.com] > > > > Sent: Thursday, October 09, 2003 12:03 PM > > > > To: 'Benoit Claise'; stbryant@cisco.com > > > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo > > > > Penno'; MEYER,JEFFREY D (HP-Cupertino,ex1); > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > > > rrs@cisco.com > > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > > > > Benoit, > > > > > > > > SCTP-PR does not make me happy, nor do the previous decisions > > > > around reliability as it regards to billing. > > > > > > > > Dropping packets under congestion is already done by UDP, and > > > > UDP is ubiquitous in all OS's. > > > > > > > > Is there some challenge in defining IPFIX over TCP? It seems > > > > to me that this is the easier case, there are less things to map > > > > to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > > > > your proposal, i.e. force the use of SCTP-PR? > > > > > > > > As with the experience of Diameter, specifying both transports > > > > will enable a migration to SCTP-PR for everyone if it actually > > > > proves to have the values espoused and it is readily available. > > > > In the interim having a TCP mapping (and UDP) would address the > > > > requirements which I've encountered (billing issues aside). > > > > > > > > As Peter pointed out the resource constraints on the exporter > > > > imposed by TCP can be mitigated in the implementation. > > > > > > > > Regards, > > > > > > > > Jeff Meyer > > > > > > > > > -----Original Message----- > > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > > Sent: Thursday, October 09, 2003 9:15 AM > > > > > To: stbryant@cisco.com > > > > > Cc: alex.audu@alcatel.com; carter@qosient.com; > 'Reinaldo Penno'; > > > > > 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > > > > ipfix-chairs@net.doit.wisc.edu; > > > > > ipfix@net.doit.wisc.edu; rrs@cisco.com > > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > There are advantages regarding the use of SCTP versus TCP > > > > (discussed > > > > > already on the list) but I think that the biggest advantage > > > > > of SCTP is > > > > > actually the extension SCTP-PR. And I'm surprised to see no > > > > > reactions on > > > > > the email below. > > > > > Yes, I know that the SCTP-PR is not a standard yet but I > > > > > think that we > > > > > should just take the right protocol instead of just using > > > > what exists > > > > > because it exists! > > > > > > > > > > I remember the heated discussions maybe one year ago about > > > > > using IPFIX > > > > > for billing, about high availability, etc... > > > > > And one of the solution that could make everybody happy > > > is: SCTP-PR. > > > > > We know that we do have some memory issues with TCP on the > > > > > high-end routers. > > > > > But, for the smaller exporter OR if you can afford/if it's > > > > > possible to > > > > > pack the exporter with the appropriate amount of memory, > > > > > SCTP-PR would > > > > > work perfectly well! > > > > > Now, in the majority of cases (no billing, no enough > > > > memory/too many > > > > > flow records, etc...) SCTP-PR would drop the flow records > > > > > excess if any, > > > > > which I think is the right thing to do. > > > > > > > > > > Regards, Benoit. > > > > > > > > > > > > > > > > > > > > > > I think that the interest is in using PR-SCTP as > described in > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > > > > > > > > > > > rather than RFC 2960 SCTP. > > > > > > > > > > > > This claims the following benefits: > > > > > > > > > > > > > > > > > > 1.3 Benefits of PR-SCTP > > > > > > > > > > > > Hereafter, we use the notation "PR-SCTP" to refer > > to the SCTP > > > > > > protocol extended as defined in this document. > > > > > > > > > > > > The following are some of the advantages for integrating > > > > > partially > > > > > > reliable data service into SCTP, i.e., benefits > of PR-SCTP: > > > > > > > > > > > > 1. Some application layer protocols may benefit from > > > > > being able to > > > > > > use a single SCTP association to carry both reliable > > > > > content, -- > > > > > > such as text pages, billing and accounting > > > > information, setup > > > > > > signaling -- and unreliable content, e.g. state that > > > > > is highly > > > > > > sensitive to timeliness, where generating a new > > > > > packet is more > > > > > > advantageous than transmitting an old one [1]. > > > > > > > > > > > > 2. Partially reliable data traffic carried by PR-SCTP > > > > > will enjoy the > > > > > > same communication failure detection and protection > > > > > capabilities > > > > > > as the normal reliable SCTP data traffic does. This > > > > > includes the > > > > > > ability to: - quickly detect a failed destination > > > > address; - > > > > > > fail-over to an alternate destination address, and; > > > > > - be notified > > > > > > if the data receiver becomes unreachable. > > > > > > > > > > > > 3. In addition to providing unordered unreliable data > > > > > transfer as > > > > > > UDP does, PR-SCTP can provide ordered unreliable > > > > > data transfer > > > > > > service. > > > > > > > > > > > > 4. PR-SCTP employs the same congestion control and > > > congestion > > > > > > avoidance for all data traffic, whether reliable > > > > or partially > > > > > > reliable - this is very desirable since > SCTP enforces > > > > > > TCP-friendliness (unlike UDP.) > > > > > > > > > > > > 5. Because of the chunk bundling function of SCTP, > > > > reliable and > > > > > > unreliable messages can be multiplexed over a > > > > single PR-SCTP > > > > > > association. Therefore, the number of IP datagrams > > > > > (and hence > > > > > > the network overhead) can be reduced versus having > > > > > to send these > > > > > > different types of data using separate protocols. > > > > > Additionally, > > > > > > this multiplexing allows for port savings versus > > > > > using different > > > > > > ports for reliable and unreliable connections. > > > > > > > > > > > > ---------- > > > > > > > > > > > > PR-SCTP has the option of being able to configure the > > > > > exporter to work > > > > > > on a > > > > > > best effort data export basis, rather than being > > > > > constrained to work on a > > > > > > reliable basis. > > > > > > > > > > > > We should spend some time thinking about the behaviour we > > > > > want in the > > > > > > exporter when the network is congested, perhaps due to an > > > > > attack. PR-SCTP > > > > > > gives us the option of running a best effort data > > > > > collection to gleen > > > > > > what > > > > > > is going on, when a TCP based exporter would otherwise > > > > > collapse due to > > > > > > backlog on the exporter. > > > > > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > 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 Oct 9 20:44: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 UAA19155 for ; Thu, 9 Oct 2003 20:44:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7lHM-0000i7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 19:37:12 -0500 Received: from login.caida.org ([192.172.226.78]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7lHL-0000i0-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 19:37:11 -0500 Received: from login.caida.org (localhost [127.0.0.1]) by login.caida.org (8.12.10/8.12.10) with ESMTP id h9A0b8rb068127 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Oct 2003 17:37:08 -0700 (PDT) Received: (from dmoore@localhost) by login.caida.org (8.12.10/8.12.10/Submit) id h9A0b7Ir068126; Thu, 9 Oct 2003 17:37:07 -0700 (PDT) Date: Thu, 9 Oct 2003 17:37:07 -0700 From: David Moore To: Carter Bullard Cc: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Congestion management Message-ID: <20031009173707.M21695@login.caida.org> References: <5C8959A16A71B449AE793CF52FBBED661CE1C2@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607A6B3@ptah.newyork.qosient.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6B3@ptah.newyork.qosient.com> User-Agent: Mutt/1.3.23i Precedence: bulk Sender: majordomo listserver On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: > When you're dealing with 1M+ records per second, the > concepts of record loss detection and selective retransmission > are just not practical. With these types of monitors, if > there is packet loss, there really isn't any way that the probes > can slow down, so, like RFC 3497, the concept would have to be > to have some type of feedback signal so the probe can stop. > So RTP/RTCP sounds good. I'd rather IPFIX send the message, > but the concept of IPFIX being congestion aware itself seems > to have dropped through a fissure somewhere. With SCTP-PR, afaik, allows you to tune whether you want any particular pieces of sent data to be reliable or unreliable. By setting every piece to be unreliable, then you have UDP in terms of reliability. However, SCTP-PR has the feedback signal which already provides TCP-friendly congestion avoidance. Is there some performance cost to SCTP-PR when all data is marked unreliable that you feel is too high, to require building a different feedback mechanism on top of UDP to also have congestion avoidance? I understand the desire for a UDP transport which has no congestion avoidance. But if the goal is something UDP-like (unreliable) but which does have congestion avoidance, IPFIX should use something already a standard (or about to be a standard) rather than inventing its own. -- david -- 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 Oct 9 22:23:24 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 WAA21572 for ; Thu, 9 Oct 2003 22:23:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7mo3-0003YV-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 21:15:03 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7mo2-0003YN-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 21:15:02 -0500 Received: (qmail 80086 invoked from network); 10 Oct 2003 02:15:01 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 10 Oct 2003 02:15:01 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9A2F1X16434; Thu, 9 Oct 2003 22:15:01 -0400 Reply-To: From: "Carter Bullard" To: "'David Moore'" Cc: "'Nevil Brownlee'" , Subject: RE: [ipfix] Congestion management Date: Thu, 9 Oct 2003 22:14:57 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B5@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE1D2@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey David, SCTP-PR is partial reliable, not unreliable. You can't seem to turn off the failure detection and protection capabilities of normal reliable SCTP, nor can you turn off the congestion avoidance logic of SCTP, so it is definitely more complex and more expensive compared to say RTP/UDP, and probably TCP. The key is to find a transition technology for the 1000's of existing IP flow monitors that are purely UDP based today. A simple transitional technology should be appropriate, and I think RTP/UDP is a good one, especially since the IESG has historically accepted it as passing the congestion awareness criteria. I'm personally concerned that the only mentioned transport candidates are connection-oriented and unicast only. There are serious advantages to connection-less transports and multicast support, and I'm interested in ensuring that IPFIX can explore those advantages. Neither SCTP-PR or TCP can support multicast, so I'm an advocate of a three transport model. But Nevil is right, the real issue is what should be the default transport for IPFIX, and here it seems to me that SCTP-PR should NOT be the default, although there is enough consensus for it to be a supported transport. TCP seems to be the only real candidate for the default, simply from an interoperability standpoint. If you've only got one shot at attaching to an IP flow probe, are you going to use SCTP-PR or TCP, if the probe could support either, but not both? I think TCP will be the higher probability choice, which would make it the default, by default. Carter > -----Original Message----- > From: David Moore [mailto:dmoore@caida.org] > Sent: Thursday, October 09, 2003 7:37 PM > To: Carter Bullard > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Congestion management > > > On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: > > When you're dealing with 1M+ records per second, the > > concepts of record loss detection and selective retransmission > > are just not practical. With these types of monitors, if > > there is packet loss, there really isn't any way that the probes > > can slow down, so, like RFC 3497, the concept would have to be > > to have some type of feedback signal so the probe can stop. > > So RTP/RTCP sounds good. I'd rather IPFIX send the message, > > but the concept of IPFIX being congestion aware itself seems > > to have dropped through a fissure somewhere. > > With SCTP-PR, afaik, allows you to tune whether you want any > particular pieces of sent data to be reliable or unreliable. By > setting every piece to be unreliable, then you have UDP in terms > of reliability. However, SCTP-PR has the feedback signal which > already provides TCP-friendly congestion avoidance. > > Is there some performance cost to SCTP-PR when all data is marked > unreliable that you feel is too high, to require building a different > feedback mechanism on top of UDP to also have congestion avoidance? > > I understand the desire for a UDP transport which has no congestion > avoidance. But if the goal is something UDP-like (unreliable) but > which does have congestion avoidance, IPFIX should use something > already a standard (or about to be a standard) rather than inventing > its own. > > > -- david > -- 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 Oct 10 00:24: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 AAA24505 for ; Fri, 10 Oct 2003 00:24:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7oXu-0006n9-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 23:06:30 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7oXt-0006n4-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 23:06:29 -0500 Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by comcast.net (rwcrmhc12) with SMTP id <2003101004062401400okbvue>; Fri, 10 Oct 2003 04:06:26 +0000 Message-ID: <3F86303F.7090900@ieee.org> Date: Thu, 09 Oct 2003 23:06:23 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu CC: carter@qosient.com, "'David Moore'" , "'Nevil Brownlee'" Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6B5@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6B5@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: > Hey David, > SCTP-PR is partial reliable, not unreliable. You > can't seem to turn off the failure detection and > protection capabilities of normal reliable SCTP, nor can > you turn off the congestion avoidance logic of SCTP, so > it is definitely more complex and more expensive compared > to say RTP/UDP, and probably TCP. PR-SCTP can definitely be "unreliable" if you so choose; have the service definition be "try this only once please" and the stack will only trasmit each send() call once. If the transport choice is to be "congestion controlled", why would NOT do congestion avoidance?! The feedback loop is exactly what allows SCTP to have TCP-friendly congetion control. I see failure detection as a benefit, not a detriment... It certainly would be nice to know that the transport has "gone away" so I can maybe failover to an alternate collector. Plus, I don't want to send packets needlessly if the collector has somehow crashed (e.g. might cause congestion?) > The key is to find a transition technology for the > 1000's of existing IP flow monitors that are purely > UDP based today. A simple transitional technology > should be appropriate, and I think RTP/UDP is a good > one, especially since the IESG has historically accepted > it as passing the congestion awareness criteria. > > I'm personally concerned that the only mentioned > transport candidates are connection-oriented and unicast > only. There are serious advantages to connection-less > transports and multicast support, and I'm interested in > ensuring that IPFIX can explore those advantages. Neither > SCTP-PR or TCP can support multicast, so I'm an advocate > of a three transport model. > > But Nevil is right, the real issue is what should be the > default transport for IPFIX, and here it seems to me that > SCTP-PR should NOT be the default, although there is enough > consensus for it to be a supported transport. TCP seems to > be the only real candidate for the default, simply from an > interoperability standpoint. If you've only got one shot > at attaching to an IP flow probe, are you going to use SCTP-PR > or TCP, if the probe could support either, but not both? > I think TCP will be the higher probability choice, which > would make it the default, by default. I disagree... picking TCP as the default tranport for reliable data then requires you to use RTP/UDP for the unreliable data (unless you want to send it ALL over TCP)... SCTP w/PR-SCTP extension allows both (over the same association even, if desired) and IMO seems to provide all the transport services that IPFIX requires. regards, --peter > Carter > > > > >>-----Original Message----- >>From: David Moore [mailto:dmoore@caida.org] >>Sent: Thursday, October 09, 2003 7:37 PM >>To: Carter Bullard >>Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] Congestion management >> >> >>On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: >> >>> When you're dealing with 1M+ records per second, the >>>concepts of record loss detection and selective retransmission >>>are just not practical. With these types of monitors, if >>>there is packet loss, there really isn't any way that the probes >>>can slow down, so, like RFC 3497, the concept would have to be >>>to have some type of feedback signal so the probe can stop. >>>So RTP/RTCP sounds good. I'd rather IPFIX send the message, >>>but the concept of IPFIX being congestion aware itself seems >>>to have dropped through a fissure somewhere. >> >>With SCTP-PR, afaik, allows you to tune whether you want any >>particular pieces of sent data to be reliable or unreliable. By >>setting every piece to be unreliable, then you have UDP in terms >>of reliability. However, SCTP-PR has the feedback signal which >>already provides TCP-friendly congestion avoidance. >> >>Is there some performance cost to SCTP-PR when all data is marked >>unreliable that you feel is too high, to require building a different >>feedback mechanism on top of UDP to also have congestion avoidance? >> >>I understand the desire for a UDP transport which has no congestion >>avoidance. But if the goal is something UDP-like (unreliable) but >>which does have congestion avoidance, IPFIX should use something >>already a standard (or about to be a standard) rather than inventing >>its own. >> >> >>-- david >> > > > > > > -- > 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 Oct 10 02:08:11 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 CAA05738 for ; Fri, 10 Oct 2003 02:08:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7qF7-0002BE-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 00:55:13 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7qF6-0002B7-00 for ipfix@net.doit.wisc.edu; Fri, 10 Oct 2003 00:55:12 -0500 Received: (qmail 33926 invoked from network); 10 Oct 2003 05:55:11 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 10 Oct 2003 05:55:11 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9A5tBX16507; Fri, 10 Oct 2003 01:55:11 -0400 Reply-To: From: "Carter Bullard" To: "'Peter Lei'" , Cc: "'David Moore'" , "'Nevil Brownlee'" Subject: RE: [ipfix] Congestion management Date: Fri, 10 Oct 2003 01:55:06 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B7@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE1E6@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Peter, You have to incur SCTP-PR functions regardless if you use them or not. The draft is very clear on this fact. SCTP-PR doesn't modify the wire protocol, so -PR doesn't reduce any overhead states or messages. It simply modifies the API and some sender semantics. And, of course, you don't get some required features such as congestion detection, without turning on some rather constrained behavior. For instance you can't do any kind of loss detection with SCTP-PR unless you use in order delivery (no "U" bits set). That can't be too efficient. And the header is huge, what is it? a common header, a chunk header and a data header, we're talking, what, 32 bytes? One problem I see is that IPFIX will use IPSec for its security. Without RFC 3554, "On the Use of Stream Control Transmission Protocol (SCTP) with Ipsec", which is not widely implemented, IPSec isn't compatible with SCTP features like multi-homing, basically making the fail-over mechanisms unuseable, and of course NAT doesn't work with multi-homing. I'm sure you feel that SCTP-PR is the most efficient mechanism for transporting bulk records at 100 Mbps across a single hop dedicated link, but does anyone have any real experience to back this position? Carter -----Original Message----- From: Peter Lei [mailto:peter.lei@ieee.org] Sent: Friday, October 10, 2003 12:06 AM To: ipfix@net.doit.wisc.edu Cc: carter@qosient.com; 'David Moore'; 'Nevil Brownlee' Subject: Re: [ipfix] Congestion management Carter Bullard wrote: > Hey David, > SCTP-PR is partial reliable, not unreliable. You > can't seem to turn off the failure detection and > protection capabilities of normal reliable SCTP, nor can > you turn off the congestion avoidance logic of SCTP, so > it is definitely more complex and more expensive compared > to say RTP/UDP, and probably TCP. PR-SCTP can definitely be "unreliable" if you so choose; have the service definition be "try this only once please" and the stack will only trasmit each send() call once. If the transport choice is to be "congestion controlled", why would NOT do congestion avoidance?! The feedback loop is exactly what allows SCTP to have TCP-friendly congetion control. I see failure detection as a benefit, not a detriment... It certainly would be nice to know that the transport has "gone away" so I can maybe failover to an alternate collector. Plus, I don't want to send packets needlessly if the collector has somehow crashed (e.g. might cause congestion?) > The key is to find a transition technology for the > 1000's of existing IP flow monitors that are purely > UDP based today. A simple transitional technology > should be appropriate, and I think RTP/UDP is a good > one, especially since the IESG has historically accepted > it as passing the congestion awareness criteria. > > I'm personally concerned that the only mentioned > transport candidates are connection-oriented and unicast > only. There are serious advantages to connection-less > transports and multicast support, and I'm interested in > ensuring that IPFIX can explore those advantages. Neither > SCTP-PR or TCP can support multicast, so I'm an advocate > of a three transport model. > > But Nevil is right, the real issue is what should be the > default transport for IPFIX, and here it seems to me that > SCTP-PR should NOT be the default, although there is enough > consensus for it to be a supported transport. TCP seems to > be the only real candidate for the default, simply from an > interoperability standpoint. If you've only got one shot > at attaching to an IP flow probe, are you going to use SCTP-PR > or TCP, if the probe could support either, but not both? > I think TCP will be the higher probability choice, which > would make it the default, by default. I disagree... picking TCP as the default tranport for reliable data then requires you to use RTP/UDP for the unreliable data (unless you want to send it ALL over TCP)... SCTP w/PR-SCTP extension allows both (over the same association even, if desired) and IMO seems to provide all the transport services that IPFIX requires. regards, --peter > Carter > > > > >>-----Original Message----- >>From: David Moore [mailto:dmoore@caida.org] >>Sent: Thursday, October 09, 2003 7:37 PM >>To: Carter Bullard >>Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] Congestion management >> >> >>On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: >> >>> When you're dealing with 1M+ records per second, the >>>concepts of record loss detection and selective retransmission >>>are just not practical. With these types of monitors, if >>>there is packet loss, there really isn't any way that the probes >>>can slow down, so, like RFC 3497, the concept would have to be >>>to have some type of feedback signal so the probe can stop. >>>So RTP/RTCP sounds good. I'd rather IPFIX send the message, >>>but the concept of IPFIX being congestion aware itself seems >>>to have dropped through a fissure somewhere. >> >>With SCTP-PR, afaik, allows you to tune whether you want any >>particular pieces of sent data to be reliable or unreliable. By >>setting every piece to be unreliable, then you have UDP in terms >>of reliability. However, SCTP-PR has the feedback signal which >>already provides TCP-friendly congestion avoidance. >> >>Is there some performance cost to SCTP-PR when all data is marked >>unreliable that you feel is too high, to require building a different >>feedback mechanism on top of UDP to also have congestion avoidance? >> >>I understand the desire for a UDP transport which has no congestion >>avoidance. But if the goal is something UDP-like (unreliable) but >>which does have congestion avoidance, IPFIX should use something >>already a standard (or about to be a standard) rather than inventing >>its own. >> >> >>-- david >> > > > > > > -- > 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 Oct 10 06:45: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 GAA18485 for ; Fri, 10 Oct 2003 06:45:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7uWn-0004NM-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 05:29:45 -0500 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 1A7uWm-0004NE-00; Fri, 10 Oct 2003 05:29:44 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-79.cisco.com [144.254.7.79]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h9AAPoU11334; Fri, 10 Oct 2003 12:25:55 +0200 (CEST) Message-ID: <3F86892E.7020602@cisco.com> Date: Fri, 10 Oct 2003 12:25:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: stbryant@cisco.com, alex.audu@alcatel.com, carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960380@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960380@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, My point is that I'm convinced that SCTP-PR gives all the advantages in one transport protocol. See the recent postings from Peter Lei; he knows the protocol a lot better than I do! Having the full flexibility (reliable, unreliable, partially reliable) in one transport protocol would be a plus. Let's give the flexibility to the different implementations. On the top of that, we don't know yet the future applications of IPFIX: PSAMP is one, exporting SLA information?, some MIB variables export?, etc... everything is possible since IPFIX is a generic export format. As I said, I think we should just use the right protocol instead of just using what exists. IMHO, SCTP_PR should be the target as transport transport. So, I would vote for SCTP with the PR extension. Regards, Benoit. >Benoit, > > SCTP-PR does not make me happy, nor do the previous decisions >around reliability as it regards to billing. > > Dropping packets under congestion is already done by UDP, and >UDP is ubiquitous in all OS's. > > Is there some challenge in defining IPFIX over TCP? It seems >to me that this is the easier case, there are less things to map >to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP >your proposal, i.e. force the use of SCTP-PR? > > As with the experience of Diameter, specifying both transports >will enable a migration to SCTP-PR for everyone if it actually >proves to have the values espoused and it is readily available. >In the interim having a TCP mapping (and UDP) would address the >requirements which I've encountered (billing issues aside). > > As Peter pointed out the resource constraints on the exporter >imposed by TCP can be mitigated in the implementation. > >Regards, > > Jeff Meyer > > > >>-----Original Message----- >>From: Benoit Claise [mailto:bclaise@cisco.com] >>Sent: Thursday, October 09, 2003 9:15 AM >>To: stbryant@cisco.com >>Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; >>'MEYER,JEFFREY D (HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>ipfix@net.doit.wisc.edu; rrs@cisco.com >>Subject: Re: [ipfix] STCP as a default transport not >> >> >>Dear all, >> >>There are advantages regarding the use of SCTP versus TCP (discussed >>already on the list) but I think that the biggest advantage >>of SCTP is >>actually the extension SCTP-PR. And I'm surprised to see no >>reactions on >>the email below. >>Yes, I know that the SCTP-PR is not a standard yet but I >>think that we >>should just take the right protocol instead of just using what exists >>because it exists! >> >>I remember the heated discussions maybe one year ago about >>using IPFIX >>for billing, about high availability, etc... >>And one of the solution that could make everybody happy is: SCTP-PR. >>We know that we do have some memory issues with TCP on the >>high-end routers. >>But, for the smaller exporter OR if you can afford/if it's >>possible to >>pack the exporter with the appropriate amount of memory, >>SCTP-PR would >>work perfectly well! >>Now, in the majority of cases (no billing, no enough memory/too many >>flow records, etc...) SCTP-PR would drop the flow records >>excess if any, >>which I think is the right thing to do. >> >>Regards, Benoit. >> >> >> >> >>>I think that the interest is in using PR-SCTP as described in >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt >>> >>>rather than RFC 2960 SCTP. >>> >>>This claims the following benefits: >>> >>> >>>1.3 Benefits of PR-SCTP >>> >>> Hereafter, we use the notation "PR-SCTP" to refer to the SCTP >>> protocol extended as defined in this document. >>> >>> The following are some of the advantages for integrating >>> >>> >>partially >> >> >>> reliable data service into SCTP, i.e., benefits of PR-SCTP: >>> >>> 1. Some application layer protocols may benefit from >>> >>> >>being able to >> >> >>> use a single SCTP association to carry both reliable >>> >>> >>content, -- >> >> >>> such as text pages, billing and accounting information, setup >>> signaling -- and unreliable content, e.g. state that >>> >>> >>is highly >> >> >>> sensitive to timeliness, where generating a new >>> >>> >>packet is more >> >> >>> advantageous than transmitting an old one [1]. >>> >>> 2. Partially reliable data traffic carried by PR-SCTP >>> >>> >>will enjoy the >> >> >>> same communication failure detection and protection >>> >>> >>capabilities >> >> >>> as the normal reliable SCTP data traffic does. This >>> >>> >>includes the >> >> >>> ability to: - quickly detect a failed destination address; - >>> fail-over to an alternate destination address, and; >>> >>> >>- be notified >> >> >>> if the data receiver becomes unreachable. >>> >>> 3. In addition to providing unordered unreliable data >>> >>> >>transfer as >> >> >>> UDP does, PR-SCTP can provide ordered unreliable >>> >>> >>data transfer >> >> >>> service. >>> >>> 4. PR-SCTP employs the same congestion control and congestion >>> avoidance for all data traffic, whether reliable or partially >>> reliable - this is very desirable since SCTP enforces >>> TCP-friendliness (unlike UDP.) >>> >>> 5. Because of the chunk bundling function of SCTP, reliable and >>> unreliable messages can be multiplexed over a single PR-SCTP >>> association. Therefore, the number of IP datagrams >>> >>> >>(and hence >> >> >>> the network overhead) can be reduced versus having >>> >>> >>to send these >> >> >>> different types of data using separate protocols. >>> >>> >>Additionally, >> >> >>> this multiplexing allows for port savings versus >>> >>> >>using different >> >> >>> ports for reliable and unreliable connections. >>> >>>---------- >>> >>>PR-SCTP has the option of being able to configure the >>> >>> >>exporter to work >> >> >>>on a >>>best effort data export basis, rather than being >>> >>> >>constrained to work on a >> >> >>>reliable basis. >>> >>>We should spend some time thinking about the behaviour we >>> >>> >>want in the >> >> >>>exporter when the network is congested, perhaps due to an >>> >>> >>attack. PR-SCTP >> >> >>>gives us the option of running a best effort data >>> >>> >>collection to gleen >> >> >>>what >>>is going on, when a TCP based exporter would otherwise >>> >>> >>collapse due to >> >> >>>backlog on the exporter. >>> >>>Stewart >>> >>> >>> >>> >>>-- >>>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 Oct 10 07:20: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 HAA20270 for ; Fri, 10 Oct 2003 07:20:00 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7vBI-0005te-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 06:11:36 -0500 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 1A7vBG-0005tU-00 for ipfix@net.doit.wisc.edu; Fri, 10 Oct 2003 06:11:35 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-79.cisco.com [144.254.7.79]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h9ABAsU09474; Fri, 10 Oct 2003 13:10:54 +0200 (CEST) Message-ID: <3F8693BE.3020005@cisco.com> Date: Fri, 10 Oct 2003 13:10:54 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Tal Givoly'" , stbryant@cisco.com, Maurizio Molina , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] bytes and packet counters, tstamp of last report References: <1D3D2C371FCBD947A7897FABBD3533A502960367@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960367@xsun01.ptp.hp.com> Content-Type: multipart/alternative; boundary="------------020705000700090102000202" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------020705000700090102000202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, >Hi, > > > In some use cases counters may have desirable properties as Tal >has described. But like many things, counters also have their >limitations and downsides. > > In the basic Flow Export scenario which is exemplified by existing >Netflow implementations, a flow record indicates a summary of >observed behavior. > > Consider two flow events: > > sourceAddress=1.2.3.4 > destinationAddress=1.2.3.5 > packetCount=1000 > byteCount=100000 > flowCreationTime=2003-10-08T10:00:00Z > flowEndTime=2003-10-08T10:00:05Z > TcpControlBits=0x13 > > > sourceAddress=1.2.3.4 > destinationAddress=1.2.3.6 > packetCount=1000 > byteCount=200000 > flowCreationTime=2003-10-08T10:00:02Z > flowEndTime=2003-10-08T10:00:06Z > TcpControlBits=0x13 > > Each of these completely describes a conversation, as it includes both > the fin and syn TCP flags. Start time, end time and absolute counts. > > Given the large percentage of flows which when exported, describe a > complete conversation, I don't see the advantage of using counters. > > I'm not even sure how one would propose the use of counters as an > alternative. Would you require two records be sent for each > flow (one with byteCounter and packetCounter=0 and another with > the final value?) > > Since most flows can be represented by a single record, doubling > the number of records to accomodate counters seems a bit odd. > Counters also require the holding of state, which produces > a much greater burden on the collector. Since the necessary > state must be held by the observer, why double the workload? > I.e. a single counter is pretty useless. I need to delta it > against a previously observed matching counter to arrive at a > quantity. > > > For information models such as PSAMP, there may be a compelling > use case. > > So I imagine adding an explicit annotation in the information > model for counters would be worthwile. However, I think that > counter behavior such as when it is zeroed out and its rollover > behavior need to be appropriately documented and thought out. > (e.g. on restart, the counters presumably reset to zero, so > here is additional state a collector may need to monitor to > reconcile (if possible) existing observations). > > For IPFIX's base information model, I would strongly discourage > "fixing" something which isn't broken. > I fully agree with Jeff here regarding the flow records but there are actually 2 aspects to this problem. 1. The flow record. There is an expiration process for the flow records. http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt 4.1 Flow Expiration A Flow is considered to be inactive if no packets belonging to the Flow have been observed at the Observation Point for a given timeout interval otherwise it is considered as an active flow. A Flow can be exported under the following conditions: 1. If the Metering Process can detect the end of a Flow, it SHOULD export the Flow Records at the end of the Flow. For example, a Flow generated by TCP [3] type of traffic where the FIN or RST bits indicate the end of the Flow. 2. If the Flow has been inactive for a certain period of time. This inactivity timeout SHOULD be configurable, with a minimum value of 0 for an immediate expiration. For example, a Flow generated by UDP [2] type of traffic. 3. For long-lasting Flows, the Metering Process SHOULD export the Flow Records on a regular basis. This periodicity SHOULD be configurable. 4. If the Metering Process experiences internal constraints, a Flow MAY be forced to expire prematurely (for example, counters wrapping or low memory). What the IPFIX information model tries to say is that: a flow expires and we send the packet/byte count for the flow duration. So this is actually a running counter for the flow duration. Note: a long last flow is actually composed a several flows (see condition 3 before). Ok, I understand that this could be better explained in the IPFIX information model draft: The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt speaks of: Incoming counter with IN_BYTES 1 N length N x 8 bits for bytes associated with an IP Flow Incoming counter with IN_PKTS 2 N length N x 8 bits for packets associated with an IP Flow 2. The second aspect is actually total counters. Something that needs to added to the IPFIX protocol draft is described in its "open issues" section: - The proposal on the table is to send a IPFIX Sync (this would be an Options Data Records) message periodically (periodicity is configurable), with the following information (aside the standard IPFix header) * Number of flow records sent (for each template?) * Packets and bytes sent (for each template?) So we need to keep a few running counters. In http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt, there are explicitely described: Counter with length N x 8 bits for bytes TOTAL_BYTES_EXP 40 N for the number of bytes exported by the Observation Domain Counter with length N x 8 bits for bytes TOTAL_EXP_PKTS_SENT 41 N for the number of packets exported by the Observation Domain Counter with length N x 8 bits for bytes TOTAL_FLOWS_EXP 42 N for the number of Flows exported by the Observation Domain I propose to also explicitely described them in the IPFIX information model draft. Regards, Benoit. > > >Regards, > > Jeff Meyer > >_________________________________________________________________ >Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- > >sign up now! http://join.msn.com/?page=dept/dialup > > > >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu]On Behalf >>Of Tal Givoly >>Sent: Wednesday, October 08, 2003 9:14 AM >>To: stbryant@cisco.com; Maurizio Molina >>Cc: ipfix@net.doit.wisc.edu >>Subject: RE: [ipfix] bytes and packet counters, tstamp of last report >> >> >>Both counters have value (running and delta). Obviously, they >>must be kept >>discrete from an information model perspective as they >>represent different >>information. Devices sometimes maintain one, sometimes the other, and >>sometimes both. Just as an example, as far as I recall, >>NetFlow v5-8 doesn't >>maintain running counters (counter to your suggestion) EVEN THOUGH it >>operates over a non-reliable and non-congestion-aware >>transport. Our probe >>product emits both for various different purposes. >> >>Tal >> >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu]On Behalf >>Of Stewart Bryant >>Sent: Wednesday, October 08, 2003 8:09 AM >>To: Maurizio Molina >>Cc: 'ipfix@net.doit.wisc.edu' >>Subject: Re: [ipfix] bytes and packet counters, tstamp of last report >> >> >> >> >>Maurizio Molina wrote: >> >> >> >>>Hi, >>>the IPFIX info model states (sec. 6.10) that >>> >>> The packet count can be a running counter and is the >>> >>> >>count from the >> >> >>> beginning of the flow establishment. >>> >>> The packet count can be a delta counter and is the count since the >>> last report for this flow. >>> >>> >>> >>I would prefer that we only supported running counters because: >> >>a) Supporting two types is more scope for non-interworking, and >> you can always convert from one to the other at the collector. >> >>b) Running counters also work over an unreliable transport >> whereas delta counters mandate the use of a reliable transport. >> >>c) Running counters are most likely what the hardware is keeping >> anyway, therefore delta counters are more work and more storage >> at the exporter. >> >>If we decide that we need both then we have to represent them >>as two different information elements because the info model does >>not support sub-typing. >> >>Stewart >> >> >> >>>(There's the same statement for byte counts in 6.11). >>> >>>To me, this doesn't clarify wheter it is both...and (2 counters) or >>>either .... or (1 counter). >>> >>>Moreover, there is currently no room for a field containing the >>>timestamp of the last report of a flow. I think that keeping this >>>timestamp is helpful for many applications and the info model should >>>support it. >>>Regards, >>>Maurizio >>> >>> >>> >>>-- >>>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/ > > --------------020705000700090102000202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
Hi,


  In some use cases counters may have desirable properties as Tal
has described.  But like many things, counters also have their 
limitations and downsides.

  In the basic Flow Export scenario which is exemplified by existing
Netflow implementations, a flow record indicates a summary of
observed behavior.

  Consider two flow events:

      sourceAddress=1.2.3.4
      destinationAddress=1.2.3.5
      packetCount=1000
      byteCount=100000
      flowCreationTime=2003-10-08T10:00:00Z
      flowEndTime=2003-10-08T10:00:05Z
      TcpControlBits=0x13


      sourceAddress=1.2.3.4
      destinationAddress=1.2.3.6
      packetCount=1000
      byteCount=200000
      flowCreationTime=2003-10-08T10:00:02Z
      flowEndTime=2003-10-08T10:00:06Z
      TcpControlBits=0x13

  Each of these completely describes a conversation, as it includes both
  the fin and syn TCP flags.  Start time, end time and absolute counts.

  Given the large percentage of flows which when exported, describe a
  complete conversation, I don't see the advantage of using counters.

  I'm not even sure how one would propose the use of counters as an
  alternative.  Would you require two records be sent for each
  flow (one with byteCounter and packetCounter=0 and another with
  the final value?)

  Since most flows can be represented by a single record, doubling
  the number of records to accomodate counters seems a bit odd.
  Counters also require the holding of state, which produces
  a much greater burden on the collector.  Since the necessary
  state must be held by the observer, why double the workload?
  I.e. a single   counter is pretty useless.  I need to delta it
  against a previously observed matching counter to arrive at a
  quantity.


  For information models such as PSAMP, there may be a compelling
  use case.

  So I imagine adding an explicit annotation in the information
  model for counters would be worthwile.  However, I think that
  counter behavior such as when it is zeroed out and its rollover
  behavior need to be appropriately documented and thought out.
  (e.g. on restart, the counters presumably reset to zero, so
  here is additional state a collector may need to monitor to
  reconcile (if possible) existing observations).

  For IPFIX's base information model, I would strongly discourage
  "fixing" something which isn't broken.
I fully agree with Jeff here regarding the flow records but there are actually 2 aspects to this problem.

1.
The flow record.
There is an expiration process for the flow records.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt
4.1 Flow Expiration 
    
   A Flow is considered to be inactive if no packets belonging to the 
   Flow have been observed at the Observation Point for a given timeout 
   interval otherwise it is considered as an active flow.  
   A Flow can be exported under the following conditions: 
    
      1. If the Metering Process can detect the end of a Flow, it 
      SHOULD export the Flow Records at the end of the Flow. For 
      example, a Flow generated by TCP [3] type of traffic where the 
      FIN or RST bits indicate the end of the Flow. 
       
      2. If the Flow has been inactive for a certain period of time. 
      This inactivity timeout SHOULD be configurable, with a minimum 
      value of 0 for an immediate expiration. For example, a Flow 
      generated by UDP [2] type of traffic. 
       
      3. For long-lasting Flows, the Metering Process SHOULD export the 
      Flow Records on a regular basis. This periodicity SHOULD be 
      configurable. 
       
      4. If the Metering Process experiences internal constraints, a 
      Flow MAY be forced to expire prematurely (for example, counters 
      wrapping or low memory). 

What the IPFIX information model tries to say is that: a flow expires and we send the packet/byte count for the flow duration. So this is actually a running counter for the flow duration.
Note: a long last flow is actually composed a several flows (see condition 3 before). 
Ok, I understand that this could be better explained in the IPFIX information model draft:
   The packet count can be a running counter and is the count from the
   beginning of the flow establishment.
   The packet count can be a delta counter and is the count since the
   last report for this flow.


http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt speaks of:
                                            Incoming counter with  
    IN_BYTES                     1    N     length N x 8 bits for bytes  
                                            associated with an IP Flow    
 
                                            Incoming counter with  
    IN_PKTS                      2    N     length N x 8 bits for  
                                            packets associated 
                                            with an IP Flow  

2. 
The second aspect is actually total counters.
Something that needs to added to the IPFIX protocol draft is described in its "open issues" section:
   - The proposal on the table is to send a IPFIX Sync (this would be 
   an Options Data Records) message periodically (periodicity is 
   configurable), with the following information (aside the standard 
   IPFix header) 
           * Number of flow records sent (for each template?)  
           * Packets and bytes sent (for each template?) 

So we need to keep a few running counters.

In http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt, there are explicitely described:
                                            Counter with length   
                                            N x 8 bits for bytes 
    TOTAL_BYTES_EXP              40   N     for the number of bytes  
                                            exported by the Observation 
                                            Domain 
 
                                            Counter with length  
                                            N x 8 bits for bytes  
    TOTAL_EXP_PKTS_SENT          41   N     for the number of packets  
                                            exported by the Observation  
                                            Domain  
 
                                            Counter with length  
                                            N x 8 bits for bytes  
    TOTAL_FLOWS_EXP              42   N     for the number of Flows  
                                            exported by the Observation  
                                            Domain

I propose to also explicitely described them in the IPFIX information model draft.

Regards, Benoit.



Regards,

  Jeff Meyer

_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month.  Limited time offer--

sign up now!   http://join.msn.com/?page=dept/dialup

  
-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Tal Givoly
Sent: Wednesday, October 08, 2003 9:14 AM
To: stbryant@cisco.com; Maurizio Molina
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] bytes and packet counters, tstamp of last report


Both counters have value (running and delta). Obviously, they 
must be kept
discrete from an information model perspective as they 
represent different
information. Devices sometimes maintain one, sometimes the other, and
sometimes both. Just as an example, as far as I recall, 
NetFlow v5-8 doesn't
maintain running counters (counter to your suggestion) EVEN THOUGH it
operates over a non-reliable and non-congestion-aware 
transport. Our probe
product emits both for various different purposes.

Tal

-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Stewart Bryant
Sent: Wednesday, October 08, 2003 8:09 AM
To: Maurizio Molina
Cc: 'ipfix@net.doit.wisc.edu'
Subject: Re: [ipfix] bytes and packet counters, tstamp of last report




Maurizio Molina wrote:

    
Hi,
the IPFIX info model states (sec. 6.10) that

   The packet count can be a running counter and is the 
      
count from the
    
  beginning of the flow establishment.

  The packet count can be a delta counter and is the count since the
  last report for this flow.

      
I would prefer that we only supported running counters because:

a) Supporting two types is more scope for non-interworking, and
    you can always convert from one to the other at the collector.

b) Running counters also work over an unreliable transport
    whereas delta counters mandate the use of a reliable transport.

c) Running counters are most likely what the hardware is keeping
    anyway, therefore delta counters are more work and more storage
    at the exporter.

If we decide that we need both then we have to represent them
as two different information elements because the info model does
not support sub-typing.

Stewart

    
(There's the same statement for byte counts in 6.11).

To me, this doesn't clarify wheter it is both...and  (2 counters) or
either .... or (1 counter).

Moreover, there is currently no room for a field containing the
timestamp of the last report of a flow. I think that keeping this
timestamp is helpful for many applications and the info model should
support it.
Regards,
Maurizio



--
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/

--------------020705000700090102000202-- -- 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 Oct 10 10:55:51 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 KAA01936 for ; Fri, 10 Oct 2003 10:55:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7yGC-0004MW-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 09:28:52 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7yGB-0004MP-00 for ipfix@net.doit.wisc.edu; Fri, 10 Oct 2003 09:28:51 -0500 Received: (qmail 95136 invoked from network); 10 Oct 2003 14:28:49 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 10 Oct 2003 14:28:49 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9AESnX17035; Fri, 10 Oct 2003 10:28:50 -0400 Reply-To: From: "Carter Bullard" To: "'Peter Lei'" , Cc: "'David Moore'" , "'Nevil Brownlee'" Subject: RE: [ipfix] Congestion management Date: Fri, 10 Oct 2003 10:28:45 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B8@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE1E6@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Gentle people, Just a follow up on SCTP-PR available implementations. There were only 3 entities that had SCTP-PR implementations at the 5th annual bakeoff, Sept 2002, Cisco, Temple and Uni Essen. There was suppose to be the 6th annual bakeoff in June, 2003, but the sctp.org mailing list ends abruptly in May, 2003. Does anyone know where the mailing list went, and/or the results of the bakeoff, specifically who else has implemented SCTP-PR? Carter -- 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 Oct 10 11:13: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 LAA02839 for ; Fri, 10 Oct 2003 11:13:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7yWZ-0004qr-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 09:45:47 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7yWY-0004ql-00; Fri, 10 Oct 2003 09:45:46 -0500 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id A139A1C02819; Fri, 10 Oct 2003 10:45:45 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 7BC2F1C000A6; Fri, 10 Oct 2003 10:45:45 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4S0G66KC>; Fri, 10 Oct 2003 10:45:45 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960387@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Benoit Claise'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: stbryant@cisco.com, alex.audu@alcatel.com, carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com Subject: RE: [ipfix] STCP as a default transport not Date: Fri, 10 Oct 2003 10:45:37 -0400 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 Benoit, I am not in any way against specifying IPFIX on top of PR-SCTP, what I am against is making that the ONLY supported transport. This is for practical reasons, like availability of implementation. And as cited before because of transport protocols' affinity for running in kernel vs. user space, the availability is going to be a lot slower coming than one might like. I would liken this to deciding to define a transport layer protocol which could only run on IPv6 and not IPv4. You could, but if you can run on both, I think there are decided benefits. The Diameter authors seemed to have made this pragmatic choice. It is a bit ironic that previous decisions of the WG around choice of candidate protocols were ultimately trumped by "practical reasons" like NF is more widely deployed, despite the fact that it was the only protocol with NO binding to a congestion aware transport. And now, the arguments seem to be a complete 180 change. Regards, Jeff Meyer > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Friday, October 10, 2003 3:26 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: stbryant@cisco.com; alex.audu@alcatel.com; carter@qosient.com; > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: Re: [ipfix] STCP as a default transport not > > > Jeff, > > My point is that I'm convinced that SCTP-PR gives all the advantages > in one transport protocol. See the recent postings from Peter > Lei; he knows the protocol a lot > better than I do! > Having the full flexibility (reliable, unreliable, partially > reliable) in one transport protocol would be a plus. > Let's give the flexibility to the different implementations. > On the top of that, we don't know yet the future applications > of IPFIX: > PSAMP is one, exporting SLA information?, some MIB variables > export?, etc... everything is possible since IPFIX is a generic > export format. > As I said, I think we should just use the right protocol > instead of just > using what exists. IMHO, SCTP_PR should be the target as transport > transport. So, I would vote for SCTP with the PR extension. > > Regards, Benoit. > > > >Benoit, > > > > SCTP-PR does not make me happy, nor do the previous decisions > >around reliability as it regards to billing. > > > > Dropping packets under congestion is already done by UDP, and > >UDP is ubiquitous in all OS's. > > > > Is there some challenge in defining IPFIX over TCP? It seems > >to me that this is the easier case, there are less things to map > >to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > >your proposal, i.e. force the use of SCTP-PR? > > > > As with the experience of Diameter, specifying both transports > >will enable a migration to SCTP-PR for everyone if it actually > >proves to have the values espoused and it is readily available. > >In the interim having a TCP mapping (and UDP) would address the > >requirements which I've encountered (billing issues aside). > > > > As Peter pointed out the resource constraints on the exporter > >imposed by TCP can be mitigated in the implementation. > > > >Regards, > > > > Jeff Meyer > > > > > > > >>-----Original Message----- > >>From: Benoit Claise [mailto:bclaise@cisco.com] > >>Sent: Thursday, October 09, 2003 9:15 AM > >>To: stbryant@cisco.com > >>Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > >>'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > ipfix-chairs@net.doit.wisc.edu; > >>ipfix@net.doit.wisc.edu; rrs@cisco.com > >>Subject: Re: [ipfix] STCP as a default transport not > >> > >> > >>Dear all, > >> > >>There are advantages regarding the use of SCTP versus TCP > (discussed > >>already on the list) but I think that the biggest advantage > >>of SCTP is > >>actually the extension SCTP-PR. And I'm surprised to see no > >>reactions on > >>the email below. > >>Yes, I know that the SCTP-PR is not a standard yet but I > >>think that we > >>should just take the right protocol instead of just using > what exists > >>because it exists! > >> > >>I remember the heated discussions maybe one year ago about > >>using IPFIX > >>for billing, about high availability, etc... > >>And one of the solution that could make everybody happy is: SCTP-PR. > >>We know that we do have some memory issues with TCP on the > >>high-end routers. > >>But, for the smaller exporter OR if you can afford/if it's > >>possible to > >>pack the exporter with the appropriate amount of memory, > >>SCTP-PR would > >>work perfectly well! > >>Now, in the majority of cases (no billing, no enough > memory/too many > >>flow records, etc...) SCTP-PR would drop the flow records > >>excess if any, > >>which I think is the right thing to do. > >> > >>Regards, Benoit. > >> > >> > >> > >> > >>>I think that the interest is in using PR-SCTP as described in > >>> > >>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > >>> > >>>rather than RFC 2960 SCTP. > >>> > >>>This claims the following benefits: > >>> > >>> > >>>1.3 Benefits of PR-SCTP > >>> > >>> Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > >>> protocol extended as defined in this document. > >>> > >>> The following are some of the advantages for integrating > >>> > >>> > >>partially > >> > >> > >>> reliable data service into SCTP, i.e., benefits of PR-SCTP: > >>> > >>> 1. Some application layer protocols may benefit from > >>> > >>> > >>being able to > >> > >> > >>> use a single SCTP association to carry both reliable > >>> > >>> > >>content, -- > >> > >> > >>> such as text pages, billing and accounting > information, setup > >>> signaling -- and unreliable content, e.g. state that > >>> > >>> > >>is highly > >> > >> > >>> sensitive to timeliness, where generating a new > >>> > >>> > >>packet is more > >> > >> > >>> advantageous than transmitting an old one [1]. > >>> > >>> 2. Partially reliable data traffic carried by PR-SCTP > >>> > >>> > >>will enjoy the > >> > >> > >>> same communication failure detection and protection > >>> > >>> > >>capabilities > >> > >> > >>> as the normal reliable SCTP data traffic does. This > >>> > >>> > >>includes the > >> > >> > >>> ability to: - quickly detect a failed destination address; - > >>> fail-over to an alternate destination address, and; > >>> > >>> > >>- be notified > >> > >> > >>> if the data receiver becomes unreachable. > >>> > >>> 3. In addition to providing unordered unreliable data > >>> > >>> > >>transfer as > >> > >> > >>> UDP does, PR-SCTP can provide ordered unreliable > >>> > >>> > >>data transfer > >> > >> > >>> service. > >>> > >>> 4. PR-SCTP employs the same congestion control and congestion > >>> avoidance for all data traffic, whether reliable or > partially > >>> reliable - this is very desirable since SCTP enforces > >>> TCP-friendliness (unlike UDP.) > >>> > >>> 5. Because of the chunk bundling function of SCTP, reliable and > >>> unreliable messages can be multiplexed over a single PR-SCTP > >>> association. Therefore, the number of IP datagrams > >>> > >>> > >>(and hence > >> > >> > >>> the network overhead) can be reduced versus having > >>> > >>> > >>to send these > >> > >> > >>> different types of data using separate protocols. > >>> > >>> > >>Additionally, > >> > >> > >>> this multiplexing allows for port savings versus > >>> > >>> > >>using different > >> > >> > >>> ports for reliable and unreliable connections. > >>> > >>>---------- > >>> > >>>PR-SCTP has the option of being able to configure the > >>> > >>> > >>exporter to work > >> > >> > >>>on a > >>>best effort data export basis, rather than being > >>> > >>> > >>constrained to work on a > >> > >> > >>>reliable basis. > >>> > >>>We should spend some time thinking about the behaviour we > >>> > >>> > >>want in the > >> > >> > >>>exporter when the network is congested, perhaps due to an > >>> > >>> > >>attack. PR-SCTP > >> > >> > >>>gives us the option of running a best effort data > >>> > >>> > >>collection to gleen > >> > >> > >>>what > >>>is going on, when a TCP based exporter would otherwise > >>> > >>> > >>collapse due to > >> > >> > >>>backlog on the exporter. > >>> > >>>Stewart > >>> > >>> > >>> > >>> > >>>-- > >>>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 Oct 10 11:49: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 LAA04303 for ; Fri, 10 Oct 2003 11:49:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7zJ9-0006Zk-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 10:35:59 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7zJ8-0006ZZ-00 for ipfix@net.doit.wisc.edu; Fri, 10 Oct 2003 10:35:58 -0500 Received: (qmail 32013 invoked from network); 10 Oct 2003 15:35:56 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 10 Oct 2003 15:35:56 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9AFZuX17068; Fri, 10 Oct 2003 11:35:56 -0400 Reply-To: From: "Carter Bullard" To: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Benoit Claise'" Cc: , , "'Reinaldo Penno'" , , , Subject: RE: [ipfix] STCP as a default transport not Date: Fri, 10 Oct 2003 11:35:52 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B9@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE232@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver My principal concern is that SCTP is too young to be the only transport. For example, a recent Univ. of Delaware Technical Document, co-authored by Cisco, identifies a serious problem with SCTP congestion control when there are multiple drops in a single window, causing it to degrade "more than necessary to be 'TCP-friendly', i.e. it grinds to a dribble for a little while, while transmitting more packets. The link where you can get the publication is: http://www.eecis.udel.edu/~amer/PEL/poc/index.html The paper is "SCTP and TCP Variants: Congestion Control Under Multiple Losses", very recent. The point is that these are the normal growing pains of a new protocol, but SCTP and PR-SCTP still have some problems to iron out. Like Jeff, I have no problems with IPFIX running over PR-SCTP, but not as the only protocol. Carter > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Friday, October 10, 2003 9:46 AM > To: 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: stbryant@cisco.com; alex.audu@alcatel.com; > carter@qosient.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com > Subject: RE: [ipfix] STCP as a default transport not > > > Benoit, > > I am not in any way against specifying IPFIX on top of PR-SCTP, > what I am against is making that the ONLY supported transport. > This is for practical reasons, like availability of implementation. > And as cited before because of transport protocols' affinity > for running in kernel vs. user space, the availability is going > to be a lot slower coming than one might like. > > I would liken this to deciding to define a transport layer > protocol which could only run on IPv6 and not IPv4. You could, > but if you can run on both, I think there are decided benefits. > > The Diameter authors seemed to have made this pragmatic choice. > > It is a bit ironic that previous decisions of the WG around > choice of candidate protocols were ultimately trumped by "practical > reasons" like NF is more widely deployed, despite the fact > that it was the only protocol with NO binding to a congestion > aware transport. And now, the arguments seem to be a complete > 180 change. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Friday, October 10, 2003 3:26 AM > > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > Cc: stbryant@cisco.com; alex.audu@alcatel.com; carter@qosient.com; > > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > > ipfix@net.doit.wisc.edu; rrs@cisco.com > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Jeff, > > > > My point is that I'm convinced that SCTP-PR gives all the > advantages > > in one transport protocol. See the recent postings from Peter > > Lei; he knows the protocol a lot > > better than I do! > > Having the full flexibility (reliable, unreliable, partially > > reliable) in one transport protocol would be a plus. > > Let's give the flexibility to the different implementations. > > On the top of that, we don't know yet the future applications > > of IPFIX: > > PSAMP is one, exporting SLA information?, some MIB variables > > export?, etc... everything is possible since IPFIX is a generic > > export format. > > As I said, I think we should just use the right protocol > > instead of just > > using what exists. IMHO, SCTP_PR should be the target as transport > > transport. So, I would vote for SCTP with the PR extension. > > > > Regards, Benoit. > > > > > > >Benoit, > > > > > > SCTP-PR does not make me happy, nor do the previous decisions > > >around reliability as it regards to billing. > > > > > > Dropping packets under congestion is already done by UDP, and > > >UDP is ubiquitous in all OS's. > > > > > > Is there some challenge in defining IPFIX over TCP? It seems > > >to me that this is the easier case, there are less things to map > > >to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > > >your proposal, i.e. force the use of SCTP-PR? > > > > > > As with the experience of Diameter, specifying both transports > > >will enable a migration to SCTP-PR for everyone if it actually > > >proves to have the values espoused and it is readily available. > > >In the interim having a TCP mapping (and UDP) would address the > > >requirements which I've encountered (billing issues aside). > > > > > > As Peter pointed out the resource constraints on the exporter > > >imposed by TCP can be mitigated in the implementation. > > > > > >Regards, > > > > > > Jeff Meyer > > > > > > > > > > > >>-----Original Message----- > > >>From: Benoit Claise [mailto:bclaise@cisco.com] > > >>Sent: Thursday, October 09, 2003 9:15 AM > > >>To: stbryant@cisco.com > > >>Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > > >>'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > > ipfix-chairs@net.doit.wisc.edu; > > >>ipfix@net.doit.wisc.edu; rrs@cisco.com > > >>Subject: Re: [ipfix] STCP as a default transport not > > >> > > >> > > >>Dear all, > > >> > > >>There are advantages regarding the use of SCTP versus TCP > > (discussed > > >>already on the list) but I think that the biggest advantage > > >>of SCTP is > > >>actually the extension SCTP-PR. And I'm surprised to see no > > >>reactions on > > >>the email below. > > >>Yes, I know that the SCTP-PR is not a standard yet but I > > >>think that we > > >>should just take the right protocol instead of just using > > what exists > > >>because it exists! > > >> > > >>I remember the heated discussions maybe one year ago about > > >>using IPFIX > > >>for billing, about high availability, etc... > > >>And one of the solution that could make everybody happy > is: SCTP-PR. > > >>We know that we do have some memory issues with TCP on the > > >>high-end routers. > > >>But, for the smaller exporter OR if you can afford/if it's > > >>possible to > > >>pack the exporter with the appropriate amount of memory, > > >>SCTP-PR would > > >>work perfectly well! > > >>Now, in the majority of cases (no billing, no enough > > memory/too many > > >>flow records, etc...) SCTP-PR would drop the flow records > > >>excess if any, > > >>which I think is the right thing to do. > > >> > > >>Regards, Benoit. > > >> > > >> > > >> > > >> > > >>>I think that the interest is in using PR-SCTP as described in > > >>> > > > >>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt > > >>> > > >>>rather than RFC 2960 SCTP. > > >>> > > >>>This claims the following benefits: > > >>> > > >>> > > >>>1.3 Benefits of PR-SCTP > > >>> > > >>> Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > > >>> protocol extended as defined in this document. > > >>> > > >>> The following are some of the advantages for integrating > > >>> > > >>> > > >>partially > > >> > > >> > > >>> reliable data service into SCTP, i.e., benefits of PR-SCTP: > > >>> > > >>> 1. Some application layer protocols may benefit from > > >>> > > >>> > > >>being able to > > >> > > >> > > >>> use a single SCTP association to carry both reliable > > >>> > > >>> > > >>content, -- > > >> > > >> > > >>> such as text pages, billing and accounting > > information, setup > > >>> signaling -- and unreliable content, e.g. state that > > >>> > > >>> > > >>is highly > > >> > > >> > > >>> sensitive to timeliness, where generating a new > > >>> > > >>> > > >>packet is more > > >> > > >> > > >>> advantageous than transmitting an old one [1]. > > >>> > > >>> 2. Partially reliable data traffic carried by PR-SCTP > > >>> > > >>> > > >>will enjoy the > > >> > > >> > > >>> same communication failure detection and protection > > >>> > > >>> > > >>capabilities > > >> > > >> > > >>> as the normal reliable SCTP data traffic does. This > > >>> > > >>> > > >>includes the > > >> > > >> > > >>> ability to: - quickly detect a failed destination > address; - > > >>> fail-over to an alternate destination address, and; > > >>> > > >>> > > >>- be notified > > >> > > >> > > >>> if the data receiver becomes unreachable. > > >>> > > >>> 3. In addition to providing unordered unreliable data > > >>> > > >>> > > >>transfer as > > >> > > >> > > >>> UDP does, PR-SCTP can provide ordered unreliable > > >>> > > >>> > > >>data transfer > > >> > > >> > > >>> service. > > >>> > > >>> 4. PR-SCTP employs the same congestion control and congestion > > >>> avoidance for all data traffic, whether reliable or > > partially > > >>> reliable - this is very desirable since SCTP enforces > > >>> TCP-friendliness (unlike UDP.) > > >>> > > >>> 5. Because of the chunk bundling function of SCTP, > reliable and > > >>> unreliable messages can be multiplexed over a > single PR-SCTP > > >>> association. Therefore, the number of IP datagrams > > >>> > > >>> > > >>(and hence > > >> > > >> > > >>> the network overhead) can be reduced versus having > > >>> > > >>> > > >>to send these > > >> > > >> > > >>> different types of data using separate protocols. > > >>> > > >>> > > >>Additionally, > > >> > > >> > > >>> this multiplexing allows for port savings versus > > >>> > > >>> > > >>using different > > >> > > >> > > >>> ports for reliable and unreliable connections. > > >>> > > >>>---------- > > >>> > > >>>PR-SCTP has the option of being able to configure the > > >>> > > >>> > > >>exporter to work > > >> > > >> > > >>>on a > > >>>best effort data export basis, rather than being > > >>> > > >>> > > >>constrained to work on a > > >> > > >> > > >>>reliable basis. > > >>> > > >>>We should spend some time thinking about the behaviour we > > >>> > > >>> > > >>want in the > > >> > > >> > > >>>exporter when the network is congested, perhaps due to an > > >>> > > >>> > > >>attack. PR-SCTP > > >> > > >> > > >>>gives us the option of running a best effort data > > >>> > > >>> > > >>collection to gleen > > >> > > >> > > >>>what > > >>>is going on, when a TCP based exporter would otherwise > > >>> > > >>> > > >>collapse due to > > >> > > >> > > >>>backlog on the exporter. > > >>> > > >>>Stewart > > >>> > > >>> > > >>> > > >>> > > >>>-- > > >>>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 Oct 10 13:56:47 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 NAA09771 for ; Fri, 10 Oct 2003 13:56:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A81HQ-0002Vw-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 12:42:20 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A81HP-0002Vr-00 for ipfix@net.doit.wisc.edu; Fri, 10 Oct 2003 12:42:19 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 9D8B41C01943; Fri, 10 Oct 2003 13:42:18 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 978471C000AA; Fri, 10 Oct 2003 13:42:18 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4LQQ22V8>; Fri, 10 Oct 2003 13:42:18 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296038C@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Randy Bush'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Fri, 10 Oct 2003 13:42:03 -0400 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 Randy, Thanks for the pointer. RFC 2309 seems like some well reasoned arguments against UDP traffic which is travelling through routers in the internet, or utilizing "shared links". Certainly some applications of IPFIX would follow this profile, so clearly UDP is NOT sufficient. However, in a situation where a middlebox has multiple ports and a collection system has a direct wired connection to such a port on this device, it would seem the behavior cited in the RFC is irrelevant. Just so I'm clear, is the intent that all references to mapping the protocol messages defined in IPFIX to UDP be expunged? I.e. take away something which currently serves a broad community of users? Perhaps we should add the following wording to the protocol spec: Although this protocol was designed initially to run on UDP and the message set maps well to this transport; and although it may be tempting to use this in certain controlled environments for which RFC 2309 has no bearing; an implementation SHALL NOT use UDP. That would capture the arguments I've seen to date, and we can move on... Combine this with a strict mapping to PR-SCTP, and disallow TCP, and you have the perfect paper spec that will address an extremely narrow audience! Regards, Jeff Meyer > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, October 09, 2003 12:15 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] STCP as a default transport not > > > > I'm sorry, perhaps I missed the well reasoned argument against the > > use of UDP on point to point connections? > > > > Could you direct me to that. > > http://ipfx.doit.wisc.edu/list/ipfix/archive/ > > and you may want to review RFC 2309, particularly section 4 > > randy > -- 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 Oct 10 14:13: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 OAA10448 for ; Fri, 10 Oct 2003 14:13:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A81dc-0003F2-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 13:05:16 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A81db-0003Ex-00 for ipfix@net.doit.wisc.edu; Fri, 10 Oct 2003 13:05:15 -0500 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id A91F41C0304A; Fri, 10 Oct 2003 14:05:14 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 9D14D1C00091; Fri, 10 Oct 2003 14:05:14 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4QSG3K2J>; Fri, 10 Oct 2003 14:05:14 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296038F@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Benoit Claise'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Tal Givoly'" , stbryant@cisco.com, Maurizio Molina , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Date: Fri, 10 Oct 2003 14:05:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38F58.04177FAE" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38F58.04177FAE Content-Type: text/plain; charset="iso-8859-1" Benoit, Adding these three information items to the Info Model sounds fine. What is the rollover and reset behavior of these counters? E.g. when an observer is started due to reboot or other administrative action the counters are set to zero. Is there a way to distinguish between a counter reset and rollover? Presumably these should be long's in the information model. Is there a practical lower bound on an implementation in terms of size, e.g. 32-bits? Also what are the triggers for these to be exported? Some timer, threshold, or unspecified operation? In any of these cases, is there a guarantee that there will not be > 1 rollover between exports? I would think most of these aspects should be captured in the information model. Hopefully they also illustrate some of the problematic behavior of dealing with counters, not insurmountable, but certainly irritating. Regards, Jeff Meyer -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Friday, October 10, 2003 4:11 AM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'Tal Givoly'; stbryant@cisco.com; Maurizio Molina; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] bytes and packet counters, tstamp of last report Hi, Hi, In some use cases counters may have desirable properties as Tal has described. But like many things, counters also have their limitations and downsides. In the basic Flow Export scenario which is exemplified by existing Netflow implementations, a flow record indicates a summary of observed behavior. Consider two flow events: sourceAddress=1.2.3.4 destinationAddress=1.2.3.5 packetCount=1000 byteCount=100000 flowCreationTime=2003-10-08T10:00:00Z flowEndTime=2003-10-08T10:00:05Z TcpControlBits=0x13 sourceAddress=1.2.3.4 destinationAddress=1.2.3.6 packetCount=1000 byteCount=200000 flowCreationTime=2003-10-08T10:00:02Z flowEndTime=2003-10-08T10:00:06Z TcpControlBits=0x13 Each of these completely describes a conversation, as it includes both the fin and syn TCP flags. Start time, end time and absolute counts. Given the large percentage of flows which when exported, describe a complete conversation, I don't see the advantage of using counters. I'm not even sure how one would propose the use of counters as an alternative. Would you require two records be sent for each flow (one with byteCounter and packetCounter=0 and another with the final value?) Since most flows can be represented by a single record, doubling the number of records to accomodate counters seems a bit odd. Counters also require the holding of state, which produces a much greater burden on the collector. Since the necessary state must be held by the observer, why double the workload? I.e. a single counter is pretty useless. I need to delta it against a previously observed matching counter to arrive at a quantity. For information models such as PSAMP, there may be a compelling use case. So I imagine adding an explicit annotation in the information model for counters would be worthwile. However, I think that counter behavior such as when it is zeroed out and its rollover behavior need to be appropriately documented and thought out. (e.g. on restart, the counters presumably reset to zero, so here is additional state a collector may need to monitor to reconcile (if possible) existing observations). For IPFIX's base information model, I would strongly discourage "fixing" something which isn't broken. I fully agree with Jeff here regarding the flow records but there are actually 2 aspects to this problem. 1. The flow record. There is an expiration process for the flow records. http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt 4.1 Flow Expiration A Flow is considered to be inactive if no packets belonging to the Flow have been observed at the Observation Point for a given timeout interval otherwise it is considered as an active flow. A Flow can be exported under the following conditions: 1. If the Metering Process can detect the end of a Flow, it SHOULD export the Flow Records at the end of the Flow. For example, a Flow generated by TCP [3] type of traffic where the FIN or RST bits indicate the end of the Flow. 2. If the Flow has been inactive for a certain period of time. This inactivity timeout SHOULD be configurable, with a minimum value of 0 for an immediate expiration. For example, a Flow generated by UDP [2] type of traffic. 3. For long-lasting Flows, the Metering Process SHOULD export the Flow Records on a regular basis. This periodicity SHOULD be configurable. 4. If the Metering Process experiences internal constraints, a Flow MAY be forced to expire prematurely (for example, counters wrapping or low memory). What the IPFIX information model tries to say is that: a flow expires and we send the packet/byte count for the flow duration. So this is actually a running counter for the flow duration. Note: a long last flow is actually composed a several flows (see condition 3 before). Ok, I understand that this could be better explained in the IPFIX information model draft: The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt speaks of: Incoming counter with IN_BYTES 1 N length N x 8 bits for bytes associated with an IP Flow Incoming counter with IN_PKTS 2 N length N x 8 bits for packets associated with an IP Flow 2. The second aspect is actually total counters. Something that needs to added to the IPFIX protocol draft is described in its "open issues" section: - The proposal on the table is to send a IPFIX Sync (this would be an Options Data Records) message periodically (periodicity is configurable), with the following information (aside the standard IPFix header) * Number of flow records sent (for each template?) * Packets and bytes sent (for each template?) So we need to keep a few running counters. In http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt , there are explicitely described: Counter with length N x 8 bits for bytes TOTAL_BYTES_EXP 40 N for the number of bytes exported by the Observation Domain Counter with length N x 8 bits for bytes TOTAL_EXP_PKTS_SENT 41 N for the number of packets exported by the Observation Domain Counter with length N x 8 bits for bytes TOTAL_FLOWS_EXP 42 N for the number of Flows exported by the Observation Domain I propose to also explicitely described them in the IPFIX information model draft. Regards, Benoit. Regards, Jeff Meyer _________________________________________________________________ Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup -----Original Message----- From: majordomo listserver [ mailto:majordomo@mil.doit.wisc.edu ]On Behalf Of Tal Givoly Sent: Wednesday, October 08, 2003 9:14 AM To: stbryant@cisco.com ; Maurizio Molina Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Both counters have value (running and delta). Obviously, they must be kept discrete from an information model perspective as they represent different information. Devices sometimes maintain one, sometimes the other, and sometimes both. Just as an example, as far as I recall, NetFlow v5-8 doesn't maintain running counters (counter to your suggestion) EVEN THOUGH it operates over a non-reliable and non-congestion-aware transport. Our probe product emits both for various different purposes. Tal -----Original Message----- From: majordomo listserver [ mailto:majordomo@mil.doit.wisc.edu ]On Behalf Of Stewart Bryant Sent: Wednesday, October 08, 2003 8:09 AM To: Maurizio Molina Cc: ' ipfix@net.doit.wisc.edu ' Subject: Re: [ipfix] bytes and packet counters, tstamp of last report Maurizio Molina wrote: Hi, the IPFIX info model states (sec. 6.10) that The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. I would prefer that we only supported running counters because: a) Supporting two types is more scope for non-interworking, and you can always convert from one to the other at the collector. b) Running counters also work over an unreliable transport whereas delta counters mandate the use of a reliable transport. c) Running counters are most likely what the hardware is keeping anyway, therefore delta counters are more work and more storage at the exporter. If we decide that we need both then we have to represent them as two different information elements because the info model does not support sub-typing. Stewart (There's the same statement for byte counts in 6.11). To me, this doesn't clarify wheter it is both...and (2 counters) or either .... or (1 counter). Moreover, there is currently no room for a field containing the timestamp of the last report of a flow. I think that keeping this timestamp is helpful for many applications and the info model should support it. Regards, Maurizio -- 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/ ------_=_NextPart_001_01C38F58.04177FAE Content-Type: text/html; charset="iso-8859-1"
Benoit,
 
  Adding these three information items to the Info Model sounds fine. 
 
   What is the rollover and reset behavior of these counters?  E.g. when an observer is started due to reboot or other administrative action the counters are set to zero.  Is there a way to distinguish between a counter reset and rollover?
 
  Presumably these should be long's in the information model.  Is there a practical lower bound on an implementation in terms of size, e.g. 32-bits?
 
  Also what are the triggers for these to be exported?  Some timer, threshold, or unspecified operation?  In any of these cases, is there a guarantee that there will not be > 1 rollover between exports?
 
  I would think most of these aspects should be captured in the information model.  Hopefully they also illustrate some of the problematic behavior of dealing with counters, not insurmountable, but certainly irritating.
 
Regards,

  Jeff Meyer
-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, October 10, 2003 4:11 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Tal Givoly'; stbryant@cisco.com; Maurizio Molina; ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] bytes and packet counters, tstamp of last report

Hi,
Hi,


  In some use cases counters may have desirable properties as Tal
has described.  But like many things, counters also have their 
limitations and downsides.

  In the basic Flow Export scenario which is exemplified by existing
Netflow implementations, a flow record indicates a summary of
observed behavior.

  Consider two flow events:

      sourceAddress=1.2.3.4
      destinationAddress=1.2.3.5
      packetCount=1000
      byteCount=100000
      flowCreationTime=2003-10-08T10:00:00Z
      flowEndTime=2003-10-08T10:00:05Z
      TcpControlBits=0x13


      sourceAddress=1.2.3.4
      destinationAddress=1.2.3.6
      packetCount=1000
      byteCount=200000
      flowCreationTime=2003-10-08T10:00:02Z
      flowEndTime=2003-10-08T10:00:06Z
      TcpControlBits=0x13

  Each of these completely describes a conversation, as it includes both
  the fin and syn TCP flags.  Start time, end time and absolute counts.

  Given the large percentage of flows which when exported, describe a
  complete conversation, I don't see the advantage of using counters.

  I'm not even sure how one would propose the use of counters as an
  alternative.  Would you require two records be sent for each
  flow (one with byteCounter and packetCounter=0 and another with
  the final value?)

  Since most flows can be represented by a single record, doubling
  the number of records to accomodate counters seems a bit odd.
  Counters also require the holding of state, which produces
  a much greater burden on the collector.  Since the necessary
  state must be held by the observer, why double the workload?
  I.e. a single   counter is pretty useless.  I need to delta it
  against a previously observed matching counter to arrive at a
  quantity.


  For information models such as PSAMP, there may be a compelling
  use case.

  So I imagine adding an explicit annotation in the information
  model for counters would be worthwile.  However, I think that
  counter behavior such as when it is zeroed out and its rollover
  behavior need to be appropriately documented and thought out.
  (e.g. on restart, the counters presumably reset to zero, so
  here is additional state a collector may need to monitor to
  reconcile (if possible) existing observations).

  For IPFIX's base information model, I would strongly discourage
  "fixing" something which isn't broken.
I fully agree with Jeff here regarding the flow records but there are actually 2 aspects to this problem.

1.
The flow record.
There is an expiration process for the flow records.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt
4.1 Flow Expiration 
    
   A Flow is considered to be inactive if no packets belonging to the 
   Flow have been observed at the Observation Point for a given timeout 
   interval otherwise it is considered as an active flow.  
   A Flow can be exported under the following conditions: 
    
      1. If the Metering Process can detect the end of a Flow, it 
      SHOULD export the Flow Records at the end of the Flow. For 
      example, a Flow generated by TCP [3] type of traffic where the 
      FIN or RST bits indicate the end of the Flow. 
       
      2. If the Flow has been inactive for a certain period of time. 
      This inactivity timeout SHOULD be configurable, with a minimum 
      value of 0 for an immediate expiration. For example, a Flow 
      generated by UDP [2] type of traffic. 
       
      3. For long-lasting Flows, the Metering Process SHOULD export the 
      Flow Records on a regular basis. This periodicity SHOULD be 
      configurable. 
       
      4. If the Metering Process experiences internal constraints, a 
      Flow MAY be forced to expire prematurely (for example, counters 
      wrapping or low memory). 

What the IPFIX information model tries to say is that: a flow expires and we send the packet/byte count for the flow duration. So this is actually a running counter for the flow duration.
Note: a long last flow is actually composed a several flows (see condition 3 before). 
Ok, I understand that this could be better explained in the IPFIX information model draft:
   The packet count can be a running counter and is the count from the
   beginning of the flow establishment.
   The packet count can be a delta counter and is the count since the
   last report for this flow.


http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt speaks of:
                                            Incoming counter with  
    IN_BYTES                     1    N     length N x 8 bits for bytes  
                                            associated with an IP Flow    
 
                                            Incoming counter with  
    IN_PKTS                      2    N     length N x 8 bits for  
                                            packets associated 
                                            with an IP Flow  

2. 
The second aspect is actually total counters.
Something that needs to added to the IPFIX protocol draft is described in its "open issues" section:
   - The proposal on the table is to send a IPFIX Sync (this would be 
   an Options Data Records) message periodically (periodicity is 
   configurable), with the following information (aside the standard 
   IPFix header) 
           * Number of flow records sent (for each template?)  
           * Packets and bytes sent (for each template?) 

So we need to keep a few running counters.

In http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt, there are explicitely described:
                                            Counter with length   
                                            N x 8 bits for bytes 
    TOTAL_BYTES_EXP              40   N     for the number of bytes  
                                            exported by the Observation 
                                            Domain 
 
                                            Counter with length  
                                            N x 8 bits for bytes  
    TOTAL_EXP_PKTS_SENT          41   N     for the number of packets  
                                            exported by the Observation  
                                            Domain  
 
                                            Counter with length  
                                            N x 8 bits for bytes  
    TOTAL_FLOWS_EXP              42   N     for the number of Flows  
                                            exported by the Observation  
                                            Domain

I propose to also explicitely described them in the IPFIX information model draft.

Regards, Benoit.


Regards,

  Jeff Meyer

_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month.  Limited time offer--

sign up now!   http://join.msn.com/?page=dept/dialup

  
-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Tal Givoly
Sent: Wednesday, October 08, 2003 9:14 AM
To: stbryant@cisco.com; Maurizio Molina
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] bytes and packet counters, tstamp of last report


Both counters have value (running and delta). Obviously, they 
must be kept
discrete from an information model perspective as they 
represent different
information. Devices sometimes maintain one, sometimes the other, and
sometimes both. Just as an example, as far as I recall, 
NetFlow v5-8 doesn't
maintain running counters (counter to your suggestion) EVEN THOUGH it
operates over a non-reliable and non-congestion-aware 
transport. Our probe
product emits both for various different purposes.

Tal

-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Stewart Bryant
Sent: Wednesday, October 08, 2003 8:09 AM
To: Maurizio Molina
Cc: 'ipfix@net.doit.wisc.edu'
Subject: Re: [ipfix] bytes and packet counters, tstamp of last report




Maurizio Molina wrote:

    
Hi,
the IPFIX info model states (sec. 6.10) that

   The packet count can be a running counter and is the 
      
count from the
    
  beginning of the flow establishment.

  The packet count can be a delta counter and is the count since the
  last report for this flow.

      
I would prefer that we only supported running counters because:

a) Supporting two types is more scope for non-interworking, and
    you can always convert from one to the other at the collector.

b) Running counters also work over an unreliable transport
    whereas delta counters mandate the use of a reliable transport.

c) Running counters are most likely what the hardware is keeping
    anyway, therefore delta counters are more work and more storage
    at the exporter.

If we decide that we need both then we have to represent them
as two different information elements because the info model does
not support sub-typing.

Stewart

    
(There's the same statement for byte counts in 6.11).

To me, this doesn't clarify wheter it is both...and  (2 counters) or
either .... or (1 counter).

Moreover, there is currently no room for a field containing the
timestamp of the last report of a flow. I think that keeping this
timestamp is helpful for many applications and the info model should
support it.
Regards,
Maurizio



--
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/

------_=_NextPart_001_01C38F58.04177FAE-- -- 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 Oct 10 14:45: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 OAA11651 for ; Fri, 10 Oct 2003 14:45:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A827e-0004GD-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Oct 2003 13:36:18 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A827c-0004G7-00 for ipfix@net.doit.wisc.edu; Fri, 10 Oct 2003 13:36:16 -0500 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id DB7011C026D0; Fri, 10 Oct 2003 14:36:15 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id CF5C41C0008D; Fri, 10 Oct 2003 14:36:15 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4S0G82RF>; Fri, 10 Oct 2003 14:36:15 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960391@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'Benoit Claise'" Cc: "'Tal Givoly'" , "'stbryant@cisco.com'" , "'Maurizio Molina'" , "'ipfix@net.doit.wisc.edu'" Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Date: Fri, 10 Oct 2003 14:36:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38F5D.604647D8" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38F5D.604647D8 Content-Type: text/plain; charset="iso-8859-1" Benoit, One other point on your e-mail. In your discussion of "Long lived flows", are you saying that if an observed connection lasts say 5 minutes, and through configuration the system will export a long lived flow after 3 minutes of activity, that the second flow record's numbytes is measured from the beginning of the flow (e..g it represents period t,t+5m vs. t+3m,t+5m, where t is the actual start time of the long lived flow). I would have thought that the second record would indicate flow properties SINCE any previous flow record. That was the revised wording I had suggested based on Maurizio's observation of ambiguity. If you are saying that the second exported flow for a long lived connection is cumulative, then you've created a rather dicey problem. Especially if a collection system is doing aggregation of these flows. Because instead of a flow being a discrete self-contained piece of information, one must now determine if it actually represents additional counts added to flows previously reported. If so this sets you up to have to search an ENORMOUS space of old flows to do delta calculations. My impression of traditional NFvX behavior is that exporting a flow effectively pops it out of the flow table. Any subsequent traffic for the same flow would first create a new flow entry and the counters effectively reset each time a flow is exported. Here is the current Cisco documentation: http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuratio n_guide_chapter09186a008019d0da.html Configuring Netflow Aging Parameters You can control when flows are purged from the software flow cache (and, if configured, reported through NDE) with the configuration aging parameters, Active and Inactive, of the ip flow-cache timeout command. wp1011379Active Aging specifies the period of time in which a flow should be removed from the software flow cache after the flow is created. Generally, this parameter is used to periodically notify external collection devices about active flows. This parameter operates independently of existing traffic on the flow. Active timeout settings tend to be on the order of minutes (default is 30min). My reading here is that exporting and purging are one in the same. I.e. I never get a flow which may reflect counts which were already reported in a previous flow. Are you proposing changing this behavior? If so, this has significant deliterious impact on collection. I would not recommend changing. Regards, Jeff Meyer -----Original Message----- From: MEYER,JEFFREY D (HP-Cupertino,ex1) Sent: Friday, October 10, 2003 11:05 AM To: 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'Tal Givoly'; stbryant@cisco.com; Maurizio Molina; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Benoit, Adding these three information items to the Info Model sounds fine. What is the rollover and reset behavior of these counters? E.g. when an observer is started due to reboot or other administrative action the counters are set to zero. Is there a way to distinguish between a counter reset and rollover? Presumably these should be long's in the information model. Is there a practical lower bound on an implementation in terms of size, e.g. 32-bits? Also what are the triggers for these to be exported? Some timer, threshold, or unspecified operation? In any of these cases, is there a guarantee that there will not be > 1 rollover between exports? I would think most of these aspects should be captured in the information model. Hopefully they also illustrate some of the problematic behavior of dealing with counters, not insurmountable, but certainly irritating. Regards, Jeff Meyer -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Friday, October 10, 2003 4:11 AM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'Tal Givoly'; stbryant@cisco.com; Maurizio Molina; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] bytes and packet counters, tstamp of last report Hi, Hi, In some use cases counters may have desirable properties as Tal has described. But like many things, counters also have their limitations and downsides. In the basic Flow Export scenario which is exemplified by existing Netflow implementations, a flow record indicates a summary of observed behavior. Consider two flow events: sourceAddress=1.2.3.4 destinationAddress=1.2.3.5 packetCount=1000 byteCount=100000 flowCreationTime=2003-10-08T10:00:00Z flowEndTime=2003-10-08T10:00:05Z TcpControlBits=0x13 sourceAddress=1.2.3.4 destinationAddress=1.2.3.6 packetCount=1000 byteCount=200000 flowCreationTime=2003-10-08T10:00:02Z flowEndTime=2003-10-08T10:00:06Z TcpControlBits=0x13 Each of these completely describes a conversation, as it includes both the fin and syn TCP flags. Start time, end time and absolute counts. Given the large percentage of flows which when exported, describe a complete conversation, I don't see the advantage of using counters. I'm not even sure how one would propose the use of counters as an alternative. Would you require two records be sent for each flow (one with byteCounter and packetCounter=0 and another with the final value?) Since most flows can be represented by a single record, doubling the number of records to accomodate counters seems a bit odd. Counters also require the holding of state, which produces a much greater burden on the collector. Since the necessary state must be held by the observer, why double the workload? I.e. a single counter is pretty useless. I need to delta it against a previously observed matching counter to arrive at a quantity. For information models such as PSAMP, there may be a compelling use case. So I imagine adding an explicit annotation in the information model for counters would be worthwile. However, I think that counter behavior such as when it is zeroed out and its rollover behavior need to be appropriately documented and thought out. (e.g. on restart, the counters presumably reset to zero, so here is additional state a collector may need to monitor to reconcile (if possible) existing observations). For IPFIX's base information model, I would strongly discourage "fixing" something which isn't broken. I fully agree with Jeff here regarding the flow records but there are actually 2 aspects to this problem. 1. The flow record. There is an expiration process for the flow records. http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt 4.1 Flow Expiration A Flow is considered to be inactive if no packets belonging to the Flow have been observed at the Observation Point for a given timeout interval otherwise it is considered as an active flow. A Flow can be exported under the following conditions: 1. If the Metering Process can detect the end of a Flow, it SHOULD export the Flow Records at the end of the Flow. For example, a Flow generated by TCP [3] type of traffic where the FIN or RST bits indicate the end of the Flow. 2. If the Flow has been inactive for a certain period of time. This inactivity timeout SHOULD be configurable, with a minimum value of 0 for an immediate expiration. For example, a Flow generated by UDP [2] type of traffic. 3. For long-lasting Flows, the Metering Process SHOULD export the Flow Records on a regular basis. This periodicity SHOULD be configurable. 4. If the Metering Process experiences internal constraints, a Flow MAY be forced to expire prematurely (for example, counters wrapping or low memory). What the IPFIX information model tries to say is that: a flow expires and we send the packet/byte count for the flow duration. So this is actually a running counter for the flow duration. Note: a long last flow is actually composed a several flows (see condition 3 before). Ok, I understand that this could be better explained in the IPFIX information model draft: The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt speaks of: Incoming counter with IN_BYTES 1 N length N x 8 bits for bytes associated with an IP Flow Incoming counter with IN_PKTS 2 N length N x 8 bits for packets associated with an IP Flow 2. The second aspect is actually total counters. Something that needs to added to the IPFIX protocol draft is described in its "open issues" section: - The proposal on the table is to send a IPFIX Sync (this would be an Options Data Records) message periodically (periodicity is configurable), with the following information (aside the standard IPFix header) * Number of flow records sent (for each template?) * Packets and bytes sent (for each template?) So we need to keep a few running counters. In http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt , there are explicitely described: Counter with length N x 8 bits for bytes TOTAL_BYTES_EXP 40 N for the number of bytes exported by the Observation Domain Counter with length N x 8 bits for bytes TOTAL_EXP_PKTS_SENT 41 N for the number of packets exported by the Observation Domain Counter with length N x 8 bits for bytes TOTAL_FLOWS_EXP 42 N for the number of Flows exported by the Observation Domain I propose to also explicitely described them in the IPFIX information model draft. Regards, Benoit. Regards, Jeff Meyer _________________________________________________________________ Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup -----Original Message----- From: majordomo listserver [ mailto:majordomo@mil.doit.wisc.edu ]On Behalf Of Tal Givoly Sent: Wednesday, October 08, 2003 9:14 AM To: stbryant@cisco.com ; Maurizio Molina Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] bytes and packet counters, tstamp of last report Both counters have value (running and delta). Obviously, they must be kept discrete from an information model perspective as they represent different information. Devices sometimes maintain one, sometimes the other, and sometimes both. Just as an example, as far as I recall, NetFlow v5-8 doesn't maintain running counters (counter to your suggestion) EVEN THOUGH it operates over a non-reliable and non-congestion-aware transport. Our probe product emits both for various different purposes. Tal -----Original Message----- From: majordomo listserver [ mailto:majordomo@mil.doit.wisc.edu ]On Behalf Of Stewart Bryant Sent: Wednesday, October 08, 2003 8:09 AM To: Maurizio Molina Cc: ' ipfix@net.doit.wisc.edu ' Subject: Re: [ipfix] bytes and packet counters, tstamp of last report Maurizio Molina wrote: Hi, the IPFIX info model states (sec. 6.10) that The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. I would prefer that we only supported running counters because: a) Supporting two types is more scope for non-interworking, and you can always convert from one to the other at the collector. b) Running counters also work over an unreliable transport whereas delta counters mandate the use of a reliable transport. c) Running counters are most likely what the hardware is keeping anyway, therefore delta counters are more work and more storage at the exporter. If we decide that we need both then we have to represent them as two different information elements because the info model does not support sub-typing. Stewart (There's the same statement for byte counts in 6.11). To me, this doesn't clarify wheter it is both...and (2 counters) or either .... or (1 counter). Moreover, there is currently no room for a field containing the timestamp of the last report of a flow. I think that keeping this timestamp is helpful for many applications and the info model should support it. Regards, Maurizio -- 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/ ------_=_NextPart_001_01C38F5D.604647D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Benoit,
 
 =20 One other point on your e-mail.  In your discussion of "Long lived = flows",=20 are you saying that if an observed connection lasts say 5 minutes, and = through=20 configuration the system will export a long lived flow after 3 minutes = of=20 activity, that the second flow record's numbytes is measured from the = beginning=20 of the flow (e..g it represents period t,t+5m vs. t+3m,t+5m, where t is = the=20 actual start time of the long lived flow).
 
 =20 I would have thought that the second record would indicate flow = properties SINCE=20 any previous flow record.  That was the revised wording I had = suggested=20 based on Maurizio's observation of ambiguity.
 
 =20 If you are saying that the second exported flow for a long lived = connection is=20 cumulative, then you've created a rather dicey problem.  = Especially if a=20 collection system is doing aggregation of these flows.  Because = instead of=20 a flow being a discrete self-contained piece of information, one must = now=20 determine if it actually represents additional counts added to flows = previously=20 reported.  If so this sets you up to have to search an ENORMOUS = space of=20 old flows to do delta calculations.
 
 =20 My impression of traditional NFvX behavior is that exporting a flow = effectively=20 pops it out of the flow table.  Any subsequent traffic for the = same flow=20 would first create a new flow entry and the counters effectively reset = each time=20 a flow is exported.  Here is the current Cisco=20 documentation:
 
 =20 http://www.cisco.com/e= n/US/products/hw/switches/ps4324/products_configuration_guide_chapter091= 86a008019d0da.html
Configuring Netflow=20 Aging Parameters
 
You can=20 control when flows are purged from the software flow cache (and, if=20 configured, reported through NDE) with the configuration aging = parameters,=20 Active and Inactive, of the ip=20 flow-cache timeout command.

Active=20 Aging specifies the period of time in which a flow should be removed = from the=20 software flow cache after the flow is created. Generally, this = parameter is=20 used to periodically notify external collection devices about active = flows.=20 This parameter operates independently of existing traffic on the = flow. Active=20 timeout settings tend to be on the order of minutes (default is = 30min). =

 =20 My reading here is that exporting and purging are one in the = same.  I.e. I=20 never get a flow which may reflect counts which were already reported = in a=20 previous flow.
 
 =20 Are you proposing changing this behavior?  If so, this has = significant=20 deliterious impact on collection.  I would not recommend=20 changing.
 
Regards,
 
 =20 Jeff Meyer
-----Original Message-----
From: MEYER,JEFFREY D=20 (HP-Cupertino,ex1)
Sent: Friday, October 10, 2003 11:05=20 AM
To: 'Benoit Claise'; MEYER,JEFFREY D=20 (HP-Cupertino,ex1)
Cc: 'Tal Givoly'; stbryant@cisco.com; = Maurizio=20 Molina; ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] bytes = and=20 packet counters, tstamp of last report

Benoit,
 
  Adding these three information items to the Info = Model sounds=20 fine. 
 
   What is the rollover and reset behavior of = these=20 counters?  E.g. when an observer is started due to reboot or = other=20 administrative action the counters are set to zero.  Is there a = way to=20 distinguish between a counter reset and rollover?
 
  Presumably these should be long's in the information=20 model.  Is there a practical lower bound on an implementation in = terms of=20 size, e.g. 32-bits?
 
  Also what are the triggers for these to be = exported?  Some=20 timer, threshold, or unspecified operation?  In any of these = cases, is=20 there a guarantee that there will not be > 1 rollover = between=20 exports?
 
  I would think most of these aspects should be = captured in the=20 information model.  Hopefully they also illustrate some of the=20 problematic behavior of dealing with counters, not insurmountable, = but=20 certainly irritating.
 
Regards,

  Jeff Meyer
-----Original Message-----
From: Benoit Claise=20 [mailto:bclaise@cisco.com]
Sent: Friday, October 10, 2003 = 4:11=20 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: = 'Tal=20 Givoly'; stbryant@cisco.com; Maurizio Molina;=20 ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] bytes and = packet=20 counters, tstamp of last report

Hi,
Hi,


  In some use cases counters may have desirable properties as Tal
has described.  But like many things, counters also have their=20
limitations and downsides.

  In the basic Flow Export scenario which is exemplified by existing
Netflow implementations, a flow record indicates a summary of
observed behavior.

  Consider two flow events:

      sourceAddress=3D1.2.3.4
      destinationAddress=3D1.2.3.5
      packetCount=3D1000
      byteCount=3D100000
      flowCreationTime=3D2003-10-08T10:00:00Z
      flowEndTime=3D2003-10-08T10:00:05Z
      TcpControlBits=3D0x13


      sourceAddress=3D1.2.3.4
      destinationAddress=3D1.2.3.6
      packetCount=3D1000
      byteCount=3D200000
      flowCreationTime=3D2003-10-08T10:00:02Z
      flowEndTime=3D2003-10-08T10:00:06Z
      TcpControlBits=3D0x13

  Each of these completely describes a conversation, as it includes =
both
  the fin and syn TCP flags.  Start time, end time and absolute counts.

  Given the large percentage of flows which when exported, describe a
  complete conversation, I don't see the advantage of using counters.

  I'm not even sure how one would propose the use of counters as an
  alternative.  Would you require two records be sent for each
  flow (one with byteCounter and packetCounter=3D0 and another with
  the final value?)

  Since most flows can be represented by a single record, doubling
  the number of records to accomodate counters seems a bit odd.
  Counters also require the holding of state, which produces
  a much greater burden on the collector.  Since the necessary
  state must be held by the observer, why double the workload?
  I.e. a single   counter is pretty useless.  I need to delta it
  against a previously observed matching counter to arrive at a
  quantity.


  For information models such as PSAMP, there may be a compelling
  use case.

  So I imagine adding an explicit annotation in the information
  model for counters would be worthwile.  However, I think that
  counter behavior such as when it is zeroed out and its rollover
  behavior need to be appropriately documented and thought out.
  (e.g. on restart, the counters presumably reset to zero, so
  here is additional state a collector may need to monitor to
  reconcile (if possible) existing observations).

  For IPFIX's base information model, I would strongly discourage
  "fixing" something which isn't broken.
I fully = agree=20 with Jeff here regarding the flow records but there are actually 2 = aspects=20 to this problem.

1.
The flow record.
There is an = expiration=20 process for the flow records.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.= txt
4.1 Flow Expiration=20
   =20
   A Flow is considered to be inactive if no packets belonging to the=20
   Flow have been observed at the Observation Point for a given timeout =

   interval otherwise it is considered as an active flow. =20
   A Flow can be exported under the following conditions:=20
   =20
      1. If the Metering Process can detect the end of a Flow, it=20
      SHOULD export the Flow Records at the end of the Flow. For=20
      example, a Flow generated by TCP [3] type of traffic where the=20
      FIN or RST bits indicate the end of the Flow.=20
      =20
      2. If the Flow has been inactive for a certain period of time.=20
      This inactivity timeout SHOULD be configurable, with a minimum=20
      value of 0 for an immediate expiration. For example, a Flow=20
      generated by UDP [2] type of traffic.=20
      =20
      3. For long-lasting Flows, the Metering Process SHOULD export the =

      Flow Records on a regular basis. This periodicity SHOULD be=20
      configurable.=20
      =20
      4. If the Metering Process experiences internal constraints, a=20
      Flow MAY be forced to expire prematurely (for example, counters=20
      wrapping or low memory).=20

What the IPFIX information model tries to say is that: a flow expires =
and we send the packet/byte count for the flow duration. So this is =
actually a running counter for the flow duration.
Note: a long last flow is actually composed a several flows (see =
condition 3 before).=20
Ok, I understand that this could be better explained in the IPFIX =
information model draft:
   The packet count can be a running counter and is the count =
from the
   beginning of the flow establishment.
   The packet count can be a delta counter and is the count since =
the
   last report for this flow.


http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt=
 speaks of:
                                            Incoming counter with =20
    IN_BYTES                     1    N     length N x 8 bits for bytes =
=20
                                            associated with an IP Flow  =
 =20
=20
                                            Incoming counter with =20
    IN_PKTS                      2    N     length N x 8 bits for =20
                                            packets associated=20
                                            with an IP Flow =20

2.=20
The second aspect is actually total counters.
Something that needs to added to the IPFIX protocol draft is described =
in its "open issues" section:
   - The proposal on the table is to send a IPFIX Sync (this would be=20
   an Options Data Records) message periodically (periodicity is=20
   configurable), with the following information (aside the standard=20
   IPFix header)=20
           * Number of flow records sent (for each template?) =20
           * Packets and bytes sent (for each template?)=20

So we need to keep a few running counters.

In http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt=
, there are explicitely described:
                                            Counter with length  =20
                                            N x 8 bits for bytes=20
    TOTAL_BYTES_EXP              40   N     for the number of bytes =20
                                            exported by the Observation =

                                            Domain=20
=20
                                            Counter with length =20
                                            N x 8 bits for bytes =20
    TOTAL_EXP_PKTS_SENT          41   N     for the number of packets =20
                                            exported by the Observation =
=20
                                            Domain =20
=20
                                            Counter with length =20
                                            N x 8 bits for bytes =20
    TOTAL_FLOWS_EXP              42   N     for the number of Flows =20
                                            exported by the Observation =
=20
                                            Domain =20

I propose to also explicitely described them in the IPFIX=20 information model draft.

Regards, Benoit.

Regards,

  Jeff Meyer

_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month.  Limited time =
offer--

sign up now!   http://join.msn.com/?pa=
ge=3Ddept/dialup

  
-----Original =
Message-----
From: majordomo listserver=20
[mailto:majordomo@mil.doit.wi=
sc.edu]On Behalf
Of Tal Givoly
Sent: Wednesday, October 08, 2003 9:14 AM
To: stbryant@cisco.com; Maurizio =
Molina
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] bytes and packet counters, tstamp of last report


Both counters have value (running and delta). Obviously, they=20
must be kept
discrete from an information model perspective as they=20
represent different
information. Devices sometimes maintain one, sometimes the other, and
sometimes both. Just as an example, as far as I recall,=20
NetFlow v5-8 doesn't
maintain running counters (counter to your suggestion) EVEN THOUGH it
operates over a non-reliable and non-congestion-aware=20
transport. Our probe
product emits both for various different purposes.

Tal

-----Original Message-----
From: majordomo listserver=20
[mailto:majordomo@mil.doit.wi=
sc.edu]On Behalf
Of Stewart Bryant
Sent: Wednesday, October 08, 2003 8:09 AM
To: Maurizio Molina
Cc: 'ipfix@net.doit.wisc.edu'
Subject: Re: [ipfix] bytes and packet counters, tstamp of last report




Maurizio Molina wrote:

    
Hi,
the IPFIX info model states (sec. 6.10) that

   The packet count can be a running counter and is the=20
      
count from the
    
  beginning of the =
flow establishment.

  The packet count can be a delta counter and is the count since the
  last report for this flow.

      
I would prefer that we only =
supported running counters because:

a) Supporting two types is more scope for non-interworking, and
    you can always convert from one to the other at the collector.

b) Running counters also work over an unreliable transport
    whereas delta counters mandate the use of a reliable transport.

c) Running counters are most likely what the hardware is keeping
    anyway, therefore delta counters are more work and more storage
    at the exporter.

If we decide that we need both then we have to represent them
as two different information elements because the info model does
not support sub-typing.

Stewart

    
(There's the same =
statement for byte counts in 6.11).

To me, this doesn't clarify wheter it is both...and  (2 counters) or
either .... or (1 counter).

Moreover, there is currently no room for a field containing the
timestamp of the last report of a flow. I think that keeping this
timestamp is helpful for many applications and the info model should
support it.
Regards,
Maurizio



--
Help        mailto:majordomo@net.doit.wi=
sc.edu and say=20
      
"help" in message
    
body
Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/=
archive/


      
--
Help        mailto:majordomo@net.doit.wi=
sc.edu and say "help"=20
in message
body
Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/=
archive/


--
Help        mailto:majordomo@net.doit.wi=
sc.edu and say "help"=20
in message body
Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/=
archive/

    

--
Help        mailto:majordomo@net.doit.wi=
sc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/=
archive/

------_=_NextPart_001_01C38F5D.604647D8-- -- 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 Sat Oct 11 10:09: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 KAA03166 for ; Sat, 11 Oct 2003 10:09:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8K7S-0006z8-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 08:49:18 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8K7R-0006yT-00 for ipfix@net.doit.wisc.edu; Sat, 11 Oct 2003 08:49:17 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8K7Q-000Jzk-H9; Sat, 11 Oct 2003 13:49:16 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8K7P-000L3M-Pm; Sat, 11 Oct 2003 06:49:15 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 11 Oct 2003 06:49:15 -0700 To: Nevil Brownlee Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6B1@ptah.newyork.qosient.com> <1065736364.4336dedb83483@hotlava.auckland.ac.nz> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > The WG issue which we opened at the Vienna meeting was "what should we > specify as a *default* transport for IPFIX?" i suggest it be phrased as "mandatory to implement," so you can be sure it is there. if one knows *for sure* one is in special circumstances, e.g. on a local wire, one might use optional transports. but the congestion-friendly transport is mandatory to implement and the default. randy -- 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 Sat Oct 11 19:54:26 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 TAA17586 for ; Sat, 11 Oct 2003 19:54:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8TAp-0007m2-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 18:29:23 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8TAn-0007ll-00; Sat, 11 Oct 2003 18:29:21 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9BNTE5R027313; Sat, 11 Oct 2003 16:29:14 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16454; Sat, 11 Oct 2003 16:29:11 -0700 (PDT) Message-ID: <3F889246.3000106@cisco.com> Date: Sat, 11 Oct 2003 18:29:10 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reinaldo Penno CC: "'alex.audu@alcatel.com'" , carter@qosient.com, "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" , stbryant@cisco.com, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <0A11633F61BD9F40B43ABCC694004F930218F28A@zsc3c026.us.nortel.com> In-Reply-To: <0A11633F61BD9F40B43ABCC694004F930218F28A@zsc3c026.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > I have a question in - multi-homing support. > > My original idea is that SCTP would bring value in reliability because > a exporter could make a connection to exporter A and if it finds that > connection has problems, switch to a totally separate collector B. > > Reading the excerpt below, it seems SCTP can only make the failover > when the two interfaces are on the same device, i.e., under the > control of the same SCTP stack I guess. > > "This capability can be used to build redundant paths between two SCTP > endpoints....Achieving path redundancy between two SCTP endpoints > normally requires that the two endpoints being equipped with multiple > interfaces assigned with multiple addresses and that routing is > configured appropriately" > > In this case it seems to me SCTP would not bring real value at least > in reliability) since the main concern is being able to switch from > collector A to collector B, where A and B are different devices > altogether. > > Could you clarify? > Reinaldo: a comment or two.. While it is true that SCTP does NOT help with switching to collector A to collector B transparently.. it does allow the failure to be controled in a MUCH more reasonalbe maner than TCP. Basically there are knobs that you, the application designer, can tweak to set the failover detection time to what you want it to be... this is something that is nearly impossible in most TCP stacks... SCTP was designed with this sort of thing in mind ... tuneable to the applications failure detections specific needs... This can be a big win.. multi-homing also may be more of a help then you think.. if billing information is being collected then you don't want an interface card failure to kill your association.. with SCTP this is taken care of without the app getting involvoed... it may be that some may not need this.. but it is a nice feeature to have for the app.. at no additional expense :> R > Thanks, > > Reinaldo > > > -----Original Message----- > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > Sent: Tuesday, October 07, 2003 10:56 AM > > To: carter@qosient.com > > Cc: Penno, Reinaldo [BL60:SF30:EXCH]; 'MEYER,JEFFREY D > > (HP-Cupertino,ex1)'; stbryant@cisco.com; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Hello Carter, > > > > This excerpt from rfc 3257 indicates SCTP can be used in > > place of TCP. Moreover, SCTP makes it easier to design a more > > reliable system due to its multi-homing and multiple > > streams-per-assoication features. This works well for a > > redundant (carrier grade) IPFIX architecture. Also, its > > message oriented feature makes it easier for the application > > to detect application message boundaries. > > > > It would be appreciated if you could point out technical > > reasons why SCTP is not a good solution for IPFIX. Otherwise, > > I vote for SCTP for IPFIX. > > > > Regards, > > Alex. > > > > ==================================================== > > > > 2.2 SCTP service model > > > > SCTP is also connection-oriented and provides all the transport > > services that TCP provides. Many Internet applications therefore > > should find that either TCP or SCTP will meet their transport > > requirements. Note, for applications conscious about processing > > cost, there might be a difference in processing cost > > associated with > > running SCTP with only a single ordered stream and one address pair > > in comparison to running TCP. > > > > However, SCTP has some additional capabilities that TCP lacks and > > This can make SCTP a better choice for some applications and > > environments: > > > > - multi-streams support: > > > > SCTP supports the delivery of multiple independent user message > > streams within a single SCTP association. This capability, when > > properly used, can alleviate the so-called head-of-line-blocking > > problem caused by the strict sequence delivery constraint > > imposed to > > the user data by TCP. > > > > This can be particularly useful for applications that need to > > exchange multiple, logically separate message streams between two > > endpoints. > > > > - multi-homing support: > > > > SCTP provides transparent support for communications between two > > endpoints of which one or both is multi-homed. > > > > SCTP provides monitoring of the reachability of the > > addresses on the > > remote endpoint and in the case of failure can > > transparently failover > > from the primary address to an alternate address, without > > upper layer > > intervention. > > > > This capability can be used to build redundant paths > > between two SCTP > > endpoints and can be particularly useful for applications that seek > > transport-level fault tolerance. > > > > Achieving path redundancy between two SCTP endpoints normally > > requires that the two endpoints being equipped with multiple > > interfaces assigned with multiple addresses and that routing is > > configured appropriately (see Section 3). > > > > - preservation of message boundaries: > > > > SCTP preserves application messages boundaries. This is > > useful when > > the application data is not a continuous byte stream but comes in > > logical chunks that the receiver handles separately. > > > > In contrast, TCP offers a reliable data stream that has no > > indication > > of what an application may consider logical chunks of the data. > > > > - unordered reliable message delivery: > > > > SCTP supports the transportation of user messages that have no > > application-specified order, yet need guaranteed reliable delivery. > > > > Applications that need to send un-ordered reliable > > messages or prefer > > using their own message sequencing and ordering mechanisms may find > > this SCTP capability useful. > > > > ===================================================== > > > > Carter Bullard wrote: > > > > > I am emphatically against any mention of SCTP, unless someone can > > > point out how the SCTP applicability statement, RFC 3257, > > applies to > > > IPFIX. > > > > > > Carter > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] > > > Sent: Monday, October 06, 2003 11:34 AM > > > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; > > > 'alex.audu@alcatel.com' > > > Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; > > > 'ipfix@net.doit.wisc.edu' > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > Okay... > > > It seems we haven't reached a (firm) conclusion, but we need to get > > > the draft going and this is a big piece of it. Jeff seems > > to propose > > > specifying both (TCP and SCTP). Anyone opposes this? Or should we > > > stick with one protocol mapping? We need to start > > converging on this > > > really soon. Thanks, > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) > > [mailto:jeff.meyer2@hp.com] > > > > Sent: Thursday, October 02, 2003 5:05 PM > > > > To: 'carter@qosient.com'; 'alex.audu@alcatel.com' > > > > Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; > > > > 'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' > > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > > > > I'd be interested in knowing what the specific aspects of > > SCTP are > > > > that the IPFIX protocol authors want to use, and how they > > do or do > > > > not conflict in some way with a parallel mapping to TCP. > > > > > > > > Taking the Diameter approach of specifying both TCP and > > SCTP would > > > > allow for the market to decide if ubiquity of availability or the > > > > special capabilities of SCTP are more important. > > > > > > > > -- Jeff > > > > > > > > > -----Original Message----- > > > > > From: Carter Bullard [mailto:carter@qosient.com] > > > > > Sent: Thursday, October 02, 2003 1:00 PM > > > > > To: alex.audu@alcatel.com > > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > Subject: RE: [ipfix] STCP as a default transport not > > > > > > > > > > > > > > > Hey Alex, > > > > > Did I say something wrong? I firmly believe that > > people adopt > > > > > technology when it solves problems. STCP will get around > > > > as its found > > > > > to be a real solution. But with regard to STCP and IPFIX, > > > > I read RFC > > > > > 3257, the SCTP Applicability Statement, and I don't see where > > > > > IPFIX fits. Benefits of SCTP over TCP are: > > > > > > > > > > multi-streams support > > > > > multi-homing support > > > > > preservation of message boundaries > > > > > unordered reliable message delivery > > > > > > > > > > The first three I don't see as requirements for IPFIX. > > > > > I actually believe the last one to be a problem for > > IPFIX. STCP is > > > > > less efficient that TCP, and so if IPFIX doesn't need any > > > > of these 4 > > > > > items, then I don't see the applicability. > > > > > > > > > > Carter > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > > > > > Sent: Thursday, October 02, 2003 2:51 PM > > > > > > To: carter@qosient.com > > > > > > Cc: stbryant@cisco.com; 'Reinaldo Penno'; > > > > > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > > > > > > > Hello Carter, > > > > > > > > > > > > If it is true that SCTP hasn't been widely deployed, it > > > > is probably > > > > > > because of statements like you have made below. Look, we all > > > > > > know SCTP has a lot of benefits over TCP. If folks like you > > > > don't drive > > > > > > its deployement > > > > > > by specifying it as default transport, how will it be > > > > > > ubiquitous? It is a self fulfilling prophesy. > > > > > > > > > > > > For IETF protocols that recommend SCTP as defaults, see rfc > > > > > > 3057, rfc 3331 and rfc 3332 just to name a few. > > > > > > > > > > > > Regards, > > > > > > Alex. > > > > > > > > > > > > Carter Bullard wrote: > > > > > > > > > > > > > I believe that SCTP-PR is not deployed widely enough to be > > > > > > > considered a default for any IETF technology. It is > > not on my > > > > > > > Linux RedHat 9.0 distribution, nor my Mac OS-X or > > my Windows > > > > > > > XP system. I don't see it > > > > available on > > > > > > > any Solaris machine that I have access to. > > > > > > > > > > > > > > What IETF technology is currently using SCTP as a default > > > > > > > transport? > > > > > > > > > > > > > > Carter > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: majordomo listserver > > > > [mailto:majordomo@mil.doit.wisc.edu] > > > > > > > > On Behalf Of Stewart Bryant > > > > > > > > Sent: Thursday, October 02, 2003 12:14 PM > > > > > > > > To: Reinaldo Penno > > > > > > > > Cc: ipfix-chairs@net.doit.wisc.edu; > > ipfix@net.doit.wisc.edu > > > > > > > > Subject: Re: [ipfix] Ipfix Protocol open items > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reinaldo Penno wrote: > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > Have we zeroed in a certain transport protocol? TCP, > > > > > SCTP-PR or > > > > > > > > > something else? > > > > > > > > > > > > > > > > > > I need to write something to explain how > > Netflow runs over > > > > > > > > TCP, but it > > > > > > > > > seems to me somewhat of a lower priority if this is not > > > > > > > > going to be the > > > > > > > > > default protocol. We should focus on explaning how this > > > > > > > > should work on > > > > > > > > > the "choosen one". > > > > > > > > > > > > > > > > I think that perhaps the question should be put another > > > > > > way. There are > > > > > > > > WG members who propose SCTP-PR as the default, and > > > > SCTP-PR has > > > > > > > > advantage because of its better flexibility in coping > > > > > > with congestion. > > > > > > > > > > > > > > > > So the real question is whether there are WG members who > > > > > > think that > > > > > > > > the default should be TCP. If no group comes forward, > > > > > then we have > > > > > > > > our answer. If there is support then we need to perform > > > > > a detailed > > > > > > > > analysis of the relative merits of the two protocols. > > > > > > > > > > > > > > > > Stewart > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > 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/ > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:02:03 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 UAA17926 for ; Sat, 11 Oct 2003 20:02:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8TG8-0000G7-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 18:34:52 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8TG7-0000Fz-00; Sat, 11 Oct 2003 18:34:51 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 16:43:41 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9BNYlUt025030; Sat, 11 Oct 2003 16:34:48 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16502; Sat, 11 Oct 2003 16:34:45 -0700 (PDT) Message-ID: <3F889395.5020706@cisco.com> Date: Sat, 11 Oct 2003 18:34:45 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: stbryant@cisco.com, "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6AB@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6AB@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter: Long before you get IPFIX into RFC PR-SCTP WILL be an RFC. It finished TSVWG last call quite some time ago.. and I have just recently corresponded with Jon Peterson (Chair of TSV and AD in transport).. he stated to me: >It will go to IESG last call >as soon as the AD review phase is complete. There are a few matters related >to this draft on which Allison and I still need to confer. I apologize for >the delay, and I anticipate that the draft will advance to IETF last call >shortly. > > > So unless you can get all of IPFIX finished in the next say.. three months or so I don't see how you could beat PR-SCTP to RFC status. Now as far as working implementations... In June at the bakeoff we had four interoperable implementations... and most of the others present planned on testing PR-SCTP at the next bakeoff (which will occur sometime early in 2004) Regards R Carter Bullard wrote: >Hey Stewart, >The default transport for a standards track protocol should >at least be an RFC. I'm not against having hooks to jumpstart >a PR-STCP association in IPFIX, but not as the default. And >those hooks should come after the PR-STCP is described >as an RFC and has had some time to bake, and possibly more >important, after there is a working IPFIX to find out if you >even need its features. > >As an internet draft its just an idea. > >Carter > > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Tuesday, October 07, 2003 10:13 AM >>To: alex.audu@alcatel.com >>Cc: carter@qosient.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D >>(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] STCP as a default transport not >> >> >> >>I think that the interest is in using PR-SCTP as described in >> >>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt >> >>rather than RFC 2960 SCTP. >> >>This claims the following benefits: >> >> >>1.3 Benefits of PR-SCTP >> >> Hereafter, we use the notation "PR-SCTP" to refer to the SCTP >> protocol extended as defined in this document. >> >> The following are some of the advantages for integrating partially >> reliable data service into SCTP, i.e., benefits of PR-SCTP: >> >> 1. Some application layer protocols may benefit from >>being able to >> use a single SCTP association to carry both reliable >>content, -- >> such as text pages, billing and accounting information, setup >> signaling -- and unreliable content, e.g. state that is highly >> sensitive to timeliness, where generating a new packet is more >> advantageous than transmitting an old one [1]. >> >> 2. Partially reliable data traffic carried by PR-SCTP >>will enjoy the >> same communication failure detection and protection >>capabilities >> as the normal reliable SCTP data traffic does. This >>includes the >> ability to: - quickly detect a failed destination address; - >> fail-over to an alternate destination address, and; - >>be notified >> if the data receiver becomes unreachable. >> >> 3. In addition to providing unordered unreliable data transfer as >> UDP does, PR-SCTP can provide ordered unreliable data transfer >> service. >> >> 4. PR-SCTP employs the same congestion control and congestion >> avoidance for all data traffic, whether reliable or partially >> reliable - this is very desirable since SCTP enforces >> TCP-friendliness (unlike UDP.) >> >> 5. Because of the chunk bundling function of SCTP, reliable and >> unreliable messages can be multiplexed over a single PR-SCTP >> association. Therefore, the number of IP datagrams (and hence >> the network overhead) can be reduced versus having to >>send these >> different types of data using separate protocols. >>Additionally, >> this multiplexing allows for port savings versus >>using different >> ports for reliable and unreliable connections. >> >>---------- >> >>PR-SCTP has the option of being able to configure the >>exporter to work on a >>best effort data export basis, rather than being constrained >>to work on a >>reliable basis. >> >>We should spend some time thinking about the behaviour we want in the >>exporter when the network is congested, perhaps due to an >>attack. PR-SCTP >>gives us the option of running a best effort data collection >>to gleen what >>is going on, when a TCP based exporter would otherwise collapse due to >>backlog on the exporter. >> >>Stewart >> >> >> >> >> > > > > >-- >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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:07:19 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 UAA18006 for ; Sat, 11 Oct 2003 20:07:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8TNi-0000RG-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 18:42:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8TNg-0000RA-00; Sat, 11 Oct 2003 18:42:40 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9BNgaUt027353; Sat, 11 Oct 2003 16:42:37 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16628; Sat, 11 Oct 2003 16:42:35 -0700 (PDT) Message-ID: <3F88956A.3060106@cisco.com> Date: Sat, 11 Oct 2003 18:42:34 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: stbryant@cisco.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6AC@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6AC@ptah.newyork.qosient.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: >Hey Stewart, > > >>We should spend some time thinking about the behavior we want in the >>exporter when the network is congested, perhaps due to an >>attack. PR-SCTP >>gives us the option of running a best effort data collection >>to gleen what >>is going on, when a TCP based exporter would otherwise collapse due to >>backlog on the exporter. >> >> > >This is a real engineering issue to talk about. Issues in producer/consumer >dynamics are real problems for IPFIX, especially when the flow record >source is generating 1M records per second, which my probes are capable >of doing. In my experience, the reader/collector not keeping up is >never a network congestion problem, it is almost always a reader/collector >resource problem, slow disks, not enough memory, competing processes, >whatever. It happens in SMP multi-threaded environments where the flow >generator and its collector are on the same machine, it happens when the >consumer is on the other end of a dedicated ATM, hyper-channel or >infiniband links. Its not an issue of reliable vs unreliable transport, >its more an issue of what does the probe do when it finds it has 1M records >that aren't being consumed, and another 1M records are coming very soon. >Does it store them, drop them with an indication? Does it proactively seek >an alternate association, the same association or does it wait for the >multiple readers to come back when they are ready. Are there going to be >multiple readers? > >Usually the monitor is being attacked, or its generating twice the load >because something else is being attacked in the network. No congestion, >just a lot of records. I don't think PR-SCTP touches these problems. > > > Well, I disagree here.. PR-SCTP has the ability to detect the reader is not reading.. i.e. its flow-controlled the sender. When this occurs the sender can start dumping records that are marked to dump... yes tragic that you loose these records.. but necessary in the situation you define.. thus you get a double win: 1) You don't clog the network with the traffic since you are dumping it at the sender 2) The receiver will have less to do since it will not get the traffic 3) You can set things up to get the last bits so you know the things that started the problem.. or if you desire you can set things up to get the last events jettising the older things.... I think it will provide just what you want... at least to protect the network.. and then if everything is going ok (i.e. no floods or problems) you get all the records with no errors or drops.. R >If you want the record generator to have a proactive role in >failover and recover, maybe RTP/RTCP would be a better choice. >Explicit feedback control channel provides enough to decide if >it should fail over. > >Carter > > > >>Stewart >> >> >> >> >>-- >>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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:14: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 UAA18259 for ; Sat, 11 Oct 2003 20:14:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8TT1-0000UW-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 18:48:11 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8TT0-0000UR-00; Sat, 11 Oct 2003 18:48:10 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9BNm75R002371; Sat, 11 Oct 2003 16:48:07 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16696; Sat, 11 Oct 2003 16:48:05 -0700 (PDT) Message-ID: <3F8896B4.9020304@cisco.com> Date: Sat, 11 Oct 2003 18:48:04 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stbryant@cisco.com CC: carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6AC@ptah.newyork.qosient.com> <3F840C68.5010406@cisco.com> In-Reply-To: <3F840C68.5010406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Stewart Bryant wrote: > > > Carter Bullard wrote: > >> Hey Stewart, >> >>> We should spend some time thinking about the behavior we want in the >>> exporter when the network is congested, perhaps due to an >>> attack. PR-SCTP >>> gives us the option of running a best effort data collection >>> to gleen what >>> is going on, when a TCP based exporter would otherwise collapse due to >>> backlog on the exporter. >> >> >> >> This is a real engineering issue to talk about. Issues in >> producer/consumer >> dynamics are real problems for IPFIX, especially when the flow record >> source is generating 1M records per second, which my probes are capable >> of doing. In my experience, the reader/collector not keeping up is >> never a network congestion problem, it is almost always a >> reader/collector >> resource problem, slow disks, not enough memory, competing processes, >> whatever. > > > The critical issue is which side of TCP does it occur. If TCP has > accepted > the data then the collector application had better do some intelligent. > My concern is with the exporter or probe having a backlog for any reason. > >> It happens in SMP multi-threaded environments where the flow >> generator and its collector are on the same machine, it happens when the >> consumer is on the other end of a dedicated ATM, hyper-channel or >> infiniband links. Its not an issue of reliable vs unreliable transport, >> its more an issue of what does the probe do when it finds it has 1M >> records >> that aren't being consumed, and another 1M records are coming very soon. > > > On this point we absolutely agree. > >> Does it store them, drop them with an indication? > > > I think that we have to assume that it does not have the storage. > > From the PR_SCTP draft: > > One example of partially reliable service is specified in this > document, namely a "timed reliability" service. This service allows > the service user to indicate a limit on the duration of time that the > sender should try to transmit/retransmit the message (this is a > natural extension of the "lifetime" parameter already in the base > protocol). > > This seems to have the right properties > One of the properties I am thinking of for IPFIX is like this but more in line I think with what you want.. instead of a timed reliability how about a buffer space bounded reliabilility.. i.ie You send(data,....bufer-size-limit, PR-SCTP) or send(data,....NO-PRSCTP) (for templates and things) So now when you get your crunch time.. and your app on the router is sending.. and the congestion/flow-control stops you.. the buffer space you have specified as the limit fills up and then, as new sends come in, you either dump things that are new or dump things that have not made it out onto the wire... controlling your buffer space to bound tightly how much you are willing to send... note that any templates sent during this period would still get thorugh reliabily... Basically you define a service that perfectly matches what you want it to for IPFIX and presto.. you get exactly what you want. R >> Does it proactively seek >> an alternate association, the same association or does it wait for the >> multiple readers to come back when they are ready. Are there going >> to be >> multiple readers? >> >> Usually the monitor is being attacked, or its generating twice the load >> because something else is being attacked in the network. No congestion, >> just a lot of records. > > > Anything that means that the exporter has a bunch of data wedged in > its output queues waiting for an ACK looks like congestion to the > exporter. > >> I don't think PR-SCTP touches these problems. >> >> If you want the record generator to have a proactive role in >> failover and recover, maybe RTP/RTCP would be a better choice. >> Explicit feedback control channel provides enough to decide if >> it should fail over. > > > As I recall RTP requires the application to define its own approach to > congestion, and we do have to have a congestion strategy. It would > be better to use a congestion aware transport that has a build-in > strategy to bail-out if there is a problem, and PR-SCTP has just those > properties. > > Stewart > > >> >> Carter >> >> >>> Stewart >>> >>> >>> >>> >>> -- >>> 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/ > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:14:40 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 UAA18274 for ; Sat, 11 Oct 2003 20:14:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8TYI-0000mZ-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 18:53:38 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8TYH-0000mQ-00; Sat, 11 Oct 2003 18:53:37 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 17:02:28 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9BNrX5R004109; Sat, 11 Oct 2003 16:53:34 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16759; Sat, 11 Oct 2003 16:53:32 -0700 (PDT) Message-ID: <3F8897FB.3040304@cisco.com> Date: Sat, 11 Oct 2003 18:53:31 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960365@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960365@xsun01.ptp.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >Hi, > > I guess there is a concern of whether we are approaching this from >the "optimize for the usual case" or "optimize for the worst case". > > The former is usually preferred. > > The general concern seems to be appropriate "capacity" on the >collector side so that little to no back pressure occurs on the >sender. > > UDP's fire and forget model makes this trivial, but its lack of >congestion aware behavior is apparently a no no. From the discussion >it sounds like PR_SCTP has similar properties on overflow, where >things just get tossed, like the behavior of the input UDP socket >buffer when the collector is falling behind. > > However, in a mode where the collector is sufficiently endowed >to consume over TCP, which would hopefully be the majority of >situations, taking advantage of TCP's ubiquity and reliability >properties makes a lot of sense to me. > > I'm still dubious of whether disallowing UDP (which happens to >be the only current concrete binding of NFv9) in favor of SCTP-PR >is really the best approach. > > Personally I'd recommend: > > o bindings over TCP for reliable communication while accomodating for > some failover mechanism if the collector becomes congested or >disabled; > o bindings of UDP for best effort (i.e. no exporter back pressure) in > > configurations where exporter and collector are coresident and >congestion > aware behavior is not a concern; > o binding of PR_SCTP where congestion aware behavior and best effort >are > desired. > > > Jeff: But you miss a big point in this... Why not o bind over SCTP for the reliabile data o and send PR-SCTP for the case where you have records you are willing to give up in the crisis SCTP in combination with PR-SCTP will: 1) Deliver all reliable information for you JUST LIKE TCP 2) During normal times all the records you are prepared to drop in a distress situation will get across TOTALLY reliably. 3) When you hit the rare situation .. the sender will begin to drop protecting your network.. So why would you not take the best of both worlds.. which is what SCTP can offer you with PR-SCTP... they work on the same association.. R >Regards, > > Jeff Meyer > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Wednesday, October 08, 2003 6:09 AM >>To: carter@qosient.com >>Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D >>(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] STCP as a default transport not >> >> >> >> >>Carter Bullard wrote: >> >> >> >>>Hey Stewart, >>> >>> >>> >>>>We should spend some time thinking about the behavior we want in the >>>>exporter when the network is congested, perhaps due to an >>>>attack. PR-SCTP >>>>gives us the option of running a best effort data collection >>>>to gleen what >>>>is going on, when a TCP based exporter would otherwise >>>> >>>> >>collapse due to >> >> >>>>backlog on the exporter. >>>> >>>> >>>This is a real engineering issue to talk about. Issues in >>> >>> >>producer/consumer >> >> >>>dynamics are real problems for IPFIX, especially when the >>> >>> >>flow record >> >> >>>source is generating 1M records per second, which my probes >>> >>> >>are capable >> >> >>>of doing. In my experience, the reader/collector not keeping up is >>>never a network congestion problem, it is almost always a >>> >>> >>reader/collector >> >> >>>resource problem, slow disks, not enough memory, competing >>> >>> >>processes, >> >> >>>whatever. >>> >>> >>The critical issue is which side of TCP does it occur. If TCP >>has accepted >>the data then the collector application had better do some >>intelligent. >>My concern is with the exporter or probe having a backlog for >>any reason. >> >> >> >>>It happens in SMP multi-threaded environments where the flow >>>generator and its collector are on the same machine, it >>> >>> >>happens when the >> >> >>>consumer is on the other end of a dedicated ATM, hyper-channel or >>>infiniband links. Its not an issue of reliable vs >>> >>> >>unreliable transport, >> >> >>>its more an issue of what does the probe do when it finds >>> >>> >>it has 1M records >> >> >>>that aren't being consumed, and another 1M records are >>> >>> >>coming very soon. >> >>On this point we absolutely agree. >> >> >> >>>Does it store them, drop them with an indication? >>> >>> >>I think that we have to assume that it does not have the storage. >> >> From the PR_SCTP draft: >> >> One example of partially reliable service is specified in this >> document, namely a "timed reliability" service. This >>service allows >> the service user to indicate a limit on the duration of >>time that the >> sender should try to transmit/retransmit the message (this is a >> natural extension of the "lifetime" parameter already in the base >> protocol). >> >>This seems to have the right properties >> >> >> >>>Does it proactively seek >>>an alternate association, the same association or does it >>> >>> >>wait for the >> >> >>>multiple readers to come back when they are ready. Are >>> >>> >>there going to be >> >> >>>multiple readers? >>> >>>Usually the monitor is being attacked, or its generating >>> >>> >>twice the load >> >> >>>because something else is being attacked in the network. >>> >>> >>No congestion, >> >> >>>just a lot of records. >>> >>> >>Anything that means that the exporter has a bunch of data wedged in >>its output queues waiting for an ACK looks like congestion to >>the exporter. >> >> >> >>>I don't think PR-SCTP touches these problems. >>> >>>If you want the record generator to have a proactive role in >>>failover and recover, maybe RTP/RTCP would be a better choice. >>>Explicit feedback control channel provides enough to decide if >>>it should fail over. >>> >>> >>As I recall RTP requires the application to define its own approach to >>congestion, and we do have to have a congestion strategy. It would >>be better to use a congestion aware transport that has a build-in >>strategy to bail-out if there is a problem, and PR-SCTP has just those >>properties. >> >>Stewart >> >> >> >> >>>Carter >>> >>> >>> >>> >>>>Stewart >>>> >>>> >>>> >>>> >>>>-- >>>>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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:16:23 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 UAA18291 for ; Sat, 11 Oct 2003 20:16:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8TZj-0000q9-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 18:55:07 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8TZh-0000q1-00; Sat, 11 Oct 2003 18:55:05 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 17:03:56 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9BNt2Ut000399; Sat, 11 Oct 2003 16:55:02 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16780; Sat, 11 Oct 2003 16:54:59 -0700 (PDT) Message-ID: <3F889853.5080102@cisco.com> Date: Sat, 11 Oct 2003 18:54:59 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960365@xsun01.ptp.hp.com> <3F858993.4040001@cisco.com> In-Reply-To: <3F858993.4040001@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > Jeff, > > I would like to comment on your recommendations. > >>Hi, >> >> I guess there is a concern of whether we are approaching this from >>the "optimize for the usual case" or "optimize for the worst case". >> >> The former is usually preferred. >> >> The general concern seems to be appropriate "capacity" on the >>collector side so that little to no back pressure occurs on the >>sender. >> >> UDP's fire and forget model makes this trivial, but its lack of >>congestion aware behavior is apparently a no no. From the discussion >>it sounds like PR_SCTP has similar properties on overflow, where >>things just get tossed, like the behavior of the input UDP socket >>buffer when the collector is falling behind. >> >> However, in a mode where the collector is sufficiently endowed >>to consume over TCP, which would hopefully be the majority of >>situations, taking advantage of TCP's ubiquity and reliability >>properties makes a lot of sense to me. >> >> I'm still dubious of whether disallowing UDP (which happens to >>be the only current concrete binding of NFv9) in favor of SCTP-PR >>is really the best approach. >> >> Personally I'd recommend: >> >> o bindings over TCP for reliable communication while accomodating for >> some failover mechanism if the collector becomes congested or >>disabled; >> > But if there is no congestion, I assume that SCTP_PR would do the same > good job as TCP in term of reliability. > And we know that TCP would have too big memory requirements in case of > congestion. Hence you propose to failover mechanism. Exactly .. in times of no congestion or reader overload SCTP_PR would deliver the data JUST LIKE SCTP i.e. fully reliable... thus you get your cake and eat it too :> R > So why have TCP at all? > >> o bindings of UDP for best effort (i.e. no exporter back pressure) in >> >> configurations where exporter and collector are coresident and >>congestion >> aware behavior is not a concern; >> > We tried very hard this path. It's a NO from the area director, even > for coresident exporter/collector. > >> o binding of PR_SCTP where congestion aware behavior and best effort >>are >> desired. >> > So I conclude that there is only solution left that makes sense! PR_SCTP. > > Regards, Benoit. > >> >>Regards, >> >> Jeff Meyer >> >> >> >>>-----Original Message----- >>>From: Stewart Bryant [mailto:stbryant@cisco.com] >>>Sent: Wednesday, October 08, 2003 6:09 AM >>>To: carter@qosient.com >>>Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D >>>(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>>ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] STCP as a default transport not >>> >>> >>> >>> >>>Carter Bullard wrote: >>> >>> >>> >>>>Hey Stewart, >>>> >>>> >>>> >>>>>We should spend some time thinking about the behavior we want in the >>>>>exporter when the network is congested, perhaps due to an >>>>>attack. PR-SCTP >>>>>gives us the option of running a best effort data collection >>>>>to gleen what >>>>>is going on, when a TCP based exporter would otherwise >>>>> >>>>> >>>collapse due to >>> >>> >>>>>backlog on the exporter. >>>>> >>>>> >>>>This is a real engineering issue to talk about. Issues in >>>> >>>> >>>producer/consumer >>> >>> >>>>dynamics are real problems for IPFIX, especially when the >>>> >>>> >>>flow record >>> >>> >>>>source is generating 1M records per second, which my probes >>>> >>>> >>>are capable >>> >>> >>>>of doing. In my experience, the reader/collector not keeping up is >>>>never a network congestion problem, it is almost always a >>>> >>>> >>>reader/collector >>> >>> >>>>resource problem, slow disks, not enough memory, competing >>>> >>>> >>>processes, >>> >>> >>>>whatever. >>>> >>>> >>>The critical issue is which side of TCP does it occur. If TCP >>>has accepted >>>the data then the collector application had better do some >>>intelligent. >>>My concern is with the exporter or probe having a backlog for >>>any reason. >>> >>> >>> >>>>It happens in SMP multi-threaded environments where the flow >>>>generator and its collector are on the same machine, it >>>> >>>> >>>happens when the >>> >>> >>>>consumer is on the other end of a dedicated ATM, hyper-channel or >>>>infiniband links. Its not an issue of reliable vs >>>> >>>> >>>unreliable transport, >>> >>> >>>>its more an issue of what does the probe do when it finds >>>> >>>> >>>it has 1M records >>> >>> >>>>that aren't being consumed, and another 1M records are >>>> >>>> >>>coming very soon. >>> >>>On this point we absolutely agree. >>> >>> >>> >>>>Does it store them, drop them with an indication? >>>> >>>> >>>I think that we have to assume that it does not have the storage. >>> >>> From the PR_SCTP draft: >>> >>> One example of partially reliable service is specified in this >>> document, namely a "timed reliability" service. This >>>service allows >>> the service user to indicate a limit on the duration of >>>time that the >>> sender should try to transmit/retransmit the message (this is a >>> natural extension of the "lifetime" parameter already in the base >>> protocol). >>> >>>This seems to have the right properties >>> >>> >>> >>>>Does it proactively seek >>>>an alternate association, the same association or does it >>>> >>>> >>>wait for the >>> >>> >>>>multiple readers to come back when they are ready. Are >>>> >>>> >>>there going to be >>> >>> >>>>multiple readers? >>>> >>>>Usually the monitor is being attacked, or its generating >>>> >>>> >>>twice the load >>> >>> >>>>because something else is being attacked in the network. >>>> >>>> >>>No congestion, >>> >>> >>>>just a lot of records. >>>> >>>> >>>Anything that means that the exporter has a bunch of data wedged in >>>its output queues waiting for an ACK looks like congestion to >>>the exporter. >>> >>> >>> >>>>I don't think PR-SCTP touches these problems. >>>> >>>>If you want the record generator to have a proactive role in >>>>failover and recover, maybe RTP/RTCP would be a better choice. >>>>Explicit feedback control channel provides enough to decide if >>>>it should fail over. >>>> >>>> >>>As I recall RTP requires the application to define its own approach to >>>congestion, and we do have to have a congestion strategy. It would >>>be better to use a congestion aware transport that has a build-in >>>strategy to bail-out if there is a problem, and PR-SCTP has just those >>>properties. >>> >>>Stewart >>> >>> >>> >>> >>>>Carter >>>> >>>> >>>> >>>> >>>>>Stewart >>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>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/ >> >> > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:20:05 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 UAA18338 for ; Sat, 11 Oct 2003 20:20:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8TdY-0000x1-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 18:59:04 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8TdX-0000wv-00 for ipfix@net.doit.wisc.edu; Sat, 11 Oct 2003 18:59:04 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9BNx15R005415; Sat, 11 Oct 2003 16:59:01 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16837; Sat, 11 Oct 2003 16:59:00 -0700 (PDT) Message-ID: <3F889943.1040906@cisco.com> Date: Sat, 11 Oct 2003 18:58:59 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brown, Mark R, ALABS" CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <9473683187ADC049A855ED2DA739ABCA2378B5@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA2378B5@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Brown, Mark R, ALABS wrote: >Peter Ludemann wrote: > > > >>Alternatively, TCP/IP (or another reliable transport) allows >>the data transmitter to observe congestion or network outage >>and then aggregating statistics until the congestion or >>outage goes away. >> >> > >I agree that it would be desireable to have a mechanism in IPFIX to >to report to the collector on the amount of data tossed by the exporter >due to buffer >overflow (e.g., total flows, bytes, start and end times) once the >congestion period has cleared. Could such a mechanism be defined so >that it would require a fixed maximum amount of memory (ignoring >possible counter wrap) regardless of the length of the congestion >period(s) or the amount of data loss? > > > Mark: This is very very possible with PR-SCTP. When a sending PR-SCTP decides to abandon the data it reports it to the sending app. Thus the app could very easily keep a statistic that it could then later report on how much it had to drop due to the congestion... Of course the app i.e. IPFIX would need to track this... and then send it to the collector later... in fact it might want to send it reliabily.. Remember you can mix PR-SCTP and plain old SCTP (fully reliable) together on the same association.. R >Mark Brown >AT&T > >-----Original Message----- >From: Peter Ludemann [mailto:p_ludemann@yahoo.com] >Sent: Thursday, October 09, 2003 12:47 PM >To: Benoit Claise; MEYER,JEFFREY D (HP-Cupertino,ex1) >Cc: 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; >'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; >ipfix@net.doit.wisc.edu >Subject: Re: [ipfix] STCP as a default transport not > > >I want to correct one misunderstanding about TCP/IP ... > >Benoit Claise wrote: > > >>And we know that TCP would have too big memory requirements >>in case of congestion. Hence you propose to failover >>mechanism. >>So why have TCP at all? >> >> > >The "too big memory requirements" has nothing to do with >TCP/IP and is solely a function of the desired over-all >reliability and granularity of the data transfer. > >In most implementations of TCP, you can do blocking or >non-blocking I/O. > >In the blocking case, your write is blocked as soon as the >TCP buffer is full (typically, the buffer is 256K or smaller >but you can make it as small as 8K or so if you want). So, >you probably won't do things this way (you can handle this >properly with multi-threading; but the net result is very >similar to non-blocking I/O [next paragraph]). > >In the non-blocking case, you get a return code that the >buffer is full. You can then decide whether or not to queue >the data or do something else with it (you have to implement >this queuing yourself). So, the "big memory requirements" has >*nothing* to do with TCP and is only to do with how granular >and reliable you want the information transmission. If you >want to throw data away when the network is congested, TCP >will cooperate very nicely with you. The difference from >using UDP is that the transmitter actually knows what is >being thrown away. > >Alternatively, TCP/IP (or another reliable transport) allows >the data transmitter to observe congestion or network outage >and then aggregating statistics until the congestion or >outage goes away. > >-- >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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:20:31 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 UAA18361 for ; Sat, 11 Oct 2003 20:20:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8Tgu-00013F-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 19:02:32 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8Tgs-00013A-00; Sat, 11 Oct 2003 19:02:30 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9C02R5R007052; Sat, 11 Oct 2003 17:02:27 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16871; Sat, 11 Oct 2003 17:02:25 -0700 (PDT) Message-ID: <3F889A11.3020304@cisco.com> Date: Sat, 11 Oct 2003 19:02:25 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A502960383@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960383@xsun01.ptp.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > Benoit, > > In answer to your question "So why have TCP at all?" > > I'll repeat, ready availability of implementations on common platforms. > > The cost of packaging and certifying a collector solution on TCP vs. > SCTP is going to be SIGNIFICANTLY less expensive. Because SCTP > belongs in kernel vs. user space, this is not going to just magically > become ubiquitous. > > I guess if your goal is to limit collectors to C implementations on > Linux or BSD then one could argue that "we have it now". However if > Windows or Java are targets for collection platforms, you're kinda > stuck at the moment. I don't think these are insignificant > considerations. > Jeff: SCTP is available on HP-UX Solaris Linux BSD IOS and even Windows.. At the last bake-off for SCTP HP-UX's stack demonstrated PR-SCTP testing against the U-of-Essen, BSD and Cisco-IOS Linux's version were pre-liminary and not tested until next bakeoff (at least that is my understanding).. The windoz implementations were a bit behind.. Sun was not present at this bakeoff.. so I don't know there status.. Bottom line is its out there.. its being used in a LOT of telephone signalling apps and it is NOT more expensive.. R > -- Jeff > > -----Original Message----- > *From:* Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Thursday, October 09, 2003 9:15 AM > *To:* MEYER,JEFFREY D (HP-Cupertino,ex1) > *Cc:* 'stbryant@cisco.com'; carter@qosient.com; > alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > *Subject:* Re: [ipfix] STCP as a default transport not > > Jeff, > > I would like to comment on your recommendations. > >>Hi, >> >> I guess there is a concern of whether we are approaching this from >>the "optimize for the usual case" or "optimize for the worst case". >> >> The former is usually preferred. >> >> The general concern seems to be appropriate "capacity" on the >>collector side so that little to no back pressure occurs on the >>sender. >> >> UDP's fire and forget model makes this trivial, but its lack of >>congestion aware behavior is apparently a no no. From the discussion >>it sounds like PR_SCTP has similar properties on overflow, where >>things just get tossed, like the behavior of the input UDP socket >>buffer when the collector is falling behind. >> >> However, in a mode where the collector is sufficiently endowed >>to consume over TCP, which would hopefully be the majority of >>situations, taking advantage of TCP's ubiquity and reliability >>properties makes a lot of sense to me. >> >> I'm still dubious of whether disallowing UDP (which happens to >>be the only current concrete binding of NFv9) in favor of SCTP-PR >>is really the best approach. >> >> Personally I'd recommend: >> >> o bindings over TCP for reliable communication while accomodating for >> some failover mechanism if the collector becomes congested or >>disabled; >> > But if there is no congestion, I assume that SCTP_PR would do the > same good job as TCP in term of reliability. > And we know that TCP would have too big memory requirements in > case of congestion. Hence you propose to failover mechanism. > So why have TCP at all? > >> o bindings of UDP for best effort (i.e. no exporter back pressure) in >> >> configurations where exporter and collector are coresident and >>congestion >> aware behavior is not a concern; >> > We tried very hard this path. It's a NO from the area director, > even for coresident exporter/collector. > >> o binding of PR_SCTP where congestion aware behavior and best effort >>are >> desired. >> > So I conclude that there is only solution left that makes sense! > PR_SCTP. > > Regards, Benoit. > >>Regards, >> >> Jeff Meyer >> >> >> >>>-----Original Message----- >>>From: Stewart Bryant [mailto:stbryant@cisco.com] >>>Sent: Wednesday, October 08, 2003 6:09 AM >>>To: carter@qosient.com >>>Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D >>>(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>>ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] STCP as a default transport not >>> >>> >>> >>> >>>Carter Bullard wrote: >>> >>> >>> >>>>Hey Stewart, >>>> >>>> >>>> >>>>>We should spend some time thinking about the behavior we want in the >>>>>exporter when the network is congested, perhaps due to an >>>>>attack. PR-SCTP >>>>>gives us the option of running a best effort data collection >>>>>to gleen what >>>>>is going on, when a TCP based exporter would otherwise >>>>> >>>>> >>>collapse due to >>> >>> >>>>>backlog on the exporter. >>>>> >>>>> >>>>This is a real engineering issue to talk about. Issues in >>>> >>>> >>>producer/consumer >>> >>> >>>>dynamics are real problems for IPFIX, especially when the >>>> >>>> >>>flow record >>> >>> >>>>source is generating 1M records per second, which my probes >>>> >>>> >>>are capable >>> >>> >>>>of doing. In my experience, the reader/collector not keeping up is >>>>never a network congestion problem, it is almost always a >>>> >>>> >>>reader/collector >>> >>> >>>>resource problem, slow disks, not enough memory, competing >>>> >>>> >>>processes, >>> >>> >>>>whatever. >>>> >>>> >>>The critical issue is which side of TCP does it occur. If TCP >>>has accepted >>>the data then the collector application had better do some >>>intelligent. >>>My concern is with the exporter or probe having a backlog for >>>any reason. >>> >>> >>> >>>>It happens in SMP multi-threaded environments where the flow >>>>generator and its collector are on the same machine, it >>>> >>>> >>>happens when the >>> >>> >>>>consumer is on the other end of a dedicated ATM, hyper-channel or >>>>infiniband links. Its not an issue of reliable vs >>>> >>>> >>>unreliable transport, >>> >>> >>>>its more an issue of what does the probe do when it finds >>>> >>>> >>>it has 1M records >>> >>> >>>>that aren't being consumed, and another 1M records are >>>> >>>> >>>coming very soon. >>> >>>On this point we absolutely agree. >>> >>> >>> >>>>Does it store them, drop them with an indication? >>>> >>>> >>>I think that we have to assume that it does not have the storage. >>> >>> From the PR_SCTP draft: >>> >>> One example of partially reliable service is specified in this >>> document, namely a "timed reliability" service. This >>>service allows >>> the service user to indicate a limit on the duration of >>>time that the >>> sender should try to transmit/retransmit the message (this is a >>> natural extension of the "lifetime" parameter already in the base >>> protocol). >>> >>>This seems to have the right properties >>> >>> >>> >>>>Does it proactively seek >>>>an alternate association, the same association or does it >>>> >>>> >>>wait for the >>> >>> >>>>multiple readers to come back when they are ready. Are >>>> >>>> >>>there going to be >>> >>> >>>>multiple readers? >>>> >>>>Usually the monitor is being attacked, or its generating >>>> >>>> >>>twice the load >>> >>> >>>>because something else is being attacked in the network. >>>> >>>> >>>No congestion, >>> >>> >>>>just a lot of records. >>>> >>>> >>>Anything that means that the exporter has a bunch of data wedged in >>>its output queues waiting for an ACK looks like congestion to >>>the exporter. >>> >>> >>> >>>>I don't think PR-SCTP touches these problems. >>>> >>>>If you want the record generator to have a proactive role in >>>>failover and recover, maybe RTP/RTCP would be a better choice. >>>>Explicit feedback control channel provides enough to decide if >>>>it should fail over. >>>> >>>> >>>As I recall RTP requires the application to define its own approach to >>>congestion, and we do have to have a congestion strategy. It would >>>be better to use a congestion aware transport that has a build-in >>>strategy to bail-out if there is a problem, and PR-SCTP has just those >>>properties. >>> >>>Stewart >>> >>> >>> >>> >>>>Carter >>>> >>>> >>>> >>>> >>>>>Stewart >>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>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/ >> >> > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:28:02 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 UAA18434 for ; Sat, 11 Oct 2003 20:28:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8To3-0001Ft-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 19:09:55 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8To2-0001Fl-00 for ipfix@net.doit.wisc.edu; Sat, 11 Oct 2003 19:09:54 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 17:18:46 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9C09p7E001654; Sat, 11 Oct 2003 17:09:51 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB16958; Sat, 11 Oct 2003 17:09:50 -0700 (PDT) Message-ID: <3F889BCD.3000504@cisco.com> Date: Sat, 11 Oct 2003 19:09:49 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'Peter Lei'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED661AB3A9@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661AB3A9@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter: I think the problem is that the requirement is to have a transport protocol that is congestion aware.. UDP is NOT congestion aware.. yes you can bolt things to it (RTP) to make it react better but that does not meet the requirements put on you by the IAB/IESG... You can't have UDP so why keep discussing it? R Carter Bullard wrote: >Is RTP/UDP congestion aware? If so, then how did UDP get >tossed out defacto? > >Carter > > > >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Peter Lei >>Sent: Thursday, October 09, 2003 1:30 PM >>To: MEYER,JEFFREY D (HP-Cupertino,ex1); ipfix@net.doit.wisc.edu >>Subject: RE: [ipfix] STCP as a default transport not >> >> >>I don't really understand this UDP thread... I thought that it >>was essentially "mandated" that the transport protocol used MUST >>be congestion aware. That ruled UDP out long ago, no?? Or is >>that going to be debated again?! >> >>I didn't see anyone point this out yet, but PR-SCTP is not just >>"best effort" w/congestion control... it is an extension to SCTP >>such that you can do any reliability level from best effort >>(UDP-like) to fully reliable (SCTP or TCP like), and anywhere in >>between. >> >>So with SCTP and the PR-SCTP extension as transport, you can do >>both the reliable and unreliable export with the same transport >>stack... and it's all congestion controlled. The application >>layer decides what reliability needed when it does the send() >>call. >> >>The PR-SCTP draft has completed working group review and last >>call in tsvwg and is supposed to be under IESG review right now. >>If you look at the draft, it is a very straightforward and >>"simple" extenstion to SCTP. >> >>regards, >>--peter >> >> >> >>>Hi, >>> >>> Does this mean UDP gets taken out? Or will there be 3 >>> >>> >>bindings for >> >> >>>different environmental requirements? [That would be my suggestion] >>> >>>o bindings over TCP for reliable communication while >>> >>> >>accomodating for some >> >> >>>failover mechanism if the collector becomes congested or disabled; >>> >>>o bindings of UDP for best effort (i.e. no exporter back >>> >>> >>pressure) in >> >> >>>configurations where exporter and collector are colocated >>> >>> >>and congestion >> >> >>>aware behavior is not a concern; >>> >>>o binding of PR_SCTP where congestion aware behavior and >>> >>> >>best effort are >> >> >>>desired. >>> >>> >>>-- Jeff >>> >>>-----Original Message----- >>>From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] >>>Sent: Monday, October 06, 2003 9:34 AM >>>To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'carter@qosient.com'; >>>'alex.audu@alcatel.com' >>>Cc: 'stbryant@cisco.com'; 'ipfix-chairs@net.doit.wisc.edu'; >>>'ipfix@net.doit.wisc.edu' >>>Subject: RE: [ipfix] STCP as a default transport not >>> >>> >>> >>>Okay... >>> >>>It seems we haven't reached a (firm) conclusion, but we >>> >>> >>need to get the >> >> >>>draft going and this is a big piece of it. Jeff seems to >>> >>> >>propose specifying >> >> >>>both (TCP and SCTP). Anyone opposes this? Or should we >>> >>> >>stick with one >> >> >>>protocol mapping? >>> >>>We need to start converging on this really soon. >>> >>>Thanks, >>> >>>Reinaldo >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: MEYER,JEFFREY D (HP-Cupertino,ex1) [ >>>> >>>> >>mailto:jeff.meyer2@hp.com >> >> >>> ] >>> >>> >>>>Sent: Thursday, October 02, 2003 5:05 PM >>>>To: 'carter@qosient.com'; 'alex.audu@alcatel.com' >>>>Cc: 'stbryant@cisco.com'; Penno, Reinaldo [BL60:SF30:EXCH]; >>>>'ipfix-chairs@net.doit.wisc.edu'; 'ipfix@net.doit.wisc.edu' >>>>Subject: RE: [ipfix] STCP as a default transport not >>>> >>>> >>>>I'd be interested in knowing what the specific aspects of >>>>SCTP are that the IPFIX protocol authors want to use, and how >>>>they do or do not conflict in some way with a parallel >>>> >>>> >>mapping to TCP. >> >> >>>>Taking the Diameter approach of specifying both TCP and SCTP >>>>would allow for the market to decide if ubiquity of >>>>availability or the special capabilities of SCTP are more >>>> >>>> >>important. >> >> >>>>-- Jeff >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Carter Bullard [ mailto:carter@qosient.com >>>>> >>>>> >>> ] >>> >>> >>>>>Sent: Thursday, October 02, 2003 1:00 PM >>>>>To: alex.audu@alcatel.com >>>>>Cc: stbryant@cisco.com; 'Reinaldo Penno'; >>>>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu >>>>>Subject: RE: [ipfix] STCP as a default transport not >>>>> >>>>> >>>>>Hey Alex, >>>>> Did I say something wrong? I firmly believe that >>>>> >>>>> >>people adopt >> >> >>>>>technology when it solves problems. STCP will get around >>>>> >>>>> >>>>as its found >>>> >>>> >>>>>to be a real solution. But with regard to STCP and IPFIX, >>>>> >>>>> >>>>I read RFC >>>> >>>> >>>>>3257, the SCTP Applicability Statement, and I don't see >>>>> >>>>> >>where IPFIX >> >> >>>>>fits. Benefits of SCTP over TCP are: >>>>> >>>>> multi-streams support >>>>> multi-homing support >>>>> preservation of message boundaries >>>>> unordered reliable message delivery >>>>> >>>>>The first three I don't see as requirements for IPFIX. >>>>>I actually believe the last one to be a problem for >>>>> >>>>> >>IPFIX. STCP is >> >> >>>>>less efficient that TCP, and so if IPFIX doesn't need any >>>>> >>>>> >>>>of these 4 >>>> >>>> >>>>>items, then I don't see the applicability. >>>>> >>>>>Carter >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Alex Audu [ mailto:alex.audu@alcatel.com >>>>>> >>>>>> >>> ] >>> >>> >>>>>>Sent: Thursday, October 02, 2003 2:51 PM >>>>>>To: carter@qosient.com >>>>>>Cc: stbryant@cisco.com; 'Reinaldo Penno'; >>>>>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu >>>>>>Subject: Re: [ipfix] STCP as a default transport not >>>>>> >>>>>> >>>>>>Hello Carter, >>>>>> >>>>>>If it is true that SCTP hasn't been widely deployed, it >>>>>> >>>>>> >>>>is probably >>>> >>>> >>>>>>because of statements like you have made below. Look, >>>>>> >>>>>> >>we all know >> >> >>>>>>SCTP has a lot of benefits over TCP. If folks like you >>>>>> >>>>>> >>>>don't drive >>>> >>>> >>>>>>its deployement >>>>>>by specifying it as default transport, how will it be >>>>>>ubiquitous? It is a >>>>>>self fulfilling prophesy. >>>>>> >>>>>>For IETF protocols that recommend SCTP as defaults, >>>>>> >>>>>> >>see rfc 3057, >> >> >>>>>>rfc 3331 and rfc 3332 just to name a few. >>>>>> >>>>>>Regards, >>>>>>Alex. >>>>>> >>>>>>Carter Bullard wrote: >>>>>> >>>>>> >>>>>> >>>>>>>I believe that SCTP-PR is not deployed widely enough >>>>>>>to be considered a default for any IETF technology. >>>>>>>It is not on my Linux RedHat 9.0 distribution, nor >>>>>>>my Mac OS-X or my Windows XP system. I don't see it >>>>>>> >>>>>>> >>>>available on >>>> >>>> >>>>>>>any Solaris machine that I have access to. >>>>>>> >>>>>>>What IETF technology is currently using SCTP as a >>>>>>>default transport? >>>>>>> >>>>>>>Carter >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: majordomo listserver >>>>>>>> >>>>>>>> >>>>[ mailto:majordomo@mil.doit.wisc.edu >>>> >>>> >> >> >> >>>] >>> >>> >>>>>>>>On Behalf Of Stewart Bryant >>>>>>>>Sent: Thursday, October 02, 2003 12:14 PM >>>>>>>>To: Reinaldo Penno >>>>>>>>Cc: ipfix-chairs@net.doit.wisc.edu; >>>>>>>> >>>>>>>> >>ipfix@net.doit.wisc.edu >> >> >>>>>>>>Subject: Re: [ipfix] Ipfix Protocol open items >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Reinaldo Penno wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hello, >>>>>>>>> >>>>>>>>>Have we zeroed in a certain transport protocol? TCP, >>>>>>>>> >>>>>>>>> >>>>>SCTP-PR or >>>>> >>>>> >>>>>>>>>something else? >>>>>>>>> >>>>>>>>>I need to write something to explain how Netflow >>>>>>>>> >>>>>>>>> >>runs over >> >> >>>>>>>>TCP, but it >>>>>>>> >>>>>>>> >>>>>>>>>seems to me somewhat of a lower priority if this is not >>>>>>>>> >>>>>>>>> >>>>>>>>going to be the >>>>>>>> >>>>>>>> >>>>>>>>>default protocol. We should focus on explaning how this >>>>>>>>> >>>>>>>>> >>>>>>>>should work on >>>>>>>> >>>>>>>> >>>>>>>>>the "choosen one". >>>>>>>>> >>>>>>>>> >>>>>>>>I think that perhaps the question should be put another >>>>>>>> >>>>>>>> >>>>>>way. There are >>>>>> >>>>>> >>>>>>>>WG members who propose SCTP-PR as the default, and >>>>>>>> >>>>>>>> >>>>SCTP-PR has >>>> >>>> >>>>>>>>advantage because of its better flexibility in coping >>>>>>>> >>>>>>>> >>>>>>with congestion. >>>>>> >>>>>> >>>>>>>>So the real question is whether there are WG members who >>>>>>>> >>>>>>>> >>>>>>think that >>>>>> >>>>>> >>>>>>>>the default should be TCP. If no group comes forward, >>>>>>>> >>>>>>>> >>>>>then we have >>>>> >>>>> >>>>>>>>our answer. If there is support then we need to perform >>>>>>>> >>>>>>>> >>>>>a detailed >>>>> >>>>> >>>>>>>>analysis of the relative merits of the two protocols. >>>>>>>> >>>>>>>>Stewart >>>>>>>> >>>>>>>> >>>>>>>>-- >>>>>>>>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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:32: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 UAA18530 for ; Sat, 11 Oct 2003 20:32:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8Tv6-0001ZN-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 19:17:12 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8Tv5-0001ZH-00 for ipfix@net.doit.wisc.edu; Sat, 11 Oct 2003 19:17:11 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9C0H77E003867; Sat, 11 Oct 2003 17:17:07 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB17062; Sat, 11 Oct 2003 17:16:57 -0700 (PDT) Message-ID: <3F889D78.7040102@cisco.com> Date: Sat, 11 Oct 2003 19:16:56 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Moore CC: Carter Bullard , "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED661CE1C2@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607A6B3@ptah.newyork.qosient.com> <20031009173707.M21695@login.caida.org> In-Reply-To: <20031009173707.M21695@login.caida.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit David Moore wrote: >On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: > > >> When you're dealing with 1M+ records per second, the >>concepts of record loss detection and selective retransmission >>are just not practical. With these types of monitors, if >>there is packet loss, there really isn't any way that the probes >>can slow down, so, like RFC 3497, the concept would have to be >>to have some type of feedback signal so the probe can stop. >>So RTP/RTCP sounds good. I'd rather IPFIX send the message, >>but the concept of IPFIX being congestion aware itself seems >>to have dropped through a fissure somewhere. >> >> > >With SCTP-PR, afaik, allows you to tune whether you want any >particular pieces of sent data to be reliable or unreliable. By >setting every piece to be unreliable, then you have UDP in terms >of reliability. However, SCTP-PR has the feedback signal which >already provides TCP-friendly congestion avoidance. > > > Exactly :> >Is there some performance cost to SCTP-PR when all data is marked >unreliable that you feel is too high, to require building a different >feedback mechanism on top of UDP to also have congestion avoidance? > >I understand the desire for a UDP transport which has no congestion >avoidance. But if the goal is something UDP-like (unreliable) but >which does have congestion avoidance, IPFIX should use something >already a standard (or about to be a standard) rather than inventing >its own. > > > > I agree, but you knew I would :> R >-- david > >-- >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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:33:11 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 UAA18560 for ; Sat, 11 Oct 2003 20:33:11 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8U3M-0001my-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 19:25:44 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8U3K-0001mt-00 for ipfix@net.doit.wisc.edu; Sat, 11 Oct 2003 19:25:43 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9C0PdUt009016; Sat, 11 Oct 2003 17:25:40 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB17164; Sat, 11 Oct 2003 17:25:37 -0700 (PDT) Message-ID: <3F889F80.5060902@cisco.com> Date: Sat, 11 Oct 2003 19:25:36 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'Peter Lei'" , ipfix@net.doit.wisc.edu, "'David Moore'" , "'Nevil Brownlee'" Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6B7@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6B7@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: >Hey Peter, > You have to incur SCTP-PR functions regardless if you >use them or not. The draft is very clear on this fact. >SCTP-PR doesn't modify the wire protocol, so -PR doesn't >reduce any overhead states or messages. > Well I think you need to re-read the draft. It extends the wire protocol and it WILL remove data from being retransmitted in cases where thing are being abandonded... which will result in less overhead on the network. > It simply modifies >the API and some sender semantics. > No, it does far more than this.. Carter please go read the current draft :> > And, of course, you don't >get some required features such as congestion detection, >without turning on some rather constrained behavior. For >instance you can't do any kind of loss detection with > > Huh? how do you reach this conclusion? Having the U bit set makes NO differenct to loss detection. No matter if a Data chunk is ordered or unordered you will detect loss. >SCTP-PR unless you use in order delivery (no "U" bits set). >That can't be too efficient. And the header is huge, what >is it? a common header, a chunk header and a data >header, we're talking, what, 32 bytes? > > Take a look again ploease.. its 4 bytes larger than TCP period.. And in many cases it ends up being smaller (since most TCP implementations turn on time-stamps by default). I really think you need to spend some time reading RFC2960 and the PR-SCTP draft... if 2960 is to heavy to read you can also try my book on SCTP ... a bit easier to read and it covers all the gory details too ;-> >One problem I see is that IPFIX will use IPSec for its security. >Without RFC 3554, "On the Use of Stream Control Transmission >Protocol (SCTP) with Ipsec", which is not widely implemented, >IPSec isn't compatible with SCTP features like multi-homing, >basically making the fail-over mechanisms unuseable, and >of course NAT doesn't work with multi-homing. > > > If you are behind NATs then you need to do the singly homed thing.. this does work.. its just you lose the benefits of multi-homing .. we actually run this as a test at the bakeoff...aka getting through a NAT >I'm sure you feel that SCTP-PR is the most efficient mechanism >for transporting bulk records at 100 Mbps across a single hop >dedicated link, but does anyone have any real experience to >back this position? > > Well we are talking of things beyond a single link network. Otherwise why are we standardizing it in the IETF? The IETF standardizes things that run across the Big-I not things that are in your local LAN.. R > >Carter > > > > >-----Original Message----- >From: Peter Lei [mailto:peter.lei@ieee.org] >Sent: Friday, October 10, 2003 12:06 AM >To: ipfix@net.doit.wisc.edu >Cc: carter@qosient.com; 'David Moore'; 'Nevil Brownlee' >Subject: Re: [ipfix] Congestion management > > >Carter Bullard wrote: > > >>Hey David, >> SCTP-PR is partial reliable, not unreliable. You >>can't seem to turn off the failure detection and >>protection capabilities of normal reliable SCTP, nor can >>you turn off the congestion avoidance logic of SCTP, so >>it is definitely more complex and more expensive compared >>to say RTP/UDP, and probably TCP. >> >> > >PR-SCTP can definitely be "unreliable" if you so choose; >have the service definition be "try this only once please" >and the stack will only trasmit each send() call once. > >If the transport choice is to be "congestion controlled", >why would NOT do congestion avoidance?! The feedback loop >is exactly what allows SCTP to have TCP-friendly congetion >control. > >I see failure detection as a benefit, not a detriment... >It certainly would be nice to know that the transport has >"gone away" so I can maybe failover to an alternate >collector. Plus, I don't want to send packets needlessly >if the collector has somehow crashed (e.g. might cause >congestion?) > > > >> The key is to find a transition technology for the >>1000's of existing IP flow monitors that are purely >>UDP based today. A simple transitional technology >>should be appropriate, and I think RTP/UDP is a good >>one, especially since the IESG has historically accepted >>it as passing the congestion awareness criteria. >> >> I'm personally concerned that the only mentioned >>transport candidates are connection-oriented and unicast >>only. There are serious advantages to connection-less >>transports and multicast support, and I'm interested in >>ensuring that IPFIX can explore those advantages. Neither >>SCTP-PR or TCP can support multicast, so I'm an advocate >>of a three transport model. >> >> > > > > >> But Nevil is right, the real issue is what should be the >>default transport for IPFIX, and here it seems to me that >>SCTP-PR should NOT be the default, although there is enough >>consensus for it to be a supported transport. TCP seems to >>be the only real candidate for the default, simply from an >>interoperability standpoint. If you've only got one shot >>at attaching to an IP flow probe, are you going to use SCTP-PR >>or TCP, if the probe could support either, but not both? >>I think TCP will be the higher probability choice, which >>would make it the default, by default. >> >> > >I disagree... picking TCP as the default tranport for reliable >data then requires you to use RTP/UDP for the unreliable data >(unless you want to send it ALL over TCP)... > >SCTP w/PR-SCTP extension allows both (over the same association >even, if desired) and IMO seems to provide all the transport >services that IPFIX requires. > >regards, >--peter > > > >>Carter >> >> >> >> >> >> >>>-----Original Message----- >>>From: David Moore [mailto:dmoore@caida.org] >>>Sent: Thursday, October 09, 2003 7:37 PM >>>To: Carter Bullard >>>Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] Congestion management >>> >>> >>>On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: >>> >>> >>> >>>> When you're dealing with 1M+ records per second, the >>>>concepts of record loss detection and selective retransmission >>>>are just not practical. With these types of monitors, if >>>>there is packet loss, there really isn't any way that the probes >>>>can slow down, so, like RFC 3497, the concept would have to be >>>>to have some type of feedback signal so the probe can stop. >>>>So RTP/RTCP sounds good. I'd rather IPFIX send the message, >>>>but the concept of IPFIX being congestion aware itself seems >>>>to have dropped through a fissure somewhere. >>>> >>>> >>>With SCTP-PR, afaik, allows you to tune whether you want any >>>particular pieces of sent data to be reliable or unreliable. By >>>setting every piece to be unreliable, then you have UDP in terms >>>of reliability. However, SCTP-PR has the feedback signal which >>>already provides TCP-friendly congestion avoidance. >>> >>>Is there some performance cost to SCTP-PR when all data is marked >>>unreliable that you feel is too high, to require building a different >>>feedback mechanism on top of UDP to also have congestion avoidance? >>> >>>I understand the desire for a UDP transport which has no congestion >>>avoidance. But if the goal is something UDP-like (unreliable) but >>>which does have congestion avoidance, IPFIX should use something >>>already a standard (or about to be a standard) rather than inventing >>>its own. >>> >>> >>>-- david >>> >>> >>> >> >> >> >>-- >>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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:33:24 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 UAA18576 for ; Sat, 11 Oct 2003 20:33:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8Tsy-0001Tw-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 19:15:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8Tsx-0001To-00; Sat, 11 Oct 2003 19:14:59 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9C0EtUt006323; Sat, 11 Oct 2003 17:14:56 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB17033; Sat, 11 Oct 2003 17:14:53 -0700 (PDT) Message-ID: <3F889CFC.1040300@cisco.com> Date: Sat, 11 Oct 2003 19:14:52 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Benoit Claise'" , stbryant@cisco.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <5C8959A16A71B449AE793CF52FBBED6607A6B9@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6B9@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter: The paper you site.. and yes I am on it.. was the basis we used to make sure "newreno" behavior for fast retransmit was put into the SCTP implementors guide. Now most implementations already were doing this (at least those I have talked to)... And as it is I don't think you will find true NewReno behavior in ALL TCP implementations either :-< So I guess by this reasoning TCP is also immature :-D SCTP is a VERY stable protocol that has a LOT of implementations (over 20 that I know of... probably close to 30 if I took the time to count them :>). Is there more research to do.. of course there is.. the same can be said for TCP.. thats why the TSVWG exists ..we are always trying to make things better :> R Carter Bullard wrote: >My principal concern is that SCTP is too young to be the only transport. >For example, a recent Univ. of Delaware Technical Document, co-authored >by Cisco, identifies a serious problem with SCTP congestion control >when there are multiple drops in a single window, causing it to degrade >"more than necessary to be 'TCP-friendly', i.e. it grinds to a dribble >for a little while, while transmitting more packets. The link where >you can get the publication is: > >http://www.eecis.udel.edu/~amer/PEL/poc/index.html > >The paper is "SCTP and TCP Variants: Congestion Control Under Multiple >Losses", very recent. The point is that these are the normal growing >pains of a new protocol, but SCTP and PR-SCTP still have some problems >to iron out. > >Like Jeff, I have no problems with IPFIX running over PR-SCTP, but >not as the only protocol. > >Carter > > > > > > >>-----Original Message----- >>From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] >>Sent: Friday, October 10, 2003 9:46 AM >>To: 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1) >>Cc: stbryant@cisco.com; alex.audu@alcatel.com; >>carter@qosient.com; 'Reinaldo Penno'; >>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com >>Subject: RE: [ipfix] STCP as a default transport not >> >> >>Benoit, >> >> I am not in any way against specifying IPFIX on top of PR-SCTP, >>what I am against is making that the ONLY supported transport. >>This is for practical reasons, like availability of implementation. >>And as cited before because of transport protocols' affinity >>for running in kernel vs. user space, the availability is going >>to be a lot slower coming than one might like. >> >> I would liken this to deciding to define a transport layer >>protocol which could only run on IPv6 and not IPv4. You could, >>but if you can run on both, I think there are decided benefits. >> >> The Diameter authors seemed to have made this pragmatic choice. >> >> It is a bit ironic that previous decisions of the WG around >>choice of candidate protocols were ultimately trumped by "practical >>reasons" like NF is more widely deployed, despite the fact >>that it was the only protocol with NO binding to a congestion >>aware transport. And now, the arguments seem to be a complete >>180 change. >> >>Regards, >> >> Jeff Meyer >> >> >> >>>-----Original Message----- >>>From: Benoit Claise [mailto:bclaise@cisco.com] >>>Sent: Friday, October 10, 2003 3:26 AM >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) >>>Cc: stbryant@cisco.com; alex.audu@alcatel.com; carter@qosient.com; >>>'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; >>>ipfix@net.doit.wisc.edu; rrs@cisco.com >>>Subject: Re: [ipfix] STCP as a default transport not >>> >>> >>>Jeff, >>> >>>My point is that I'm convinced that SCTP-PR gives all the >>> >>> >>advantages >> >> >>>in one transport protocol. See the recent postings from Peter >>>Lei; he knows the protocol a lot >>>better than I do! >>>Having the full flexibility (reliable, unreliable, partially >>>reliable) in one transport protocol would be a plus. >>>Let's give the flexibility to the different implementations. >>>On the top of that, we don't know yet the future applications >>>of IPFIX: >>>PSAMP is one, exporting SLA information?, some MIB variables >>>export?, etc... everything is possible since IPFIX is a generic >>>export format. >>>As I said, I think we should just use the right protocol >>>instead of just >>>using what exists. IMHO, SCTP_PR should be the target as transport >>>transport. So, I would vote for SCTP with the PR extension. >>> >>>Regards, Benoit. >>> >>> >>> >>> >>>>Benoit, >>>> >>>> SCTP-PR does not make me happy, nor do the previous decisions >>>>around reliability as it regards to billing. >>>> >>>> Dropping packets under congestion is already done by UDP, and >>>>UDP is ubiquitous in all OS's. >>>> >>>> Is there some challenge in defining IPFIX over TCP? It seems >>>>to me that this is the easier case, there are less things to map >>>>to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP >>>>your proposal, i.e. force the use of SCTP-PR? >>>> >>>> As with the experience of Diameter, specifying both transports >>>>will enable a migration to SCTP-PR for everyone if it actually >>>>proves to have the values espoused and it is readily available. >>>>In the interim having a TCP mapping (and UDP) would address the >>>>requirements which I've encountered (billing issues aside). >>>> >>>> As Peter pointed out the resource constraints on the exporter >>>>imposed by TCP can be mitigated in the implementation. >>>> >>>>Regards, >>>> >>>> Jeff Meyer >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Benoit Claise [mailto:bclaise@cisco.com] >>>>>Sent: Thursday, October 09, 2003 9:15 AM >>>>>To: stbryant@cisco.com >>>>>Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; >>>>>'MEYER,JEFFREY D (HP-Cupertino,ex1)'; >>>>> >>>>> >>>ipfix-chairs@net.doit.wisc.edu; >>> >>> >>>>>ipfix@net.doit.wisc.edu; rrs@cisco.com >>>>>Subject: Re: [ipfix] STCP as a default transport not >>>>> >>>>> >>>>>Dear all, >>>>> >>>>>There are advantages regarding the use of SCTP versus TCP >>>>> >>>>> >>>(discussed >>> >>> >>>>>already on the list) but I think that the biggest advantage >>>>>of SCTP is >>>>>actually the extension SCTP-PR. And I'm surprised to see no >>>>>reactions on >>>>>the email below. >>>>>Yes, I know that the SCTP-PR is not a standard yet but I >>>>>think that we >>>>>should just take the right protocol instead of just using >>>>> >>>>> >>>what exists >>> >>> >>>>>because it exists! >>>>> >>>>>I remember the heated discussions maybe one year ago about >>>>>using IPFIX >>>>>for billing, about high availability, etc... >>>>>And one of the solution that could make everybody happy >>>>> >>>>> >>is: SCTP-PR. >> >> >>>>>We know that we do have some memory issues with TCP on the >>>>>high-end routers. >>>>>But, for the smaller exporter OR if you can afford/if it's >>>>>possible to >>>>>pack the exporter with the appropriate amount of memory, >>>>>SCTP-PR would >>>>>work perfectly well! >>>>>Now, in the majority of cases (no billing, no enough >>>>> >>>>> >>>memory/too many >>> >>> >>>>>flow records, etc...) SCTP-PR would drop the flow records >>>>>excess if any, >>>>>which I think is the right thing to do. >>>>> >>>>>Regards, Benoit. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I think that the interest is in using PR-SCTP as described in >>>>>> >>>>>> >>>>>> >>>>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt >>>>> >>>>> >>>>>>rather than RFC 2960 SCTP. >>>>>> >>>>>>This claims the following benefits: >>>>>> >>>>>> >>>>>>1.3 Benefits of PR-SCTP >>>>>> >>>>>> Hereafter, we use the notation "PR-SCTP" to refer to the SCTP >>>>>> protocol extended as defined in this document. >>>>>> >>>>>> The following are some of the advantages for integrating >>>>>> >>>>>> >>>>>> >>>>>> >>>>>partially >>>>> >>>>> >>>>> >>>>> >>>>>> reliable data service into SCTP, i.e., benefits of PR-SCTP: >>>>>> >>>>>> 1. Some application layer protocols may benefit from >>>>>> >>>>>> >>>>>> >>>>>> >>>>>being able to >>>>> >>>>> >>>>> >>>>> >>>>>> use a single SCTP association to carry both reliable >>>>>> >>>>>> >>>>>> >>>>>> >>>>>content, -- >>>>> >>>>> >>>>> >>>>> >>>>>> such as text pages, billing and accounting >>>>>> >>>>>> >>>information, setup >>> >>> >>>>>> signaling -- and unreliable content, e.g. state that >>>>>> >>>>>> >>>>>> >>>>>> >>>>>is highly >>>>> >>>>> >>>>> >>>>> >>>>>> sensitive to timeliness, where generating a new >>>>>> >>>>>> >>>>>> >>>>>> >>>>>packet is more >>>>> >>>>> >>>>> >>>>> >>>>>> advantageous than transmitting an old one [1]. >>>>>> >>>>>> 2. Partially reliable data traffic carried by PR-SCTP >>>>>> >>>>>> >>>>>> >>>>>> >>>>>will enjoy the >>>>> >>>>> >>>>> >>>>> >>>>>> same communication failure detection and protection >>>>>> >>>>>> >>>>>> >>>>>> >>>>>capabilities >>>>> >>>>> >>>>> >>>>> >>>>>> as the normal reliable SCTP data traffic does. This >>>>>> >>>>>> >>>>>> >>>>>> >>>>>includes the >>>>> >>>>> >>>>> >>>>> >>>>>> ability to: - quickly detect a failed destination >>>>>> >>>>>> >>address; - >> >> >>>>>> fail-over to an alternate destination address, and; >>>>>> >>>>>> >>>>>> >>>>>> >>>>>- be notified >>>>> >>>>> >>>>> >>>>> >>>>>> if the data receiver becomes unreachable. >>>>>> >>>>>> 3. In addition to providing unordered unreliable data >>>>>> >>>>>> >>>>>> >>>>>> >>>>>transfer as >>>>> >>>>> >>>>> >>>>> >>>>>> UDP does, PR-SCTP can provide ordered unreliable >>>>>> >>>>>> >>>>>> >>>>>> >>>>>data transfer >>>>> >>>>> >>>>> >>>>> >>>>>> service. >>>>>> >>>>>> 4. PR-SCTP employs the same congestion control and congestion >>>>>> avoidance for all data traffic, whether reliable or >>>>>> >>>>>> >>>partially >>> >>> >>>>>> reliable - this is very desirable since SCTP enforces >>>>>> TCP-friendliness (unlike UDP.) >>>>>> >>>>>> 5. Because of the chunk bundling function of SCTP, >>>>>> >>>>>> >>reliable and >> >> >>>>>> unreliable messages can be multiplexed over a >>>>>> >>>>>> >>single PR-SCTP >> >> >>>>>> association. Therefore, the number of IP datagrams >>>>>> >>>>>> >>>>>> >>>>>> >>>>>(and hence >>>>> >>>>> >>>>> >>>>> >>>>>> the network overhead) can be reduced versus having >>>>>> >>>>>> >>>>>> >>>>>> >>>>>to send these >>>>> >>>>> >>>>> >>>>> >>>>>> different types of data using separate protocols. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Additionally, >>>>> >>>>> >>>>> >>>>> >>>>>> this multiplexing allows for port savings versus >>>>>> >>>>>> >>>>>> >>>>>> >>>>>using different >>>>> >>>>> >>>>> >>>>> >>>>>> ports for reliable and unreliable connections. >>>>>> >>>>>>---------- >>>>>> >>>>>>PR-SCTP has the option of being able to configure the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>exporter to work >>>>> >>>>> >>>>> >>>>> >>>>>>on a >>>>>>best effort data export basis, rather than being >>>>>> >>>>>> >>>>>> >>>>>> >>>>>constrained to work on a >>>>> >>>>> >>>>> >>>>> >>>>>>reliable basis. >>>>>> >>>>>>We should spend some time thinking about the behaviour we >>>>>> >>>>>> >>>>>> >>>>>> >>>>>want in the >>>>> >>>>> >>>>> >>>>> >>>>>>exporter when the network is congested, perhaps due to an >>>>>> >>>>>> >>>>>> >>>>>> >>>>>attack. PR-SCTP >>>>> >>>>> >>>>> >>>>> >>>>>>gives us the option of running a best effort data >>>>>> >>>>>> >>>>>> >>>>>> >>>>>collection to gleen >>>>> >>>>> >>>>> >>>>> >>>>>>what >>>>>>is going on, when a TCP based exporter would otherwise >>>>>> >>>>>> >>>>>> >>>>>> >>>>>collapse due to >>>>> >>>>> >>>>> >>>>> >>>>>>backlog on the exporter. >>>>>> >>>>>>Stewart >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>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/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> > > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sat Oct 11 20:36: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 UAA18645 for ; Sat, 11 Oct 2003 20:36:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8U78-0001tJ-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Oct 2003 19:29:38 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8U77-0001tB-00 for ipfix@net.doit.wisc.edu; Sat, 11 Oct 2003 19:29:37 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 17:38:29 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9C0TY7E006674; Sat, 11 Oct 2003 17:29:34 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB17205; Sat, 11 Oct 2003 17:29:32 -0700 (PDT) Message-ID: <3F88A06C.9040502@cisco.com> Date: Sat, 11 Oct 2003 19:29:32 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'Peter Lei'" , ipfix@net.doit.wisc.edu, "'David Moore'" , "'Nevil Brownlee'" Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6B8@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6B8@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: >Gentle people, > Just a follow up on SCTP-PR available implementations. >There were only 3 entities that had SCTP-PR implementations >at the 5th annual bakeoff, Sept 2002, Cisco, Temple and >Uni Essen. > > > But that was 2002 .. the bakeoff at the U-of-Deleware (2003 June) had Cisco, BSD/Temple, Uni-Essen and The HP-UX stack. Also we had some testing with our linux friends .. but they just were not quite done.. I would imagine they will be at the next bakeoff.. Adax wanted to test there PR-SCTP but could not attend due to a conflict .. most other implementations that were at the June bakeoff said they would be testing PR-SCTP in the 2004 bakeoff.. R > There was suppose to be the 6th annual bakeoff in June, >2003, but the sctp.org mailing list ends abruptly in May, >2003. Does anyone know where the mailing list went, and/or >the results of the bakeoff, specifically who else has >implemented SCTP-PR? > > > >Carter > > > > > >-- >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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Sun Oct 12 22:54:02 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 WAA07802 for ; Sun, 12 Oct 2003 22:54:01 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8sUw-00011h-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Oct 2003 21:31:50 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A8sUv-00011Y-00 for ipfix@net.doit.wisc.edu; Sun, 12 Oct 2003 21:31:49 -0500 Received: (qmail 71263 invoked from network); 13 Oct 2003 02:31:48 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 13 Oct 2003 02:31:48 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9D2VlX30567; Sun, 12 Oct 2003 22:31:47 -0400 Reply-To: From: "Carter Bullard" To: "'Randall Stewart \(cisco\)'" Cc: , , "'Reinaldo Penno'" , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , , Subject: RE: [ipfix] STCP as a default transport not Date: Sun, 12 Oct 2003 22:31:41 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB3CA@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE2F6@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Randall, In my systems, no one loses any records. I don't rely on the transport mechanism to provide reliability. My point was that on the wire congestion is rarely the problem with high performance IPFIX style systems. Its primarily receiver resource issues. I don't expect, nor do I want, the transport layer to attempt to solve this type of problem. Carter > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Saturday, October 11, 2003 6:43 PM > To: carter@qosient.com > Cc: stbryant@cisco.com; alex.audu@alcatel.com; 'Reinaldo > Penno'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > Carter Bullard wrote: > > >Hey Stewart, > > > > > >>We should spend some time thinking about the behavior we want in the > >>exporter when the network is congested, perhaps due to an > >>attack. PR-SCTP > >>gives us the option of running a best effort data collection > >>to gleen what > >>is going on, when a TCP based exporter would otherwise > collapse due to > >>backlog on the exporter. > >> > >> > > > >This is a real engineering issue to talk about. Issues in > producer/consumer > >dynamics are real problems for IPFIX, especially when the flow record > >source is generating 1M records per second, which my probes > are capable > >of doing. In my experience, the reader/collector not keeping up is > >never a network congestion problem, it is almost always a > reader/collector > >resource problem, slow disks, not enough memory, competing processes, > >whatever. It happens in SMP multi-threaded environments > where the flow > >generator and its collector are on the same machine, it > happens when the > >consumer is on the other end of a dedicated ATM, hyper-channel or > >infiniband links. Its not an issue of reliable vs > unreliable transport, > >its more an issue of what does the probe do when it finds it > has 1M records > >that aren't being consumed, and another 1M records are > coming very soon. > >Does it store them, drop them with an indication? Does it > proactively seek > >an alternate association, the same association or does it > wait for the > >multiple readers to come back when they are ready. Are > there going to be > >multiple readers? > > > >Usually the monitor is being attacked, or its generating > twice the load > >because something else is being attacked in the network. No > congestion, > >just a lot of records. I don't think PR-SCTP touches these problems. > > > > > > > Well, I disagree here.. PR-SCTP has the ability to detect the > reader is not > reading.. i.e. its flow-controlled the sender. When this > occurs the sender > can start dumping records that are marked to dump... yes > tragic that you > loose these records.. but necessary in the situation you > define.. thus > you get > a double win: > > 1) You don't clog the network with the traffic since you are > dumping it at > the sender > 2) The receiver will have less to do since it will not get the traffic > 3) You can set things up to get the last bits so you know the things > that started the problem.. or if you desire you can set things > up to get the last events jettising the older things.... > > I think it will provide just what you want... at least to protect the > network.. and then > if everything is going ok (i.e. no floods or problems) you > get all the > records with no > errors or drops.. > > R > > >If you want the record generator to have a proactive role in > >failover and recover, maybe RTP/RTCP would be a better choice. > >Explicit feedback control channel provides enough to decide if > >it should fail over. > > > >Carter > > > > > > > >>Stewart > >> > >> > >> > >> > >>-- > >>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/ > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > -- 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 Sun Oct 12 23:14:59 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 XAA08528 for ; Sun, 12 Oct 2003 23:14:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8ssz-0001rm-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Oct 2003 21:56:41 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A8ssy-0001rZ-00 for ipfix@net.doit.wisc.edu; Sun, 12 Oct 2003 21:56:40 -0500 Received: (qmail 75289 invoked from network); 13 Oct 2003 02:56:39 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 13 Oct 2003 02:56:39 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9D2uaX30572; Sun, 12 Oct 2003 22:56:36 -0400 Reply-To: From: "Carter Bullard" To: "'Randall Stewart \(cisco\)'" Cc: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Benoit Claise'" , , , "'Reinaldo Penno'" , , Subject: RE: [ipfix] STCP as a default transport not Date: Sun, 12 Oct 2003 22:56:31 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6BE@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE304@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Randall, The paper is just one data point in my position that PR-SCTP is a new protocol, and probably too new to be the default and sole transport protocol for IPFIX. The proposal is to use PR-SCTP and you yourself stated that its just Cisco and HP for commercial vendors and 2 universities. HP is the only newcomer to bring PR-SCTP to a bakeoff in 2003, and the story is still 'its our intention to do PR-SCTP' for everyone else. That was the 20 or so vendors/university's position position in 2002. I'm now even more concerned that its taking some of these vendors 2 years to do PR-SCTP. And since you have no status on Sun, which I believe is a most telling statistic, I'm a bit more dubious about the extent of PR-SCTP's deployment. Lets just implement Netflow over PR-SCTP and lets see how it goes for a while before everyone decides to make it the default transport protocol. A demonstration doesn't sound too far fetched, does it? And of course if anyone could please apply the SCTP applicability RFC to IPFIX, then that would go a long way. I didn't know that IPFIX needed message boundary preservation. I don't even know what an IPFIX message boundary looks like. Carter > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Saturday, October 11, 2003 7:15 PM > To: carter@qosient.com > Cc: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise'; > stbryant@cisco.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > Carter: > > The paper you site.. and yes I am on it.. was the basis > we used to make sure "newreno" behavior for fast retransmit > was put into the SCTP implementors guide. Now most implementations > already were doing this (at least those I have talked to)... > > And as it is I don't think you will find true NewReno behavior > in ALL TCP implementations either :-< So I guess by this > reasoning TCP is also immature :-D > > SCTP is a VERY stable protocol that has a LOT of > implementations (over > 20 that I > know of... probably close to 30 if I took the time to count > them :>). Is > there more > research to do.. of course there is.. the same can be said for TCP.. > thats why > the TSVWG exists ..we are always trying to make things better :> > > R > > Carter Bullard wrote: > > >My principal concern is that SCTP is too young to be the > only transport. > >For example, a recent Univ. of Delaware Technical Document, > co-authored > >by Cisco, identifies a serious problem with SCTP congestion control > >when there are multiple drops in a single window, causing it > to degrade > >"more than necessary to be 'TCP-friendly', i.e. it grinds to > a dribble > >for a little while, while transmitting more packets. The link where > >you can get the publication is: > > > >http://www.eecis.udel.edu/~amer/PEL/poc/index.html > > > >The paper is "SCTP and TCP Variants: Congestion Control > Under Multiple > >Losses", very recent. The point is that these are the normal growing > >pains of a new protocol, but SCTP and PR-SCTP still have > some problems > >to iron out. > > > >Like Jeff, I have no problems with IPFIX running over PR-SCTP, but > >not as the only protocol. > > > >Carter > > > > > > > > > > > > > >>-----Original Message----- > >>From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > >>Sent: Friday, October 10, 2003 9:46 AM > >>To: 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1) > >>Cc: stbryant@cisco.com; alex.audu@alcatel.com; > >>carter@qosient.com; 'Reinaldo Penno'; > >>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; > rrs@cisco.com > >>Subject: RE: [ipfix] STCP as a default transport not > >> > >> > >>Benoit, > >> > >> I am not in any way against specifying IPFIX on top of PR-SCTP, > >>what I am against is making that the ONLY supported transport. > >>This is for practical reasons, like availability of implementation. > >>And as cited before because of transport protocols' affinity > >>for running in kernel vs. user space, the availability is going > >>to be a lot slower coming than one might like. > >> > >> I would liken this to deciding to define a transport layer > >>protocol which could only run on IPv6 and not IPv4. You could, > >>but if you can run on both, I think there are decided benefits. > >> > >> The Diameter authors seemed to have made this pragmatic choice. > >> > >> It is a bit ironic that previous decisions of the WG around > >>choice of candidate protocols were ultimately trumped by "practical > >>reasons" like NF is more widely deployed, despite the fact > >>that it was the only protocol with NO binding to a congestion > >>aware transport. And now, the arguments seem to be a complete > >>180 change. > >> > >>Regards, > >> > >> Jeff Meyer > >> > >> > >> > >>>-----Original Message----- > >>>From: Benoit Claise [mailto:bclaise@cisco.com] > >>>Sent: Friday, October 10, 2003 3:26 AM > >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) > >>>Cc: stbryant@cisco.com; alex.audu@alcatel.com; carter@qosient.com; > >>>'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > >>>ipfix@net.doit.wisc.edu; rrs@cisco.com > >>>Subject: Re: [ipfix] STCP as a default transport not > >>> > >>> > >>>Jeff, > >>> > >>>My point is that I'm convinced that SCTP-PR gives all the > >>> > >>> > >>advantages > >> > >> > >>>in one transport protocol. See the recent postings from Peter > >>>Lei; he knows the protocol a lot > >>>better than I do! > >>>Having the full flexibility (reliable, unreliable, partially > >>>reliable) in one transport protocol would be a plus. > >>>Let's give the flexibility to the different implementations. > >>>On the top of that, we don't know yet the future applications > >>>of IPFIX: > >>>PSAMP is one, exporting SLA information?, some MIB variables > >>>export?, etc... everything is possible since IPFIX is a generic > >>>export format. > >>>As I said, I think we should just use the right protocol > >>>instead of just > >>>using what exists. IMHO, SCTP_PR should be the target as transport > >>>transport. So, I would vote for SCTP with the PR extension. > >>> > >>>Regards, Benoit. > >>> > >>> > >>> > >>> > >>>>Benoit, > >>>> > >>>> SCTP-PR does not make me happy, nor do the previous decisions > >>>>around reliability as it regards to billing. > >>>> > >>>> Dropping packets under congestion is already done by UDP, and > >>>>UDP is ubiquitous in all OS's. > >>>> > >>>> Is there some challenge in defining IPFIX over TCP? It seems > >>>>to me that this is the easier case, there are less things to map > >>>>to vs. SCTP-PR. Is explicitly NOT defining a mapping to TCP > >>>>your proposal, i.e. force the use of SCTP-PR? > >>>> > >>>> As with the experience of Diameter, specifying both transports > >>>>will enable a migration to SCTP-PR for everyone if it actually > >>>>proves to have the values espoused and it is readily available. > >>>>In the interim having a TCP mapping (and UDP) would address the > >>>>requirements which I've encountered (billing issues aside). > >>>> > >>>> As Peter pointed out the resource constraints on the exporter > >>>>imposed by TCP can be mitigated in the implementation. > >>>> > >>>>Regards, > >>>> > >>>> Jeff Meyer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Benoit Claise [mailto:bclaise@cisco.com] > >>>>>Sent: Thursday, October 09, 2003 9:15 AM > >>>>>To: stbryant@cisco.com > >>>>>Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno'; > >>>>>'MEYER,JEFFREY D (HP-Cupertino,ex1)'; > >>>>> > >>>>> > >>>ipfix-chairs@net.doit.wisc.edu; > >>> > >>> > >>>>>ipfix@net.doit.wisc.edu; rrs@cisco.com > >>>>>Subject: Re: [ipfix] STCP as a default transport not > >>>>> > >>>>> > >>>>>Dear all, > >>>>> > >>>>>There are advantages regarding the use of SCTP versus TCP > >>>>> > >>>>> > >>>(discussed > >>> > >>> > >>>>>already on the list) but I think that the biggest advantage > >>>>>of SCTP is > >>>>>actually the extension SCTP-PR. And I'm surprised to see no > >>>>>reactions on > >>>>>the email below. > >>>>>Yes, I know that the SCTP-PR is not a standard yet but I > >>>>>think that we > >>>>>should just take the right protocol instead of just using > >>>>> > >>>>> > >>>what exists > >>> > >>> > >>>>>because it exists! > >>>>> > >>>>>I remember the heated discussions maybe one year ago about > >>>>>using IPFIX > >>>>>for billing, about high availability, etc... > >>>>>And one of the solution that could make everybody happy > >>>>> > >>>>> > >>is: SCTP-PR. > >> > >> > >>>>>We know that we do have some memory issues with TCP on the > >>>>>high-end routers. > >>>>>But, for the smaller exporter OR if you can afford/if it's > >>>>>possible to > >>>>>pack the exporter with the appropriate amount of memory, > >>>>>SCTP-PR would > >>>>>work perfectly well! > >>>>>Now, in the majority of cases (no billing, no enough > >>>>> > >>>>> > >>>memory/too many > >>> > >>> > >>>>>flow records, etc...) SCTP-PR would drop the flow records > >>>>>excess if any, > >>>>>which I think is the right thing to do. > >>>>> > >>>>>Regards, Benoit. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I think that the interest is in using PR-SCTP as described in > >>>>>> > >>>>>> > >>>>>> > >>>>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsc > tp-01.txt > >>>>> > >>>>> > >>>>>>rather than RFC 2960 SCTP. > >>>>>> > >>>>>>This claims the following benefits: > >>>>>> > >>>>>> > >>>>>>1.3 Benefits of PR-SCTP > >>>>>> > >>>>>> Hereafter, we use the notation "PR-SCTP" to refer to the SCTP > >>>>>> protocol extended as defined in this document. > >>>>>> > >>>>>> The following are some of the advantages for integrating > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>partially > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> reliable data service into SCTP, i.e., benefits of PR-SCTP: > >>>>>> > >>>>>> 1. Some application layer protocols may benefit from > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>being able to > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> use a single SCTP association to carry both reliable > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>content, -- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> such as text pages, billing and accounting > >>>>>> > >>>>>> > >>>information, setup > >>> > >>> > >>>>>> signaling -- and unreliable content, e.g. state that > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>is highly > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> sensitive to timeliness, where generating a new > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>packet is more > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> advantageous than transmitting an old one [1]. > >>>>>> > >>>>>> 2. Partially reliable data traffic carried by PR-SCTP > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>will enjoy the > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> same communication failure detection and protection > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>capabilities > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> as the normal reliable SCTP data traffic does. This > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>includes the > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> ability to: - quickly detect a failed destination > >>>>>> > >>>>>> > >>address; - > >> > >> > >>>>>> fail-over to an alternate destination address, and; > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>- be notified > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> if the data receiver becomes unreachable. > >>>>>> > >>>>>> 3. In addition to providing unordered unreliable data > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>transfer as > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> UDP does, PR-SCTP can provide ordered unreliable > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>data transfer > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> service. > >>>>>> > >>>>>> 4. PR-SCTP employs the same congestion control and congestion > >>>>>> avoidance for all data traffic, whether reliable or > >>>>>> > >>>>>> > >>>partially > >>> > >>> > >>>>>> reliable - this is very desirable since SCTP enforces > >>>>>> TCP-friendliness (unlike UDP.) > >>>>>> > >>>>>> 5. Because of the chunk bundling function of SCTP, > >>>>>> > >>>>>> > >>reliable and > >> > >> > >>>>>> unreliable messages can be multiplexed over a > >>>>>> > >>>>>> > >>single PR-SCTP > >> > >> > >>>>>> association. Therefore, the number of IP datagrams > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>(and hence > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> the network overhead) can be reduced versus having > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>to send these > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> different types of data using separate protocols. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>Additionally, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> this multiplexing allows for port savings versus > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>using different > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> ports for reliable and unreliable connections. > >>>>>> > >>>>>>---------- > >>>>>> > >>>>>>PR-SCTP has the option of being able to configure the > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>exporter to work > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>on a > >>>>>>best effort data export basis, rather than being > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>constrained to work on a > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>reliable basis. > >>>>>> > >>>>>>We should spend some time thinking about the behaviour we > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>want in the > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>exporter when the network is congested, perhaps due to an > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>attack. PR-SCTP > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>gives us the option of running a best effort data > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>collection to gleen > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>what > >>>>>>is going on, when a TCP based exporter would otherwise > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>collapse due to > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>backlog on the exporter. > >>>>>> > >>>>>>Stewart > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>-- > >>>>>>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/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > > > > > > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > -- 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 Oct 13 00:02:20 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 AAA09838 for ; Mon, 13 Oct 2003 00:02:19 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8tn0-0003dh-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Oct 2003 22:54:35 -0500 Received: from web80404.mail.yahoo.com ([66.218.79.59]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A8tmz-0003dZ-00 for ipfix@net.doit.wisc.edu; Sun, 12 Oct 2003 22:54:34 -0500 Message-ID: <20031013035432.82137.qmail@web80404.mail.yahoo.com> Received: from [67.127.69.185] by web80404.mail.yahoo.com via HTTP; Sun, 12 Oct 2003 20:54:32 PDT Date: Sun, 12 Oct 2003 20:54:32 -0700 (PDT) From: Peter Ludemann Subject: Re: [ipfix] STCP as a default transport not To: "Randall Stewart \(cisco\)" , Reinaldo Penno Cc: "'alex.audu@alcatel.com'" , carter@qosient.com, "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , stbryant@cisco.com, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu In-Reply-To: <3F889246.3000106@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver --- "Randall Stewart (cisco)" wrote: > While it is true that SCTP does NOT help with switching to > collector A to collector B transparently.. it does > allow the failure to be controled in a MUCH more reasonalbe > maner than TCP. Basically there > are knobs that you, the application designer, can tweak to > set the failover detection time to what > you want it to be... this is something that is nearly > impossible in most TCP stacks... Isn't this a property of the API, not of the protocol? It is unfortunate that most (all?) TCP implementations do not give access to the "tweak"ing at the application level, but require global kernel parameter setting. The SCTP API designer should be applauded for avoiding this mistake of the TCP APIs. I apologise if I am out of date on the SCTP implementations -- I've looked at RFC 2960, draft-ietf-tsvwg-sctpsocket-07.txt and http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp-api.pdf . Perhaps I missed something, but these seem to not give APPLICATION-level confirmation of receipt of data, but only communication-level confirmation. So, for full reliability, IPFIX needs to have its own confirmation mechanism (the data might have been received at the transport layer but the application might have crashed before processing it); and IPFIX/TCP can provide a fail-over mechanism as good as SCTP's by using the application-level acknowledgment mechanism (by the way, the application-level acknowledgment has very small overhead, compared to TCP's/SCTP's). I do agree that SCTP is a better protocol than TCP for IPFIX, because of its message orientation and because of its better support for fail-over. Nevertheless, it does not solve *all* the issues for reliability and fail-over (or, rather, the APIs that I have looked at do not solve the issues) and -- if full reliability is desired -- the IPFIX protocol must have its own features for filling in the missing pieces. But this is just repeating old arguments that have been voted down by those who don't need/want reliability. Perhaps what is needed is a set of optional features for implementing a fully reliable IPFIX for those who need it. The default protocol for unreliable IPFIX might even be different than for reliable IPFIX. And for unreliable IPFIX, TCP seems "good enough" and more common than SCTP. -- 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 Oct 13 00:08:03 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 AAA09917 for ; Mon, 13 Oct 2003 00:08:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8tpe-0003fz-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Oct 2003 22:57:18 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A8tpd-0003fu-00 for ipfix@net.doit.wisc.edu; Sun, 12 Oct 2003 22:57:17 -0500 Received: (qmail 85134 invoked from network); 13 Oct 2003 03:57:14 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 13 Oct 2003 03:57:14 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9D3vDX30596; Sun, 12 Oct 2003 23:57:13 -0400 Reply-To: From: "Carter Bullard" To: "'Randall Stewart \(cisco\)'" Cc: "'Peter Lei'" , , "'David Moore'" , "'Nevil Brownlee'" Subject: RE: [ipfix] Congestion management Date: Sun, 12 Oct 2003 23:57:08 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6BF@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE308@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Randall, I believe that my statements about PR-SCTP are on the money, based on my personal experience with PR-SCTP, monitoring it, reading its documents and talking/email with others who have experience with it. I think the draft speaks for itself, and its pretty light reading. > > > And, of course, you don't > >get some required features such as congestion detection, > >without turning on some rather constrained behavior. For > >instance you can't do any kind of loss detection with > > > > > Huh? how do you reach this conclusion? Having the U bit > set makes NO differenct to loss detection. No matter if a > Data chunk is ordered or unordered you will detect loss. Here is section 4.4 of your current draft. 4.4 Usage Notes Detecting missing data in a PR-SCTP stream is useful for some applications (e.g. Fiber channel or SCSI over IP). With PR-SCTP this becomes possible - the upper layer simply needs to examine the stream sequence number of the arrived user messages of that stream to detect any missing data. Note, this detection only works when all the messages on that stream are sent in order, i.e., the "U" bit is not set. Can I set the "U" bit and still detect missing data at the application level? If so, what does section 4.4 mean? > > > If you are behind NATs then you need to do the singly homed > thing.. this > does > work.. its just you lose the benefits of multi-homing .. we > actually run > this > as a test at the bakeoff...aka getting through a NAT > The point is that many functions of PR-SCTP don't work in the real world of "the Big-I". NAT traversal is a real concern, and so you are saying that multihoming doesn't work in conventional Internet deployments. That is an important data point in making a decision for, or against, PR-SCTP's default transport. This of course doesn't address the fundamental problems with PR-SCTP multi-homing and IPSec. The issue is that some features of PR-SCTP cannot support the security model of IPFIX. >>I'm sure you feel that SCTP-PR is the most efficient mechanism >>for transporting bulk records at 100 Mbps across a single hop >>dedicated link, but does anyone have any real experience to >>back this position? > Well we are talking of things beyond a single link network. > Otherwise why > are we standardizing it in the IETF? The IETF standardizes things that > run across the Big-I not things that are in your local LAN.. > Well, the world of IPFIX type devices is that they usually (> 90%) have directly attached collectors. I don't expect IPFIX devices to transport their data over "the Big-I". I don't think anyone in the working group expects this. Your reaction suggests to me that you wouldn't necessarily recommend PR-SCTP for transporting data over single hop dedicated high speed links. Is that a true statement? > R > Carter -- 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 Oct 13 03:12:55 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 DAA25300 for ; Mon, 13 Oct 2003 03:12:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A8wjv-0001XU-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 02:03:35 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A8wju-0001XP-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 02:03:34 -0500 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9D73SIR000759; Mon, 13 Oct 2003 00:03:29 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4355.cisco.com [10.61.81.2]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA05672; Mon, 13 Oct 2003 08:03:26 +0100 (BST) Message-ID: <3F8A4E3D.5000401@cisco.com> Date: Mon, 13 Oct 2003 08:03:25 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush CC: Nevil Brownlee , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6B1@ptah.newyork.qosient.com> <1065736364.4336dedb83483@hotlava.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Randy Bush wrote: >>The WG issue which we opened at the Vienna meeting was "what should we >>specify as a *default* transport for IPFIX?" > > > i suggest it be phrased as "mandatory to implement," so you can be sure > it is there. > > if one knows *for sure* one is in special circumstances, e.g. on a local > wire, one might use optional transports. Some text of the form TTL SHOULD be set to one might help. Stewart > > but the congestion-friendly transport is mandatory to implement and the > default. > > randy > > > -- > 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 Oct 13 10:16:59 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 KAA07241 for ; Mon, 13 Oct 2003 10:16:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A939N-0007lV-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 08:54:17 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A939L-0007lM-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 08:54:16 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9DDrJIU007294; Mon, 13 Oct 2003 06:53:19 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANB58179; Mon, 13 Oct 2003 06:53:17 -0700 (PDT) Message-ID: <3F8AAE4C.4030403@cisco.com> Date: Mon, 13 Oct 2003 08:53:16 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'Peter Lei'" , ipfix@net.doit.wisc.edu, "'David Moore'" , "'Nevil Brownlee'" Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6BF@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6BF@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: >Hey Randall, >I believe that my statements about PR-SCTP are on the money, >based on my personal experience with PR-SCTP, monitoring it, >reading its documents and talking/email with others who have >experience with it. > > I think the draft speaks for itself, >and its pretty light reading. > > That is strange.. a lot of your comments imply you do not understand SCTP in general.... PR-SCTP works in conjunction with SCTP since it is nothing more than an extension to SCTP... I would also be curious on who has mis-lead you on PR-SCTP... it seems from you comments you don't see how it can be used like unto UDP but with the congestion control advantages... and even more so taylored to IPFIX via a buffer based sender profile... I am familiar with most all the implementations and implementors of SCTP and PR-SCTP and it surprises me that any of them would so mis-lead you :-< > > >>> And, of course, you don't >>>get some required features such as congestion detection, >>>without turning on some rather constrained behavior. For >>>instance you can't do any kind of loss detection with >>> >>> >>> >>> >>Huh? how do you reach this conclusion? Having the U bit >>set makes NO differenct to loss detection. No matter if a >>Data chunk is ordered or unordered you will detect loss. >> >> > >Here is section 4.4 of your current draft. > >4.4 Usage Notes > > Detecting missing data in a PR-SCTP stream is useful for some > applications (e.g. Fiber channel or SCSI over IP). With PR-SCTP this > becomes possible - the upper layer simply needs to examine the stream > sequence number of the arrived user messages of that stream to detect > any missing data. Note, this detection only works when all the > messages on that stream are sent in order, i.e., the "U" bit is not > set. > >Can I set the "U" bit and still detect missing data at the >application level? If so, what does section 4.4 mean? > > > This is just one possiblity.. the sender KNOWS what messages were skipped by local reports. If this information is critical to tabulate via statisitcs or other mechanism then it can be passed later after the congestion/attack/event... Just because the draft gives one particular example does not mean there are not more than one way to use it :>... and not only that, that statement was taylored to a particular application using PR-SCTP aka iSCSI which has differerent needs and requirements than IPFIX would... In fact I would imagine the timed service is NOT what is needed for IPFIX but instead (as I stated earlier) a buffer based scheme is needed. After all you don't care how long it takes to get the ipflow info across as long as you are not being flooded with information. So if a transient congestion event occurs and you are not maxing out your buffer space you want to get all the info across no matter how long it takes.. the only time you want to start dropping things is when you are running out of space... >>If you are behind NATs then you need to do the singly homed >>thing.. this >>does >>work.. its just you lose the benefits of multi-homing .. we >>actually run >>this >>as a test at the bakeoff...aka getting through a NAT >> >> >> > >The point is that many functions of PR-SCTP don't work >in the real world of "the Big-I". NAT traversal is a real >concern, and so you are saying that multihoming doesn't work >in conventional Internet deployments. That is an important >data point in making a decision for, or against, PR-SCTP's >default transport. > > > NAT traversal with multi-homing definetly will reduce you to a single homed endpoint... until a NAT-2-NAT protocol is developed to make NAT's share state... evil evil evil in my opinion.. then you will have this problem. Now is it realistic that you will be crossing NAT boundaries for IPFIX... your earlier email implies just the opposite.. its on a LAN segment one hop away. In such a deployment then the multi-homing can be fully taken advantage of.. even if I deploy it across a wide variety of hops within an ISP as long as they are on the same private network.. multi-homing will work perfectly fine... giving a nice advantage for PR-SCTP and SCTP in IPFIX at no real cost to the IPFIX applicaiton... >This of course doesn't address the fundamental problems with >PR-SCTP multi-homing and IPSec. The issue is that some features >of PR-SCTP cannot support the security model of IPFIX. > > > And what security model is that.. IPSEC will work with SCTP.. and thus with PR-SCTP... even a conventional multi-homed environment can work (that does not include the IPSEC extensions).. you end up with LOTS of SPID's but that can be made to work. Again... what is your target at one point you talk about UDP being one hop away.. the next we are talking about inter-net backbone carrying multi-homed and across IPSEC and NAT traversal tied in. ANY or ALL of the environments can work with SCTP by the way.. but it would be nice to get a clear picture of what environment you wish to run IPFIX over.... >>>I'm sure you feel that SCTP-PR is the most efficient mechanism >>>for transporting bulk records at 100 Mbps across a single hop >>>dedicated link, but does anyone have any real experience to >>>back this position? >>> >>> > > > >>Well we are talking of things beyond a single link network. >>Otherwise why >>are we standardizing it in the IETF? The IETF standardizes things that >>run across the Big-I not things that are in your local LAN.. >> >> >> > >Well, the world of IPFIX type devices is that they usually (> 90%) >have directly attached collectors. I don't expect IPFIX devices >to transport their data over "the Big-I". I don't think anyone >in the working group expects this. > > > Ok then where do the multi-homed NATS come in? >Your reaction suggests to me that you wouldn't necessarily recommend >PR-SCTP for transporting data over single hop dedicated high speed >links. Is that a true statement? > > > No.. I have done LOADS of testing of PR-SCTP over a single hop network.. and I have watched it do line-rate transfer... There is no problem with it.. it works fine... And.. fill in multiple other senders adding congestion to the network and it will drop what it is supposed to reducing the overall congestion on the network.. R >>R >> >> >> > >Carter > > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Oct 13 10:58:47 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 KAA10233 for ; Mon, 13 Oct 2003 10:58:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A940t-0001bk-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 09:49:35 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A940r-0001bc-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 09:49:33 -0500 Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by comcast.net (rwcrmhc11) with SMTP id <2003101314493201300qptp4e>; Mon, 13 Oct 2003 14:49:32 +0000 Message-ID: <3F8ABB51.7040603@ieee.org> Date: Mon, 13 Oct 2003 09:48:49 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: ipfix@net.doit.wisc.edu, "'David Moore'" , "'Nevil Brownlee'" Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6B7@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6B7@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: > Hey Peter, > You have to incur SCTP-PR functions regardless if you > use them or not. The draft is very clear on this fact. > SCTP-PR doesn't modify the wire protocol, so -PR doesn't > reduce any overhead states or messages. It simply modifies > the API and some sender semantics. And, of course, you don't > get some required features such as congestion detection, > without turning on some rather constrained behavior. For > instance you can't do any kind of loss detection with > SCTP-PR unless you use in order delivery (no "U" bits set). > That can't be too efficient. And the header is huge, what > is it? a common header, a chunk header and a data > header, we're talking, what, 32 bytes? I'm not sure what you are getting at here... of course the functions have to be there in order for you to get the functionality... Please re-read the draft... PR-SCTP does indeed extend the on-the-wire protocol; it is NOT just an API change. The setting of the "U" bits does NOT "disable" loss detection; the whole association is congestion controlled. And that is the point. I'd like to have IPFIX and provide reliable and un-reliable service while being congestion controlled; and I can do this with one association between a probe and collector. This is why IMO PR-SCTP fits so nicely. > One problem I see is that IPFIX will use IPSec for its security. > Without RFC 3554, "On the Use of Stream Control Transmission > Protocol (SCTP) with Ipsec", which is not widely implemented, > IPSec isn't compatible with SCTP features like multi-homing, > basically making the fail-over mechanisms unuseable, and > of course NAT doesn't work with multi-homing. Yes, without RFC 3554 one cannot do multi-homed SCTP w/IPsec efficiently. I would argue this is no different than the TCP case today, i.e. you need multiple associations. However, at least SCTP gives you the *possibility* of doing this with one association once IPSec implementations catchup w/3554. > I'm sure you feel that SCTP-PR is the most efficient mechanism > for transporting bulk records at 100 Mbps across a single hop > dedicated link, but does anyone have any real experience to > back this position? Well, it is probably not the "most efficient"... but this isn't the general case we're designing IPFIX for, are we? If so, we can forget the NAT arguments. And yes, we definitely have done high rate bulk data transfers with SCTP/PR-SCTP. regards, --peter > Carter > > > > > -----Original Message----- > From: Peter Lei [mailto:peter.lei@ieee.org] > Sent: Friday, October 10, 2003 12:06 AM > To: ipfix@net.doit.wisc.edu > Cc: carter@qosient.com; 'David Moore'; 'Nevil Brownlee' > Subject: Re: [ipfix] Congestion management > > > Carter Bullard wrote: > >>Hey David, >> SCTP-PR is partial reliable, not unreliable. You >>can't seem to turn off the failure detection and >>protection capabilities of normal reliable SCTP, nor can >>you turn off the congestion avoidance logic of SCTP, so >>it is definitely more complex and more expensive compared >>to say RTP/UDP, and probably TCP. > > > PR-SCTP can definitely be "unreliable" if you so choose; > have the service definition be "try this only once please" > and the stack will only trasmit each send() call once. > > If the transport choice is to be "congestion controlled", > why would NOT do congestion avoidance?! The feedback loop > is exactly what allows SCTP to have TCP-friendly congetion > control. > > I see failure detection as a benefit, not a detriment... > It certainly would be nice to know that the transport has > "gone away" so I can maybe failover to an alternate > collector. Plus, I don't want to send packets needlessly > if the collector has somehow crashed (e.g. might cause > congestion?) > > >> The key is to find a transition technology for the >>1000's of existing IP flow monitors that are purely >>UDP based today. A simple transitional technology >>should be appropriate, and I think RTP/UDP is a good >>one, especially since the IESG has historically accepted >>it as passing the congestion awareness criteria. >> >> I'm personally concerned that the only mentioned >>transport candidates are connection-oriented and unicast >>only. There are serious advantages to connection-less >>transports and multicast support, and I'm interested in >>ensuring that IPFIX can explore those advantages. Neither >>SCTP-PR or TCP can support multicast, so I'm an advocate >>of a three transport model. > > > > >> But Nevil is right, the real issue is what should be the >>default transport for IPFIX, and here it seems to me that >>SCTP-PR should NOT be the default, although there is enough >>consensus for it to be a supported transport. TCP seems to >>be the only real candidate for the default, simply from an >>interoperability standpoint. If you've only got one shot >>at attaching to an IP flow probe, are you going to use SCTP-PR >>or TCP, if the probe could support either, but not both? >>I think TCP will be the higher probability choice, which >>would make it the default, by default. > > > I disagree... picking TCP as the default tranport for reliable > data then requires you to use RTP/UDP for the unreliable data > (unless you want to send it ALL over TCP)... > > SCTP w/PR-SCTP extension allows both (over the same association > even, if desired) and IMO seems to provide all the transport > services that IPFIX requires. > > regards, > --peter > > >>Carter >> >> >> >> >> >>>-----Original Message----- >>>From: David Moore [mailto:dmoore@caida.org] >>>Sent: Thursday, October 09, 2003 7:37 PM >>>To: Carter Bullard >>>Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] Congestion management >>> >>> >>>On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: >>> >>> >>>> When you're dealing with 1M+ records per second, the >>>>concepts of record loss detection and selective retransmission >>>>are just not practical. With these types of monitors, if >>>>there is packet loss, there really isn't any way that the probes >>>>can slow down, so, like RFC 3497, the concept would have to be >>>>to have some type of feedback signal so the probe can stop. >>>>So RTP/RTCP sounds good. I'd rather IPFIX send the message, >>>>but the concept of IPFIX being congestion aware itself seems >>>>to have dropped through a fissure somewhere. >>> >>>With SCTP-PR, afaik, allows you to tune whether you want any >>>particular pieces of sent data to be reliable or unreliable. By >>>setting every piece to be unreliable, then you have UDP in terms >>>of reliability. However, SCTP-PR has the feedback signal which >>>already provides TCP-friendly congestion avoidance. >>> >>>Is there some performance cost to SCTP-PR when all data is marked >>>unreliable that you feel is too high, to require building a different >>>feedback mechanism on top of UDP to also have congestion avoidance? >>> >>>I understand the desire for a UDP transport which has no congestion >>>avoidance. But if the goal is something UDP-like (unreliable) but >>>which does have congestion avoidance, IPFIX should use something >>>already a standard (or about to be a standard) rather than inventing >>>its own. >>> >>> >>>-- david >>> >> >> >> >> >> >>-- >>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 Mon Oct 13 11:11: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 LAA10545 for ; Mon, 13 Oct 2003 11:11:00 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A94AI-0001w3-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 09:59:18 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A94AH-0001vx-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 09:59:18 -0500 Received: (qmail 56033 invoked from network); 13 Oct 2003 14:59:17 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 13 Oct 2003 14:59:17 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9DExGX31173; Mon, 13 Oct 2003 10:59:16 -0400 Reply-To: From: "Carter Bullard" To: "'Randall Stewart \(cisco\)'" Cc: "'Peter Lei'" , , "'David Moore'" , "'Nevil Brownlee'" Subject: RE: [ipfix] Congestion management Date: Mon, 13 Oct 2003 10:59:12 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6C0@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE3DC@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Randall, So please lets focus on one issue at a time. Your draft states: 4.4 Usage Notes Detecting missing data in a PR-SCTP stream is useful for some applications (e.g. Fiber channel or SCSI over IP). With PR-SCTP this becomes possible - the upper layer simply needs to examine the stream sequence number of the arrived user messages of that stream to detect any missing data. Note, this detection only works when all the messages on that stream are sent in order, i.e., the "U" bit is not set. Seems like this is referring to receiver side data loss detection at the application level, which I believe is important (a requirement?) of IPFIXs. Seems pretty definitive, and an issue important enough to get its own section, so I expect it to be a true statement. So, is in order message delivery a requirement for receiver side data loss detection using PR-SCTP? Carter -- 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 Oct 13 12:31: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 MAA14185 for ; Mon, 13 Oct 2003 12:31:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A95TO-0004WR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 11:23:06 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A95TM-0004WM-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 11:23:05 -0500 Received: (qmail 98209 invoked from network); 13 Oct 2003 16:23:03 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 13 Oct 2003 16:23:03 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9DGN3X31222; Mon, 13 Oct 2003 12:23:03 -0400 Reply-To: From: "Carter Bullard" To: "'Peter Lei'" Cc: , "'David Moore'" , "'Nevil Brownlee'" Subject: RE: [ipfix] Congestion management Date: Mon, 13 Oct 2003 12:22:59 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6C2@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE3E3@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Peter, The issue is that PR-SCTP is being advocated as the protocol for both reliable and un-reliable transport for IPFIX. In my due diligence in trying to understand if PR-SCTP is appropriate for the unreliable transport requirements of IPFIX, I have to get past the statements of enthusiastic support, which are always optimistic and never revealing, and get to the reality of the protocol. First and foremost, and this has been reiterated by all so far, PR-SCTP is SCTP with only minor changes. When running in its most unreliable mode of operation PR-SCTP imposes states for the sender and receiver, there are memory requirements and protocol interfaces that a switch/router will have to support for SCTP's congestion control, which cannot be turned off. These are resources that a router currently does not have to spend when transporting Netflow over UDP. In most installations of IPFIX (> 90%), congestion control is not a requirement, as the collector is directly connected to the switch/router. In these cases, PR-SCTP may not be an appropriate protocol. It is very important that everyone realize that PR-SCTP is not being advocated because it can be as efficient as Netflow over UDP when it is operating as an unreliable transport. But for those 10% that do need congestion control, where the data is traversing multiple hops, and PR-SCTP may be appropriate, you run into issues like NAT and you have new requirements for security. These are issues that are real problems for some people that do need to be mentioned and discussed. Carter > -----Original Message----- > From: Peter Lei [mailto:peter.lei@ieee.org] > Sent: Monday, October 13, 2003 9:49 AM > To: carter@qosient.com > Cc: ipfix@net.doit.wisc.edu; 'David Moore'; 'Nevil Brownlee' > Subject: Re: [ipfix] Congestion management > > > Carter Bullard wrote: > > Hey Peter, > > You have to incur SCTP-PR functions regardless if you > > use them or not. The draft is very clear on this fact. > > SCTP-PR doesn't modify the wire protocol, so -PR doesn't > > reduce any overhead states or messages. It simply modifies > > the API and some sender semantics. And, of course, you don't > > get some required features such as congestion detection, > > without turning on some rather constrained behavior. For > > instance you can't do any kind of loss detection with > > SCTP-PR unless you use in order delivery (no "U" bits set). > > That can't be too efficient. And the header is huge, what > > is it? a common header, a chunk header and a data > > header, we're talking, what, 32 bytes? > > I'm not sure what you are getting at here... of course the > functions have to be there in order for you to get the > functionality... > > Please re-read the draft... PR-SCTP does indeed extend the > on-the-wire protocol; it is NOT just an API change. > > The setting of the "U" bits does NOT "disable" loss detection; > the whole association is congestion controlled. And that is > the point. I'd like to have IPFIX and provide reliable and > un-reliable service while being congestion controlled; and I > can do this with one association between a probe and collector. > This is why IMO PR-SCTP fits so nicely. > > > > One problem I see is that IPFIX will use IPSec for its security. > > Without RFC 3554, "On the Use of Stream Control Transmission > > Protocol (SCTP) with Ipsec", which is not widely implemented, > > IPSec isn't compatible with SCTP features like multi-homing, > > basically making the fail-over mechanisms unuseable, and > > of course NAT doesn't work with multi-homing. > > Yes, without RFC 3554 one cannot do multi-homed SCTP w/IPsec > efficiently. I would argue this is no different than the TCP > case today, i.e. you need multiple associations. However, at > least SCTP gives you the *possibility* of doing this with one > association once IPSec implementations catchup w/3554. > > > I'm sure you feel that SCTP-PR is the most efficient mechanism > > for transporting bulk records at 100 Mbps across a single hop > > dedicated link, but does anyone have any real experience to > > back this position? > > Well, it is probably not the "most efficient"... but this isn't > the general case we're designing IPFIX for, are we? If so, we > can forget the NAT arguments. And yes, we definitely have done > high rate bulk data transfers with SCTP/PR-SCTP. > > regards, > --peter > > > Carter > > > > > > > > > > -----Original Message----- > > From: Peter Lei [mailto:peter.lei@ieee.org] > > Sent: Friday, October 10, 2003 12:06 AM > > To: ipfix@net.doit.wisc.edu > > Cc: carter@qosient.com; 'David Moore'; 'Nevil Brownlee' > > Subject: Re: [ipfix] Congestion management > > > > > > Carter Bullard wrote: > > > >>Hey David, > >> SCTP-PR is partial reliable, not unreliable. You > >>can't seem to turn off the failure detection and > >>protection capabilities of normal reliable SCTP, nor can > >>you turn off the congestion avoidance logic of SCTP, so > >>it is definitely more complex and more expensive compared > >>to say RTP/UDP, and probably TCP. > > > > > > PR-SCTP can definitely be "unreliable" if you so choose; > > have the service definition be "try this only once please" > > and the stack will only trasmit each send() call once. > > > > If the transport choice is to be "congestion controlled", > > why would NOT do congestion avoidance?! The feedback loop > > is exactly what allows SCTP to have TCP-friendly congetion > > control. > > > > I see failure detection as a benefit, not a detriment... > > It certainly would be nice to know that the transport has > > "gone away" so I can maybe failover to an alternate > > collector. Plus, I don't want to send packets needlessly > > if the collector has somehow crashed (e.g. might cause > > congestion?) > > > > > >> The key is to find a transition technology for the > >>1000's of existing IP flow monitors that are purely > >>UDP based today. A simple transitional technology > >>should be appropriate, and I think RTP/UDP is a good > >>one, especially since the IESG has historically accepted > >>it as passing the congestion awareness criteria. > >> > >> I'm personally concerned that the only mentioned > >>transport candidates are connection-oriented and unicast > >>only. There are serious advantages to connection-less > >>transports and multicast support, and I'm interested in > >>ensuring that IPFIX can explore those advantages. Neither > >>SCTP-PR or TCP can support multicast, so I'm an advocate > >>of a three transport model. > > > > > > > > >> But Nevil is right, the real issue is what should be the > >>default transport for IPFIX, and here it seems to me that > >>SCTP-PR should NOT be the default, although there is enough > >>consensus for it to be a supported transport. TCP seems to > >>be the only real candidate for the default, simply from an > >>interoperability standpoint. If you've only got one shot > >>at attaching to an IP flow probe, are you going to use SCTP-PR > >>or TCP, if the probe could support either, but not both? > >>I think TCP will be the higher probability choice, which > >>would make it the default, by default. > > > > > > I disagree... picking TCP as the default tranport for reliable > > data then requires you to use RTP/UDP for the unreliable data > > (unless you want to send it ALL over TCP)... > > > > SCTP w/PR-SCTP extension allows both (over the same association > > even, if desired) and IMO seems to provide all the transport > > services that IPFIX requires. > > > > regards, > > --peter > > > > > >>Carter > >> > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: David Moore [mailto:dmoore@caida.org] > >>>Sent: Thursday, October 09, 2003 7:37 PM > >>>To: Carter Bullard > >>>Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > >>>Subject: Re: [ipfix] Congestion management > >>> > >>> > >>>On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: > >>> > >>> > >>>> When you're dealing with 1M+ records per second, the > >>>>concepts of record loss detection and selective retransmission > >>>>are just not practical. With these types of monitors, if > >>>>there is packet loss, there really isn't any way that the probes > >>>>can slow down, so, like RFC 3497, the concept would have to be > >>>>to have some type of feedback signal so the probe can stop. > >>>>So RTP/RTCP sounds good. I'd rather IPFIX send the message, > >>>>but the concept of IPFIX being congestion aware itself seems > >>>>to have dropped through a fissure somewhere. > >>> > >>>With SCTP-PR, afaik, allows you to tune whether you want any > >>>particular pieces of sent data to be reliable or unreliable. By > >>>setting every piece to be unreliable, then you have UDP in terms > >>>of reliability. However, SCTP-PR has the feedback signal which > >>>already provides TCP-friendly congestion avoidance. > >>> > >>>Is there some performance cost to SCTP-PR when all data is marked > >>>unreliable that you feel is too high, to require building > a different > >>>feedback mechanism on top of UDP to also have congestion avoidance? > >>> > >>>I understand the desire for a UDP transport which has no congestion > >>>avoidance. But if the goal is something UDP-like (unreliable) but > >>>which does have congestion avoidance, IPFIX should use something > >>>already a standard (or about to be a standard) rather than > inventing > >>>its own. > >>> > >>> > >>>-- david > >>> > >> > >> > >> > >> > >> > >>-- > >>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 Mon Oct 13 15:08: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 PAA21076 for ; Mon, 13 Oct 2003 15:08:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A97tB-0001I7-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 13:57:53 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A97t9-0001I2-00; Mon, 13 Oct 2003 13:57:51 -0500 Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel12.hp.com (Postfix) with ESMTP id 086A91C021E2; Mon, 13 Oct 2003 11:57:51 -0700 (PDT) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id EE4F01004B9B; Mon, 13 Oct 2003 11:57:50 -0700 (PDT) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <4V0BP183>; Mon, 13 Oct 2003 11:57:50 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296039D@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Randall Stewart (cisco)'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Mon, 13 Oct 2003 11:57:41 -0700 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 Stewart, By availability I mean you take the system out of the box and w/in 5 minutes of booting you are able to use the service. TCP fits this criteria. Perhaps that is also true for SCTP on IOS, I would presume given your arguments. However on no other platform other than Linux am I aware of this availability. SCTP does not come preloaded on Windows, Solaris or HP-UX, and if I go the the Microsoft, Sun and HP sites looking for infomration on how to configure SCTP, I get either nothing or a reference to 3rd party (for fee) products to enable this. So, although in your world this may still count as "available". In the world of delivering multiplatform capable packaged collection SW which can be installed rapidly, it just don't cut it. -- Jeff -----Original Message----- From: Randall Stewart (cisco) [mailto:rrs@cisco.com] Sent: Saturday, October 11, 2003 5:02 PM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'Benoit Claise'; 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > Benoit, > > In answer to your question "So why have TCP at all?" > > I'll repeat, ready availability of implementations on common platforms. > > The cost of packaging and certifying a collector solution on TCP vs. > SCTP is going to be SIGNIFICANTLY less expensive. Because SCTP > belongs in kernel vs. user space, this is not going to just magically > become ubiquitous. > > I guess if your goal is to limit collectors to C implementations on > Linux or BSD then one could argue that "we have it now". However if > Windows or Java are targets for collection platforms, you're kinda > stuck at the moment. I don't think these are insignificant > considerations. > Jeff: SCTP is available on HP-UX Solaris Linux BSD IOS and even Windows.. At the last bake-off for SCTP HP-UX's stack demonstrated PR-SCTP testing against the U-of-Essen, BSD and Cisco-IOS Linux's version were pre-liminary and not tested until next bakeoff (at least that is my understanding).. The windoz implementations were a bit behind.. Sun was not present at this bakeoff.. so I don't know there status.. Bottom line is its out there.. its being used in a LOT of telephone signalling apps and it is NOT more expensive.. R > -- Jeff > > -----Original Message----- > *From:* Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Thursday, October 09, 2003 9:15 AM > *To:* MEYER,JEFFREY D (HP-Cupertino,ex1) > *Cc:* 'stbryant@cisco.com'; carter@qosient.com; > alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > *Subject:* Re: [ipfix] STCP as a default transport not > > Jeff, > > I would like to comment on your recommendations. > >>Hi, >> >> I guess there is a concern of whether we are approaching this from >>the "optimize for the usual case" or "optimize for the worst case". >> >> The former is usually preferred. >> >> The general concern seems to be appropriate "capacity" on the >>collector side so that little to no back pressure occurs on the >>sender. >> >> UDP's fire and forget model makes this trivial, but its lack of >>congestion aware behavior is apparently a no no. From the discussion >>it sounds like PR_SCTP has similar properties on overflow, where >>things just get tossed, like the behavior of the input UDP socket >>buffer when the collector is falling behind. >> >> However, in a mode where the collector is sufficiently endowed >>to consume over TCP, which would hopefully be the majority of >>situations, taking advantage of TCP's ubiquity and reliability >>properties makes a lot of sense to me. >> >> I'm still dubious of whether disallowing UDP (which happens to >>be the only current concrete binding of NFv9) in favor of SCTP-PR >>is really the best approach. >> >> Personally I'd recommend: >> >> o bindings over TCP for reliable communication while accomodating for >> some failover mechanism if the collector becomes congested or >>disabled; >> > But if there is no congestion, I assume that SCTP_PR would do the > same good job as TCP in term of reliability. > And we know that TCP would have too big memory requirements in > case of congestion. Hence you propose to failover mechanism. > So why have TCP at all? > >> o bindings of UDP for best effort (i.e. no exporter back pressure) in >> >> configurations where exporter and collector are coresident and >>congestion >> aware behavior is not a concern; >> > We tried very hard this path. It's a NO from the area director, > even for coresident exporter/collector. > >> o binding of PR_SCTP where congestion aware behavior and best effort >>are >> desired. >> > So I conclude that there is only solution left that makes sense! > PR_SCTP. > > Regards, Benoit. > >>Regards, >> >> Jeff Meyer >> >> >> >>>-----Original Message----- >>>From: Stewart Bryant [mailto:stbryant@cisco.com] >>>Sent: Wednesday, October 08, 2003 6:09 AM >>>To: carter@qosient.com >>>Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D >>>(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>>ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] STCP as a default transport not >>> >>> >>> >>> >>>Carter Bullard wrote: >>> >>> >>> >>>>Hey Stewart, >>>> >>>> >>>> >>>>>We should spend some time thinking about the behavior we want in the >>>>>exporter when the network is congested, perhaps due to an >>>>>attack. PR-SCTP >>>>>gives us the option of running a best effort data collection >>>>>to gleen what >>>>>is going on, when a TCP based exporter would otherwise >>>>> >>>>> >>>collapse due to >>> >>> >>>>>backlog on the exporter. >>>>> >>>>> >>>>This is a real engineering issue to talk about. Issues in >>>> >>>> >>>producer/consumer >>> >>> >>>>dynamics are real problems for IPFIX, especially when the >>>> >>>> >>>flow record >>> >>> >>>>source is generating 1M records per second, which my probes >>>> >>>> >>>are capable >>> >>> >>>>of doing. In my experience, the reader/collector not keeping up is >>>>never a network congestion problem, it is almost always a >>>> >>>> >>>reader/collector >>> >>> >>>>resource problem, slow disks, not enough memory, competing >>>> >>>> >>>processes, >>> >>> >>>>whatever. >>>> >>>> >>>The critical issue is which side of TCP does it occur. If TCP >>>has accepted >>>the data then the collector application had better do some >>>intelligent. >>>My concern is with the exporter or probe having a backlog for >>>any reason. >>> >>> >>> >>>>It happens in SMP multi-threaded environments where the flow >>>>generator and its collector are on the same machine, it >>>> >>>> >>>happens when the >>> >>> >>>>consumer is on the other end of a dedicated ATM, hyper-channel or >>>>infiniband links. Its not an issue of reliable vs >>>> >>>> >>>unreliable transport, >>> >>> >>>>its more an issue of what does the probe do when it finds >>>> >>>> >>>it has 1M records >>> >>> >>>>that aren't being consumed, and another 1M records are >>>> >>>> >>>coming very soon. >>> >>>On this point we absolutely agree. >>> >>> >>> >>>>Does it store them, drop them with an indication? >>>> >>>> >>>I think that we have to assume that it does not have the storage. >>> >>> From the PR_SCTP draft: >>> >>> One example of partially reliable service is specified in this >>> document, namely a "timed reliability" service. This >>>service allows >>> the service user to indicate a limit on the duration of >>>time that the >>> sender should try to transmit/retransmit the message (this is a >>> natural extension of the "lifetime" parameter already in the base >>> protocol). >>> >>>This seems to have the right properties >>> >>> >>> >>>>Does it proactively seek >>>>an alternate association, the same association or does it >>>> >>>> >>>wait for the >>> >>> >>>>multiple readers to come back when they are ready. Are >>>> >>>> >>>there going to be >>> >>> >>>>multiple readers? >>>> >>>>Usually the monitor is being attacked, or its generating >>>> >>>> >>>twice the load >>> >>> >>>>because something else is being attacked in the network. >>>> >>>> >>>No congestion, >>> >>> >>>>just a lot of records. >>>> >>>> >>>Anything that means that the exporter has a bunch of data wedged in >>>its output queues waiting for an ACK looks like congestion to >>>the exporter. >>> >>> >>> >>>>I don't think PR-SCTP touches these problems. >>>> >>>>If you want the record generator to have a proactive role in >>>>failover and recover, maybe RTP/RTCP would be a better choice. >>>>Explicit feedback control channel provides enough to decide if >>>>it should fail over. >>>> >>>> >>>As I recall RTP requires the application to define its own approach to >>>congestion, and we do have to have a congestion strategy. It would >>>be better to use a congestion aware transport that has a build-in >>>strategy to bail-out if there is a problem, and PR-SCTP has just those >>>properties. >>> >>>Stewart >>> >>> >>> >>> >>>>Carter >>>> >>>> >>>> >>>> >>>>>Stewart >>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>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/ >> >> > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Oct 13 15:20: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 PAA22199 for ; Mon, 13 Oct 2003 15:20:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A981L-0001WR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 14:06:19 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A981K-0001WM-00; Mon, 13 Oct 2003 14:06:18 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 946191C02B64; Mon, 13 Oct 2003 15:06:17 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 8AC3F1C0009B; Mon, 13 Oct 2003 15:06:17 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4V7MCPLS>; Mon, 13 Oct 2003 15:06:17 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296039E@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Randall Stewart (cisco)'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Mon, 13 Oct 2003 15:06:13 -0400 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 Randall, When you ask "Why wouldn't I take the best of both worlds w/ SCTP", I think you are missing the point. I am perfectly fine with defining a binding on top of SCTP. What I don't want is for that to be the only defined binding. The reasons are based on the practical availability of SCTP to customers on both new and existing systems. TCP and UDP are there already, to use SCTP in many situations will produce a lousy customer experience, especially when being loaded on an existing system. Is there some particular reason why a binding to TCP (and UDP) in addition to PR-SCTP is infeasable? Here you get the tecnical elegance of PR-SCTP for all to see and the ability to allow others to make use of legacy platforms which may have prohibitive factors against the use of SCTP? -- Jeff -----Original Message----- From: Randall Stewart (cisco) [mailto:rrs@cisco.com] Sent: Saturday, October 11, 2003 4:54 PM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >Hi, > > I guess there is a concern of whether we are approaching this from >the "optimize for the usual case" or "optimize for the worst case". > > The former is usually preferred. > > The general concern seems to be appropriate "capacity" on the >collector side so that little to no back pressure occurs on the >sender. > > UDP's fire and forget model makes this trivial, but its lack of >congestion aware behavior is apparently a no no. From the discussion >it sounds like PR_SCTP has similar properties on overflow, where >things just get tossed, like the behavior of the input UDP socket >buffer when the collector is falling behind. > > However, in a mode where the collector is sufficiently endowed >to consume over TCP, which would hopefully be the majority of >situations, taking advantage of TCP's ubiquity and reliability >properties makes a lot of sense to me. > > I'm still dubious of whether disallowing UDP (which happens to >be the only current concrete binding of NFv9) in favor of SCTP-PR >is really the best approach. > > Personally I'd recommend: > > o bindings over TCP for reliable communication while accomodating for > some failover mechanism if the collector becomes congested or >disabled; > o bindings of UDP for best effort (i.e. no exporter back pressure) in > > configurations where exporter and collector are coresident and >congestion > aware behavior is not a concern; > o binding of PR_SCTP where congestion aware behavior and best effort >are > desired. > > > Jeff: But you miss a big point in this... Why not o bind over SCTP for the reliabile data o and send PR-SCTP for the case where you have records you are willing to give up in the crisis SCTP in combination with PR-SCTP will: 1) Deliver all reliable information for you JUST LIKE TCP 2) During normal times all the records you are prepared to drop in a distress situation will get across TOTALLY reliably. 3) When you hit the rare situation .. the sender will begin to drop protecting your network.. So why would you not take the best of both worlds.. which is what SCTP can offer you with PR-SCTP... they work on the same association.. R >Regards, > > Jeff Meyer > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Wednesday, October 08, 2003 6:09 AM >>To: carter@qosient.com >>Cc: alex.audu@alcatel.com; 'Reinaldo Penno'; 'MEYER,JEFFREY D >>(HP-Cupertino,ex1)'; ipfix-chairs@net.doit.wisc.edu; >>ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] STCP as a default transport not >> >> >> >> >>Carter Bullard wrote: >> >> >> >>>Hey Stewart, >>> >>> >>> >>>>We should spend some time thinking about the behavior we want in the >>>>exporter when the network is congested, perhaps due to an >>>>attack. PR-SCTP >>>>gives us the option of running a best effort data collection >>>>to gleen what >>>>is going on, when a TCP based exporter would otherwise >>>> >>>> >>collapse due to >> >> >>>>backlog on the exporter. >>>> >>>> >>>This is a real engineering issue to talk about. Issues in >>> >>> >>producer/consumer >> >> >>>dynamics are real problems for IPFIX, especially when the >>> >>> >>flow record >> >> >>>source is generating 1M records per second, which my probes >>> >>> >>are capable >> >> >>>of doing. In my experience, the reader/collector not keeping up is >>>never a network congestion problem, it is almost always a >>> >>> >>reader/collector >> >> >>>resource problem, slow disks, not enough memory, competing >>> >>> >>processes, >> >> >>>whatever. >>> >>> >>The critical issue is which side of TCP does it occur. If TCP >>has accepted >>the data then the collector application had better do some >>intelligent. >>My concern is with the exporter or probe having a backlog for >>any reason. >> >> >> >>>It happens in SMP multi-threaded environments where the flow >>>generator and its collector are on the same machine, it >>> >>> >>happens when the >> >> >>>consumer is on the other end of a dedicated ATM, hyper-channel or >>>infiniband links. Its not an issue of reliable vs >>> >>> >>unreliable transport, >> >> >>>its more an issue of what does the probe do when it finds >>> >>> >>it has 1M records >> >> >>>that aren't being consumed, and another 1M records are >>> >>> >>coming very soon. >> >>On this point we absolutely agree. >> >> >> >>>Does it store them, drop them with an indication? >>> >>> >>I think that we have to assume that it does not have the storage. >> >> From the PR_SCTP draft: >> >> One example of partially reliable service is specified in this >> document, namely a "timed reliability" service. This >>service allows >> the service user to indicate a limit on the duration of >>time that the >> sender should try to transmit/retransmit the message (this is a >> natural extension of the "lifetime" parameter already in the base >> protocol). >> >>This seems to have the right properties >> >> >> >>>Does it proactively seek >>>an alternate association, the same association or does it >>> >>> >>wait for the >> >> >>>multiple readers to come back when they are ready. Are >>> >>> >>there going to be >> >> >>>multiple readers? >>> >>>Usually the monitor is being attacked, or its generating >>> >>> >>twice the load >> >> >>>because something else is being attacked in the network. >>> >>> >>No congestion, >> >> >>>just a lot of records. >>> >>> >>Anything that means that the exporter has a bunch of data wedged in >>its output queues waiting for an ACK looks like congestion to >>the exporter. >> >> >> >>>I don't think PR-SCTP touches these problems. >>> >>>If you want the record generator to have a proactive role in >>>failover and recover, maybe RTP/RTCP would be a better choice. >>>Explicit feedback control channel provides enough to decide if >>>it should fail over. >>> >>> >>As I recall RTP requires the application to define its own approach to >>congestion, and we do have to have a congestion strategy. It would >>be better to use a congestion aware transport that has a build-in >>strategy to bail-out if there is a problem, and PR-SCTP has just those >>properties. >> >>Stewart >> >> >> >> >>>Carter >>> >>> >>> >>> >>>>Stewart >>>> >>>> >>>> >>>> >>>>-- >>>>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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Oct 13 15:25:24 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 PAA22385 for ; Mon, 13 Oct 2003 15:25:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A98BN-0001sn-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 14:16:41 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A98BL-0001sg-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 14:16:39 -0500 Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by comcast.net (rwcrmhc12) with SMTP id <20031013191637014009kqbce>; Mon, 13 Oct 2003 19:16:37 +0000 Message-ID: <3F8AF9EA.5040501@ieee.org> Date: Mon, 13 Oct 2003 14:15:54 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6C2@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6C2@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter Bullard wrote: > Hey Peter, > The issue is that PR-SCTP is being advocated as the > protocol for both reliable and un-reliable transport > for IPFIX. In my due diligence in trying to understand > if PR-SCTP is appropriate for the unreliable transport > requirements of IPFIX, I have to get past the statements > of enthusiastic support, which are always optimistic and > never revealing, and get to the reality of the protocol. Nor would I argue that we shouldn't do due diligence here... > First and foremost, and this has been reiterated by > all so far, PR-SCTP is SCTP with only minor changes. > When running in its most unreliable mode of operation > PR-SCTP imposes states for the sender and receiver, > there are memory requirements and protocol interfaces > that a switch/router will have to support for SCTP's > congestion control, which cannot be turned off. These > are resources that a router currently does not have to > spend when transporting Netflow over UDP. Yes, as I mentioned before, you DO need to have those memory/ protocol requirements there... however, they would already exist if you are doing reliable export with SCTP. Unless you are going to mandate multiple transports (like SCTP + x/UDP, or TCP + x/UDP), I don't believe you will get the efficiency that you want from a single default transport without doing something like SCTP + PR-SCTP. As mentioned in another thread in this list, one can constrain the memory utilization of the PR-SCTP stack. > In most installations of IPFIX (> 90%), congestion control > is not a requirement, as the collector is directly connected > to the switch/router. In these cases, PR-SCTP may not > be an appropriate protocol. It is very important that > everyone realize that PR-SCTP is not being advocated because > it can be as efficient as Netflow over UDP when it is > operating as an unreliable transport. We already know we aren't going to get a transport protocol as efficient as UDP if it must be congestion controlled. And as mentioned several times on this list, congestion control IS a hard requirement. Given that IPFIX must have congestion control anyways with the default transport, that's why SCTP+PR-SCTP is being advocated. If there wasn't that requirement, folks would still be using UDP for flow export... or maybe that's what you are proposing?? I haven't seen an explicit recommendation for an alternative so far, beyond UDP or RTP/UDP. > But for those 10% that do need congestion control, where > the data is traversing multiple hops, and PR-SCTP may be > appropriate, you run into issues like NAT and you have > new requirements for security. These are issues that are > real problems for some people that do need to be mentioned > and discussed. Agreed... and at the worst case, I don't believe these are any more difficult than the TCP case w/multi-homing. You can always "fall back" to having singly homeed associations that look like TCP connections-- in that scenario, SCTP will work fine with exisiting IPSec and NAT implementations. --peter > Carter > > > > > >>-----Original Message----- >>From: Peter Lei [mailto:peter.lei@ieee.org] >>Sent: Monday, October 13, 2003 9:49 AM >>To: carter@qosient.com >>Cc: ipfix@net.doit.wisc.edu; 'David Moore'; 'Nevil Brownlee' >>Subject: Re: [ipfix] Congestion management >> >> >>Carter Bullard wrote: >> >>>Hey Peter, >>> You have to incur SCTP-PR functions regardless if you >>>use them or not. The draft is very clear on this fact. >>>SCTP-PR doesn't modify the wire protocol, so -PR doesn't >>>reduce any overhead states or messages. It simply modifies >>>the API and some sender semantics. And, of course, you don't >>>get some required features such as congestion detection, >>>without turning on some rather constrained behavior. For >>>instance you can't do any kind of loss detection with >>>SCTP-PR unless you use in order delivery (no "U" bits set). >>>That can't be too efficient. And the header is huge, what >>>is it? a common header, a chunk header and a data >>>header, we're talking, what, 32 bytes? >> >>I'm not sure what you are getting at here... of course the >>functions have to be there in order for you to get the >>functionality... >> >>Please re-read the draft... PR-SCTP does indeed extend the >>on-the-wire protocol; it is NOT just an API change. >> >>The setting of the "U" bits does NOT "disable" loss detection; >>the whole association is congestion controlled. And that is >>the point. I'd like to have IPFIX and provide reliable and >>un-reliable service while being congestion controlled; and I >>can do this with one association between a probe and collector. >>This is why IMO PR-SCTP fits so nicely. >> >> >> >>>One problem I see is that IPFIX will use IPSec for its security. >>>Without RFC 3554, "On the Use of Stream Control Transmission >>>Protocol (SCTP) with Ipsec", which is not widely implemented, >>>IPSec isn't compatible with SCTP features like multi-homing, >>>basically making the fail-over mechanisms unuseable, and >>>of course NAT doesn't work with multi-homing. >> >>Yes, without RFC 3554 one cannot do multi-homed SCTP w/IPsec >>efficiently. I would argue this is no different than the TCP >>case today, i.e. you need multiple associations. However, at >>least SCTP gives you the *possibility* of doing this with one >>association once IPSec implementations catchup w/3554. >> >> >>>I'm sure you feel that SCTP-PR is the most efficient mechanism >>>for transporting bulk records at 100 Mbps across a single hop >>>dedicated link, but does anyone have any real experience to >>>back this position? >> >>Well, it is probably not the "most efficient"... but this isn't >>the general case we're designing IPFIX for, are we? If so, we >>can forget the NAT arguments. And yes, we definitely have done >>high rate bulk data transfers with SCTP/PR-SCTP. >> >>regards, >>--peter >> >> >>>Carter >>> >>> >>> >>> >>>-----Original Message----- >>>From: Peter Lei [mailto:peter.lei@ieee.org] >>>Sent: Friday, October 10, 2003 12:06 AM >>>To: ipfix@net.doit.wisc.edu >>>Cc: carter@qosient.com; 'David Moore'; 'Nevil Brownlee' >>>Subject: Re: [ipfix] Congestion management >>> >>> >>>Carter Bullard wrote: >>> >>> >>>>Hey David, >>>> SCTP-PR is partial reliable, not unreliable. You >>>>can't seem to turn off the failure detection and >>>>protection capabilities of normal reliable SCTP, nor can >>>>you turn off the congestion avoidance logic of SCTP, so >>>>it is definitely more complex and more expensive compared >>>>to say RTP/UDP, and probably TCP. >>> >>> >>>PR-SCTP can definitely be "unreliable" if you so choose; >>>have the service definition be "try this only once please" >>>and the stack will only trasmit each send() call once. >>> >>>If the transport choice is to be "congestion controlled", >>>why would NOT do congestion avoidance?! The feedback loop >>>is exactly what allows SCTP to have TCP-friendly congetion >>>control. >>> >>>I see failure detection as a benefit, not a detriment... >>>It certainly would be nice to know that the transport has >>>"gone away" so I can maybe failover to an alternate >>>collector. Plus, I don't want to send packets needlessly >>>if the collector has somehow crashed (e.g. might cause >>>congestion?) >>> >>> >>> >>>> The key is to find a transition technology for the >>>>1000's of existing IP flow monitors that are purely >>>>UDP based today. A simple transitional technology >>>>should be appropriate, and I think RTP/UDP is a good >>>>one, especially since the IESG has historically accepted >>>>it as passing the congestion awareness criteria. >>>> >>>> I'm personally concerned that the only mentioned >>>>transport candidates are connection-oriented and unicast >>>>only. There are serious advantages to connection-less >>>>transports and multicast support, and I'm interested in >>>>ensuring that IPFIX can explore those advantages. Neither >>>>SCTP-PR or TCP can support multicast, so I'm an advocate >>>>of a three transport model. >>> >>> > >>> >>>> But Nevil is right, the real issue is what should be the >>>>default transport for IPFIX, and here it seems to me that >>>>SCTP-PR should NOT be the default, although there is enough >>>>consensus for it to be a supported transport. TCP seems to >>>>be the only real candidate for the default, simply from an >>>>interoperability standpoint. If you've only got one shot >>>>at attaching to an IP flow probe, are you going to use SCTP-PR >>>>or TCP, if the probe could support either, but not both? >>>>I think TCP will be the higher probability choice, which >>>>would make it the default, by default. >>> >>> >>>I disagree... picking TCP as the default tranport for reliable >>>data then requires you to use RTP/UDP for the unreliable data >>>(unless you want to send it ALL over TCP)... >>> >>>SCTP w/PR-SCTP extension allows both (over the same association >>>even, if desired) and IMO seems to provide all the transport >>>services that IPFIX requires. >>> >>>regards, >>>--peter >>> >>> >>> >>>>Carter >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: David Moore [mailto:dmoore@caida.org] >>>>>Sent: Thursday, October 09, 2003 7:37 PM >>>>>To: Carter Bullard >>>>>Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu >>>>>Subject: Re: [ipfix] Congestion management >>>>> >>>>> >>>>>On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote: >>>>> >>>>> >>>>> >>>>>> When you're dealing with 1M+ records per second, the >>>>>>concepts of record loss detection and selective retransmission >>>>>>are just not practical. With these types of monitors, if >>>>>>there is packet loss, there really isn't any way that the probes >>>>>>can slow down, so, like RFC 3497, the concept would have to be >>>>>>to have some type of feedback signal so the probe can stop. >>>>>>So RTP/RTCP sounds good. I'd rather IPFIX send the message, >>>>>>but the concept of IPFIX being congestion aware itself seems >>>>>>to have dropped through a fissure somewhere. >>>>> >>>>>With SCTP-PR, afaik, allows you to tune whether you want any >>>>>particular pieces of sent data to be reliable or unreliable. By >>>>>setting every piece to be unreliable, then you have UDP in terms >>>>>of reliability. However, SCTP-PR has the feedback signal which >>>>>already provides TCP-friendly congestion avoidance. >>>>> >>>>>Is there some performance cost to SCTP-PR when all data is marked >>>>>unreliable that you feel is too high, to require building >> >>a different >> >>>>>feedback mechanism on top of UDP to also have congestion avoidance? >>>>> >>>>>I understand the desire for a UDP transport which has no congestion >>>>>avoidance. But if the goal is something UDP-like (unreliable) but >>>>>which does have congestion avoidance, IPFIX should use something >>>>>already a standard (or about to be a standard) rather than >> >>inventing >> >>>>>its own. >>>>> >>>>> >>>>>-- david >>>>> >>>> >>>> >>>> >>>> >>>> >>>>-- >>>>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 Mon Oct 13 16:19: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 QAA25975 for ; Mon, 13 Oct 2003 16:19:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9936-0003dU-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 15:12:12 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A9935-0003dM-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 15:12:11 -0500 Received: (qmail 12543 invoked from network); 13 Oct 2003 20:12:10 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 13 Oct 2003 20:12:10 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9DKCAX31357; Mon, 13 Oct 2003 16:12:10 -0400 Reply-To: From: "Carter Bullard" To: "'Peter Lei'" Cc: Subject: RE: [ipfix] Congestion management Date: Mon, 13 Oct 2003 16:12:07 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6C3@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE40E@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Peter, The default transport has to have some congestion awareness, and given the IESG recent track record, that doesn't mean integrated congestion control, just awareness. There is no requirement that any other transport bindings must support congestion awareness. You still work for Cisco, right? So, maybe you can tell us when you guys will be able to demonstrate Netflow over PR-SCTP in an existing router. That really should be the litmus test for getting a binding in the IPFIX protocol. Hopefully without having to put in a specific blade to enable it. Carter -- 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 Oct 13 16:40:18 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 QAA27661 for ; Mon, 13 Oct 2003 16:40:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A99KI-00047w-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 15:29:58 -0500 Received: from mailhub.lawrence.edu ([143.44.65.14] helo=lawrence.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A99KG-00047p-00; Mon, 13 Oct 2003 15:29:56 -0500 Received: from [143.44.97.19] (HELO lawrence.edu) by lawrence.edu (CommuniGate Pro SMTP 4.0.6) with ESMTP id 1704063; Mon, 13 Oct 2003 16:03:07 -0500 Message-ID: <3F8B0B44.8090402@lawrence.edu> Date: Mon, 13 Oct 2003 15:29:56 -0500 From: Robert Lowe Organization: Lawrence University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A50296039D@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: Hi Jeff! > By availability I mean you take the system out of the box and w/in 5 > minutes > of booting you are able to use the service. TCP fits this criteria. > Perhaps > that is also true for SCTP on IOS, I would presume given your arguments. > However on no other platform other than Linux am I aware of this > availability. > > SCTP does not come preloaded on Windows, Solaris or HP-UX, and if I go the > the > Microsoft, Sun and HP sites looking for infomration on how to configure > SCTP, I get > either nothing or a reference to 3rd party (for fee) products to enable > this. > > So, although in your world this may still count as "available". In the > world of delivering multiplatform capable packaged collection SW which can > be > installed rapidly, it just don't cut it. De-lurking again... ;-) I assume we're talking about collectors here, not exporters. Where do most collectors run today? Just a wild guess, but a majority on Linux or moving there? I could be wrong though. Either way, you're providing the same argumentation that you, and others, didn't agree with regarding candidate protocols, i.e. Netflow is more widely implemented, making IPFIX more likely to be implemented, therefore better. I mean, I can remember a day when Microsoft didn't have their own implementation of TCP/IP, and noone worried. I'm not advocating a "build it and they will come" approach, but I also recognize that solutions do not always win out based solely on technical merit. So are you wrong? Maybe not, but as Carter suggests, it is important to ensure that the transport is not a hindrance to any of the other requirements. So, if I had any say, I'd recommend focusing the discussion on any interactions between any proposed transport and other requirements, not overly worrying about what the landscape looks like today for both implementers and end-customers, other than perhaps architecture, which also has direct bearing on how exporter, collector, and any intervening network will behave under stress. Over and out, Robert -- 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 Oct 13 17:31: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 RAA00328 for ; Mon, 13 Oct 2003 17:31:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9AAA-0005qQ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 16:23:34 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9AA8-0005qK-00; Mon, 13 Oct 2003 16:23:32 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id CA7DE1C0293D; Mon, 13 Oct 2003 17:23:31 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id BA1391C000A8; Mon, 13 Oct 2003 17:23:31 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4VNVLJCM>; Mon, 13 Oct 2003 17:23:31 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A5029603A1@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Robert Lowe'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Mon, 13 Oct 2003 17:23:27 -0400 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 Robert, I agree with your points, with the one caveat that user vs. kernel space (where SCTP belongs) makes the ubiquity step just that much harder. I especially agree with the focus on "restrictions imposed by the transport". I believe that the message set defined in the IPFIX protocol to date is relatively transport neutral. Hence the additional overhead of specifying the binding details to TCP and PR-SCTP seem relatively straightforward, i.e. Diameter seemed to have no trouble here. So all I'd like to see is a preservation of that transport independence and explicit bindings to TCP and PR-SCTP (in addition to the existing UDP binding which is prevalent today). The conversation seems to have devolved into a "You only need SCTP and shouldn't use anything else" which I think ignores some practical matters in terms of rapid implementation and adoption. Regards, Jeff Meyer -----Original Message----- From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] Sent: Monday, October 13, 2003 1:30 PM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: Hi Jeff! > By availability I mean you take the system out of the box and w/in 5 > minutes > of booting you are able to use the service. TCP fits this criteria. > Perhaps > that is also true for SCTP on IOS, I would presume given your arguments. > However on no other platform other than Linux am I aware of this > availability. > > SCTP does not come preloaded on Windows, Solaris or HP-UX, and if I go the > the > Microsoft, Sun and HP sites looking for infomration on how to configure > SCTP, I get > either nothing or a reference to 3rd party (for fee) products to enable > this. > > So, although in your world this may still count as "available". In the > world of delivering multiplatform capable packaged collection SW which can > be > installed rapidly, it just don't cut it. De-lurking again... ;-) I assume we're talking about collectors here, not exporters. Where do most collectors run today? Just a wild guess, but a majority on Linux or moving there? I could be wrong though. Either way, you're providing the same argumentation that you, and others, didn't agree with regarding candidate protocols, i.e. Netflow is more widely implemented, making IPFIX more likely to be implemented, therefore better. I mean, I can remember a day when Microsoft didn't have their own implementation of TCP/IP, and noone worried. I'm not advocating a "build it and they will come" approach, but I also recognize that solutions do not always win out based solely on technical merit. So are you wrong? Maybe not, but as Carter suggests, it is important to ensure that the transport is not a hindrance to any of the other requirements. So, if I had any say, I'd recommend focusing the discussion on any interactions between any proposed transport and other requirements, not overly worrying about what the landscape looks like today for both implementers and end-customers, other than perhaps architecture, which also has direct bearing on how exporter, collector, and any intervening network will behave under stress. Over and out, Robert -- 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 Oct 13 18:17: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 SAA03138 for ; Mon, 13 Oct 2003 18:17:44 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9AtN-0007GM-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 17:10:17 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9AtM-0007G9-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 17:10:16 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9AtK-000Jj0-4M; Mon, 13 Oct 2003 22:10:14 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9AtJ-000C6O-2q; Tue, 14 Oct 2003 00:10:13 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 14 Oct 2003 00:10:12 +0200 To: "Carter Bullard" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED661CE40E@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607A6C3@ptah.newyork.qosient.com> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > The default transport has to have some congestion awareness, > and given the IESG recent track record, that doesn't mean > integrated congestion control, just awareness. not bleedin' likely -- 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 Oct 13 18:31:52 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 SAA03504 for ; Mon, 13 Oct 2003 18:31:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9B5M-0007gF-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 17:22:40 -0500 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9B5L-0007g8-00; Mon, 13 Oct 2003 17:22:39 -0500 Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by comcast.net (rwcrmhc13) with SMTP id <2003101322223501500ki65le>; Mon, 13 Oct 2003 22:22:35 +0000 Message-ID: <3F8B257E.6040104@ieee.org> Date: Mon, 13 Oct 2003 17:21:50 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A5029603A1@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A5029603A1@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Robert, > > I agree with your points, with the one caveat that user vs. kernel space > (where SCTP belongs) makes the ubiquity step just that much harder. Please clarify this statement for me... SCTP is in kernel space for both Linux and xBSD platforms... there is a normal sockets API for SCTP. There is even a TCP "compatible" API such that we have been able to port SSH, FTP, Apache web server, and Mozilla browser by changes a hand few lines of code (in the socket() call change the IPPROTO_TCP or "0" to IPPROTO_SCTP). > I especially agree with the focus on "restrictions imposed by the > transport". > > I believe that the message set defined in the IPFIX protocol to date is > relatively transport neutral. Hence the additional overhead of specifying > the binding details to TCP and PR-SCTP seem relatively straightforward, > i.e. Diameter seemed to have no trouble here. > > So all I'd like to see is a preservation of that transport independence > and explicit bindings to TCP and PR-SCTP (in addition to the existing UDP > binding which is prevalent today). I don't see a problem with this... none of the transports being discussed places any changes/constraints on the IPFIX protocol itself. It MAY require the IPFIX application layer choice of "do I want to this reliable or unreliable" which might mean choose a different socket descriptor or change a parameter in my send call (in the case of PR-SCTP)... but these are known apriori by the application. > The conversation seems to have devolved into a "You only need SCTP and > shouldn't use anything else" which I think ignores some practical matters > in terms of rapid implementation and adoption. The question posed (and remains the topic of discussion) is "what should the default transport for IPFIX be"... I read that as "if you MUST support only ONE transport, what should it be, given that we want congestion control and both reliable and unreliable export." Diameter essentially makes SCTP the default protocol (it shoud be tried first), and TCP the "fallback". Servers are required to support both. From RFC 3588: 2.1. Transport Transport profile is defined in [AAATRANS]. The base Diameter protocol is run on port 3868 of both TCP [TCP] and SCTP [SCTP] transport protocols. Diameter clients MUST support either TCP or SCTP, while agents and servers MUST support both. Future versions of this specification MAY mandate that clients support SCTP. [snip] When connecting to a peer and either zero or more transports are specified, SCTP SHOULD be tried first, followed by TCP. See Section 5.2 for more information on peer discovery. regards, --peter > Regards, > > Jeff Meyer > > > -----Original Message----- > From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > Sent: Monday, October 13, 2003 1:30 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; > carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > Hi Jeff! > > >> By availability I mean you take the system out of the box and w/in 5 >>minutes >>of booting you are able to use the service. TCP fits this criteria. >>Perhaps >>that is also true for SCTP on IOS, I would presume given your arguments. >>However on no other platform other than Linux am I aware of this >>availability. >> >> SCTP does not come preloaded on Windows, Solaris or HP-UX, and if I go > > the > >>the >>Microsoft, Sun and HP sites looking for infomration on how to configure >>SCTP, I get >>either nothing or a reference to 3rd party (for fee) products to enable >>this. >> >> So, although in your world this may still count as "available". In the >>world of delivering multiplatform capable packaged collection SW which can >>be >>installed rapidly, it just don't cut it. > > > De-lurking again... ;-) > > I assume we're talking about collectors here, not exporters. Where do most > collectors run today? Just a wild guess, but a majority on Linux or moving > there? I could be wrong though. > > Either way, you're providing the same argumentation that you, and others, > didn't agree with regarding candidate protocols, i.e. Netflow is more > widely implemented, making IPFIX more likely to be implemented, therefore > better. I mean, I can remember a day when Microsoft didn't have their own > implementation of TCP/IP, and noone worried. I'm not advocating a "build > it and they will come" approach, but I also recognize that solutions do not > always win out based solely on technical merit. So are you wrong? Maybe > not, but as Carter suggests, it is important to ensure that the transport > is not a hindrance to any of the other requirements. So, if I had any say, > I'd recommend focusing the discussion on any interactions between any > proposed transport and other requirements, not overly worrying about what > the landscape looks like today for both implementers and end-customers, > other than perhaps architecture, which also has direct bearing on how > exporter, collector, and any intervening network will behave under stress. > > Over and out, > Robert > > -- > 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 Oct 13 18:32: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 SAA03541 for ; Mon, 13 Oct 2003 18:32:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9B4y-0007fs-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 17:22:16 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A9B4x-0007fm-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 17:22:15 -0500 Received: (qmail 65322 invoked from network); 13 Oct 2003 22:22:14 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 13 Oct 2003 22:22:14 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9DMMEX31442; Mon, 13 Oct 2003 18:22:14 -0400 Reply-To: From: "Carter Bullard" To: "'Randy Bush'" Cc: Subject: RE: [ipfix] Congestion management Date: Mon, 13 Oct 2003 18:22:11 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6C4@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE429@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Well if you're going to make comments like that, you have to explain RFC 3497. How can the IESG approve 1.485 Gbps over RTP/UDP, and then state that IPFIX has to use TCP? Explain yourself. > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Randy Bush > Sent: Monday, October 13, 2003 5:10 PM > To: Carter Bullard > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] Congestion management > > > > The default transport has to have some congestion awareness, > > and given the IESG recent track record, that doesn't mean > > integrated congestion control, just awareness. > > not bleedin' likely > > > -- > 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 Oct 13 18: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 SAA04093 for ; Mon, 13 Oct 2003 18:50:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9BMf-0000RR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 17:40:33 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9BMe-0000RM-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 17:40:32 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9BMd-000M3v-Rb; Mon, 13 Oct 2003 22:40:32 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9BMd-000C9E-2R; Tue, 14 Oct 2003 00:40:31 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 14 Oct 2003 00:40:30 +0200 To: "Carter Bullard" Cc: Subject: RE: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED661CE429@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607A6C4@ptah.newyork.qosient.com> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Well if you're going to make comments like that, you > have to explain RFC 3497. we'll let those who passed it explain themselves. i have forwarded your mail. > How can the IESG approve 1.485 Gbps over RTP/UDP, and then state > that IPFIX has to use TCP? i am not aware of stating that ipfix had to use tcp. but it will have to supply a mandatory to implement congestion friendly transport. randy -- 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 Oct 13 19:08:55 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 TAA04564 for ; Mon, 13 Oct 2003 19:08:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9BS9-0000X2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 17:46:13 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9BS8-0000Wx-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 17:46:12 -0500 Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by comcast.net (rwcrmhc11) with SMTP id <2003101322461101300bugfpe>; Mon, 13 Oct 2003 22:46:11 +0000 Message-ID: <3F8B2B07.4010801@ieee.org> Date: Mon, 13 Oct 2003 17:45:27 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6C3@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6C3@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Hey Peter, > The default transport has to have some congestion awareness, > and given the IESG recent track record, that doesn't mean > integrated congestion control, just awareness. There is no > requirement that any other transport bindings must support > congestion awareness. Umm.... are you sure about that?! Randy's (Bush) previous email stated "congestion-friendly transport is mandatory to implement and the default." In order to be "friendly" the transport has to do something to mitigate congestion, not just be "aware" that it's happening... > You still work for Cisco, right? So, maybe you can > tell us when you guys will be able to demonstrate Netflow over > PR-SCTP in an existing router. That really should be the > litmus test for getting a binding in the IPFIX protocol. > Hopefully without having to put in a specific blade to > enable it. > > Carter > > > > > -- > 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 Oct 13 19:40:30 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 TAA05475 for ; Mon, 13 Oct 2003 19:40:30 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9Bzi-0001iA-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 18:20:54 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9Bzh-0001hz-00; Mon, 13 Oct 2003 18:20:53 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id 5D9E81C02405; Mon, 13 Oct 2003 19:20:52 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 513FA1C000A8; Mon, 13 Oct 2003 19:20:52 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4V7MDXP9>; Mon, 13 Oct 2003 19:20:52 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A5029603A3@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Peter Lei'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, alex.audu@alcatel.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Mon, 13 Oct 2003 19:20:50 -0400 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 Peter, Here's what I meant by my statement: In general it is easier to develop and deliver user space applications, vs. kernel modules. Things like portability of code, installation procedures, impact of bugs are more signficant issues in kernel space. SCTP, like UDP and TCP is best suited as an OS service, although one could develop an entirely user space application over raw IP sockets, but it would have limitations like easily sharing SCTP services across multiple processes. The SCTP API is simply the way a user space process makes use of the kernel module enabling SCTP. Consider the quandry of a SW developer wanting to build a shiny new IPFIX compliant offering on a variety of platforms. Java would sure make that handy, but there is no SCTP API binding for Java. Writing in C/C++ allows you to use the SCTP API, but you still require the SCTP stack. This isn't available preinstalled on platforms other than Linux that I know of. HP, Sun and Microsoft don't appear to be offering easy downloads to turn this on, so you are forced to either roll your own (e.g. hire a different set of developers) or to partner with some SCTP provider and inflate the price of your offering. Now for the SIGTRAN type applications which were initially targeted by SCTP, I can imagine that this premium is acceptable, after all the alternative was even more costly and complex IN/SS7 equipment and stacks. For IPFIX this is not the current state of affairs. -- Jeff -----Original Message----- From: Peter Lei [mailto:peter.lei@ieee.org] Sent: Monday, October 13, 2003 3:22 PM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'Robert Lowe'; 'Randall Stewart (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not > Robert, > > I agree with your points, with the one caveat that user vs. kernel space > (where SCTP belongs) makes the ubiquity step just that much harder. Please clarify this statement for me... SCTP is in kernel space for both Linux and xBSD platforms... there is a normal sockets API for SCTP. There is even a TCP "compatible" API such that we have been able to port SSH, FTP, Apache web server, and Mozilla browser by changes a hand few lines of code (in the socket() call change the IPPROTO_TCP or "0" to IPPROTO_SCTP). > I especially agree with the focus on "restrictions imposed by the > transport". > > I believe that the message set defined in the IPFIX protocol to date is > relatively transport neutral. Hence the additional overhead of specifying > the binding details to TCP and PR-SCTP seem relatively straightforward, > i.e. Diameter seemed to have no trouble here. > > So all I'd like to see is a preservation of that transport independence > and explicit bindings to TCP and PR-SCTP (in addition to the existing UDP > binding which is prevalent today). I don't see a problem with this... none of the transports being discussed places any changes/constraints on the IPFIX protocol itself. It MAY require the IPFIX application layer choice of "do I want to this reliable or unreliable" which might mean choose a different socket descriptor or change a parameter in my send call (in the case of PR-SCTP)... but these are known apriori by the application. > The conversation seems to have devolved into a "You only need SCTP and > shouldn't use anything else" which I think ignores some practical matters > in terms of rapid implementation and adoption. The question posed (and remains the topic of discussion) is "what should the default transport for IPFIX be"... I read that as "if you MUST support only ONE transport, what should it be, given that we want congestion control and both reliable and unreliable export." Diameter essentially makes SCTP the default protocol (it shoud be tried first), and TCP the "fallback". Servers are required to support both. From RFC 3588: 2.1. Transport Transport profile is defined in [AAATRANS]. The base Diameter protocol is run on port 3868 of both TCP [TCP] and SCTP [SCTP] transport protocols. Diameter clients MUST support either TCP or SCTP, while agents and servers MUST support both. Future versions of this specification MAY mandate that clients support SCTP. [snip] When connecting to a peer and either zero or more transports are specified, SCTP SHOULD be tried first, followed by TCP. See Section 5.2 for more information on peer discovery. regards, --peter > Regards, > > Jeff Meyer > > > -----Original Message----- > From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > Sent: Monday, October 13, 2003 1:30 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; > carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > Hi Jeff! > > >> By availability I mean you take the system out of the box and w/in 5 >>minutes >>of booting you are able to use the service. TCP fits this criteria. >>Perhaps >>that is also true for SCTP on IOS, I would presume given your arguments. >>However on no other platform other than Linux am I aware of this >>availability. >> >> SCTP does not come preloaded on Windows, Solaris or HP-UX, and if I go > > the > >>the >>Microsoft, Sun and HP sites looking for infomration on how to configure >>SCTP, I get >>either nothing or a reference to 3rd party (for fee) products to enable >>this. >> >> So, although in your world this may still count as "available". In the >>world of delivering multiplatform capable packaged collection SW which can >>be >>installed rapidly, it just don't cut it. > > > De-lurking again... ;-) > > I assume we're talking about collectors here, not exporters. Where do most > collectors run today? Just a wild guess, but a majority on Linux or moving > there? I could be wrong though. > > Either way, you're providing the same argumentation that you, and others, > didn't agree with regarding candidate protocols, i.e. Netflow is more > widely implemented, making IPFIX more likely to be implemented, therefore > better. I mean, I can remember a day when Microsoft didn't have their own > implementation of TCP/IP, and noone worried. I'm not advocating a "build > it and they will come" approach, but I also recognize that solutions do not > always win out based solely on technical merit. So are you wrong? Maybe > not, but as Carter suggests, it is important to ensure that the transport > is not a hindrance to any of the other requirements. So, if I had any say, > I'd recommend focusing the discussion on any interactions between any > proposed transport and other requirements, not overly worrying about what > the landscape looks like today for both implementers and end-customers, > other than perhaps architecture, which also has direct bearing on how > exporter, collector, and any intervening network will behave under stress. > > Over and out, > Robert > > -- > 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 Oct 13 19:43:28 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 TAA05592 for ; Mon, 13 Oct 2003 19:43:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9CEy-0002EA-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 18:36:40 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9CEx-0002E1-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 18:36:39 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h9DNaaEE028969 for ; Tue, 14 Oct 2003 12:36:37 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1A12D33E7A for ; Tue, 14 Oct 2003 12:34:06 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19633-17 for ; Tue, 14 Oct 2003 12:34:06 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EDD6F33E84 for ; Tue, 14 Oct 2003 12:34:05 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h9DNaa028915 for ipfix@net.doit.wisc.edu; Tue, 14 Oct 2003 12:36:36 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Tue, 14 Oct 2003 12:36:36 +1300 Message-ID: <1066088196.c49ca5a54e747@hotlava.auckland.ac.nz> Date: Tue, 14 Oct 2003 12:36:36 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] CUrrent issues, Draft deadlines References: <5C8959A16A71B449AE793CF52FBBED6607A6C4@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6C4@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 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello all: Reminder for all the IPFIX draft editors: deadline for IETF 58, the Minneapolis meeting (9-14 Nov 03) is 0900 ET on Monday 27 October. That's not very far away now, we need to focus on getting the next revisions done - which means we need to get closer to consensus on the (not very many) remaining issues. Here's my current list. It's not by any means complete (I presume the draft editors are keeping their own 'issues' lists), it's just the ones which have been prominent on the mailing list recently. I've indicated my own opinions inside brackets! Proto-1: Default transport protocol. Note that there's no question of choosing a single protocol, there never was. The issue is that we need to pick one 'mandatory-to- implement' transport, so that users will be able to talk to any IPFIX device when they plug it onto their network. At the moment (following the list discussion) it seems that TCP would be better for IPFIX collectors, since it's easily available at user level on every host. But SCTP seems to offer advantages, the most obvious being the ability to carry partially reliable data with congestion control. could we agree on TCP 'mandatory to implement,' and assume that vendors who see technical advantages in SCTP will also implement SCTP and encourage their customers to use it? IM-1: Counters vs Integers We seem to acknowledge that counters (running totals) and Integers (reset to zero when the exporter sends out data about a flow) can both be useful, so the Information Model needs to have both Counter and Integer types. My experience with RTFM is that counters have the advantage that it doesn't matter if you loose a few intermediate counts for any reason. If that happens you loose some time granularity, but you still have most, or at least some, of the packet and byte counts for the flow. I'm not sure that - at least for packet and byte counts - we need both. could we agree to only have counters? General-2: Variable-size objects There probably are a few objects which really do need variable-length encodings; they need to be identified, and the Information Model must support them. However, much of the discussion on this has centred on the need to minimise the number of bytes to carry objects, especially small integers for packet and byte counts. Almost sounds to me like an argument for ASN.1 encodings ..! I liked the suggestion that this is really an encoding issue. The objects should be defined in the Information Model with their maximum sizes (64-bit), and the Protocol document should specify how they are encoded into various numbers of bytes. That encoding could be fixed numbers of bytes (specified in the template), or a variable-length encoding. General-3: Timestamps I think we have a consensus that timestamps should be UTC-based rather than meter-uptime-based - any dissenting opinion on that? We also have consensus that microsecond precision is needed. I haven't seen any strong statements for (seconds, microseconds) vs (NTP-standard 32.32-bit fixed binary). I find NTP-standard easier to work with, but we need a WG consensus. Lets see some opinions on this, please. Those are my four 'current' IPSIF issues. Let's try to get to consensus on these in the next week or so. Also please read the drafts, and post text to the list for any sections you think need improvement. Don't just sit back and assume the draft editors will do it - after all, they need your contributed text to edit! 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 Mon Oct 13 23:11: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 XAA11257 for ; Mon, 13 Oct 2003 23:11:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9FKj-00001n-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 21:54:49 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A9FKi-00001f-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 21:54:48 -0500 Received: (qmail 37323 invoked from network); 14 Oct 2003 02:54:47 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 14 Oct 2003 02:54:47 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9E2slX31521; Mon, 13 Oct 2003 22:54:47 -0400 Reply-To: From: "Carter Bullard" To: "'Nevil Brownlee'" , Subject: RE: [ipfix] CUrrent issues, Draft deadlines Date: Mon, 13 Oct 2003 22:54:44 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6C6@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE43C@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Nevil, With regard to counters vs integers. I would suggest that the better default choice would be integers. Counters would require that originators of IPFIX always support the largest data type possible, where an integers strategy can be used by a probe to limit the size of the reported metrics. This would provide the opportunity to control the memory demands of a probe, and minimize the amount of data on the wire. Because counters have roll-over behaviors, regardless of the size of the counters you support, the counter strategy is fundamentally the same as integers, except that with counters you throw away some intermediate records and keep others. This introduces possible uncertainty. The reader is throwing away data, did it throw away the right data? I would rather like to avoid having any IPFIX component throw away data as a part of its basic function. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > Sent: Monday, October 13, 2003 6:37 PM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] CUrrent issues, Draft deadlines > > > > Hello all: > > Reminder for all the IPFIX draft editors: deadline for IETF 58, the > Minneapolis meeting (9-14 Nov 03) is 0900 ET on Monday 27 October. > That's not very far away now, we need to focus on getting the next > revisions done - which means we need to get closer to consensus on > the (not very many) remaining issues. > > Here's my current list. It's not by any means complete (I presume the > draft editors are keeping their own 'issues' lists), it's just the > ones which have been prominent on the mailing list recently. I've > indicated my own opinions inside brackets! > > Proto-1: Default transport protocol. > Note that there's no question of choosing a single protocol, there > never was. The issue is that we need to pick one 'mandatory-to- > implement' transport, so that users will be able to talk to any > IPFIX device when they plug it onto their network. > > At the moment (following the list discussion) it seems > that TCP would > be better for IPFIX collectors, since it's easily available at user > level on every host. But SCTP seems to offer advantages, the most > obvious being the ability to carry partially reliable data with > congestion control. > > could we agree on TCP 'mandatory to implement,' > and assume that vendors who see technical advantages in SCTP will > also implement SCTP and encourage their customers to use it? > > > IM-1: Counters vs Integers > We seem to acknowledge that counters (running totals) and Integers > (reset to zero when the exporter sends out data about a flow) can > both be useful, so the Information Model needs to have both Counter > and Integer types. > > My experience with RTFM is that counters have the advantage that > it doesn't matter if you loose a few intermediate counts for any > reason. If that happens you loose some time granularity, but you > still have most, or at least some, of the packet and byte counts > for the flow. > > I'm not sure that - at least for packet and byte counts - we need > both. could we agree to only have counters? > > > General-2: Variable-size objects > There probably are a few objects which really do need > variable-length > encodings; they need to be identified, and the Information Model > must support them. > > However, much of the discussion on this has centred on the need to > minimise the number of bytes to carry objects, especially small > integers for packet and byte counts. Almost sounds to me like > an argument for ASN.1 encodings ..! > > I liked the suggestion that this is really an > encoding issue. The objects should be defined in the Information > Model with their maximum sizes (64-bit), and the Protocol document > should specify how they are encoded into various numbers of bytes. > That encoding could be fixed numbers of bytes (specified in the > template), or a variable-length encoding. > > General-3: Timestamps > I think we have a consensus that timestamps should be UTC-based > rather than meter-uptime-based - any dissenting opinion on that? > > We also have consensus that microsecond precision is needed. > > I haven't seen any strong statements for (seconds, microseconds) > vs (NTP-standard 32.32-bit fixed binary). > I find NTP-standard easier to work with, but we need a WG > consensus. > Lets see some opinions on this, please. > > Those are my four 'current' IPSIF issues. Let's try to get > to consensus > on these in the next week or so. Also please read the > drafts, and post > text to the list for any sections you think need improvement. Don't > just sit back and assume the draft editors will do it - after all, > they need your contributed text to edit! > > 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/ > -- 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 Oct 14 00:10: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 AAA12421 for ; Tue, 14 Oct 2003 00:10:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9GLF-0001yw-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Oct 2003 22:59:25 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A9GLD-0001yo-00 for ipfix@net.doit.wisc.edu; Mon, 13 Oct 2003 22:59:23 -0500 Received: (qmail 52373 invoked from network); 14 Oct 2003 03:59:22 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 14 Oct 2003 03:59:22 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9E3xMX31544; Mon, 13 Oct 2003 23:59:22 -0400 Reply-To: From: "Carter Bullard" To: "'Peter Lei'" Cc: Subject: RE: [ipfix] Congestion management Date: Mon, 13 Oct 2003 23:59:19 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6C7@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE432@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Well, when you have the other Transport WG AD co-authoring a draft that uses RTP/UDP to transport SMPTE video at 1.485 Gbps with the intent that it be used over "the Big-I", and the IESG approves it in 2003 (RFC 3497), it is very difficult for me to accept the notion that the IESG has a mandatory requirement that new IP applications must use congestion friendly transport. Unless of course RTP/UDP is considered by the IESG to be congestion friendly. (I didn't think RTP was friendly, just aware, so I possibly erred when I suggested the IESG was only concerned about awareness). If an IESG mandatory requirement for congestion friendly transport actually existed and RTP/UDP wasn't a congestion friendly transport, the Transport WG AD that co-authored the draft surely would have known there was a problem, but of course if she missed the meeting, the other Transport WG AD would have reminded her, the chair of the WG and possibly the authors of the draft of the problem. Of course if somehow these mechanisms failed, the draft surely would not have been approved and promoted to Standards Track RFC by the IESG itself. Seems like a pretty big booo-booo for so many checks and balances to have failed on an IP application that runs at 1.485 GIGABITS per second minimum. Obviously, RTP/UDP is congestion friendly, but given the possibility that it is not, then I'm sure that the IESG has begun the process to retract the RFC, now that this potential violation of the IESG mandatory congestion friendly transport requirement has been identified. I don't know, maybe there isn't really a requirement. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Peter Lei > Sent: Monday, October 13, 2003 5:45 PM > To: carter@qosient.com > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Congestion management > > > > Hey Peter, > > The default transport has to have some congestion awareness, > > and given the IESG recent track record, that doesn't mean > > integrated congestion control, just awareness. There is no > > requirement that any other transport bindings must support > > congestion awareness. > > Umm.... are you sure about that?! Randy's (Bush) previous > email stated "congestion-friendly transport is mandatory to > implement and the default." In order to be "friendly" the > transport has to do something to mitigate congestion, not > just be "aware" that it's happening... > > > You still work for Cisco, right? So, maybe you can > > tell us when you guys will be able to demonstrate Netflow over > > PR-SCTP in an existing router. That really should be the > > litmus test for getting a binding in the IPFIX protocol. > > Hopefully without having to put in a specific blade to > > enable it. > > > > Carter > > > > > > > > > > -- > > 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 Tue Oct 14 12:17:55 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 MAA17723 for ; Tue, 14 Oct 2003 12:17:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9RMH-0000jE-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Oct 2003 10:45:13 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9RMG-0000j9-00 for ipfix@net.doit.wisc.edu; Tue, 14 Oct 2003 10:45:12 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id 5CC451C026D8; Tue, 14 Oct 2003 11:45:11 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 5639C1C000B7; Tue, 14 Oct 2003 11:45:11 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4V7MG2T4>; Tue, 14 Oct 2003 11:45:11 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A5029603A7@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'carter@qosient.com'" , "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] CUrrent issues, Draft deadlines Date: Tue, 14 Oct 2003 11:45:07 -0400 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 would second Carter's opinion on counters v. integers for the basic IPFIX export information elements. A few other points are that: a. The current behavior of NFvX is to use integers not counters. b. Since information is being exported and not polled, counters provide less benefit. Especially when most flows are exported exactly once. c. There needs to be some strategy on the collector to do delta calculations with flows. Since the number of unique flow records would be huge, searching for previous flows to do the delta can be costly. One alternative to address c. with counters would be to have explicit indications of whether a flow record is the "last" one. If it is last, then it does not need to be preserved for subsequent delta calculations. But this alternative sounds a little clunky to me. Regards, Jeff Meyer > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: Monday, October 13, 2003 7:55 PM > To: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] CUrrent issues, Draft deadlines > > > Hey Nevil, > With regard to counters vs integers. I would suggest that > the better default choice would be integers. Counters > would require that originators of IPFIX always support the > largest data type possible, where an integers strategy can > be used by a probe to limit the size of the reported metrics. > This would provide the opportunity to control the > memory demands of a probe, and minimize the amount of > data on the wire. > > Because counters have roll-over behaviors, regardless > of the size of the counters you support, the counter strategy > is fundamentally the same as integers, except that with > counters you throw away some intermediate records and keep > others. This introduces possible uncertainty. The reader is > throwing away data, did it throw away the right data? I > would rather like to avoid having any IPFIX component > throw away data as a part of its basic function. > > Carter > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > > Sent: Monday, October 13, 2003 6:37 PM > > To: ipfix@net.doit.wisc.edu > > Subject: [ipfix] CUrrent issues, Draft deadlines > > > > > > > > Hello all: > > > > Reminder for all the IPFIX draft editors: deadline for IETF 58, the > > Minneapolis meeting (9-14 Nov 03) is 0900 ET on Monday 27 October. > > That's not very far away now, we need to focus on getting the next > > revisions done - which means we need to get closer to consensus on > > the (not very many) remaining issues. > > > > Here's my current list. It's not by any means complete (I > presume the > > draft editors are keeping their own 'issues' lists), it's just the > > ones which have been prominent on the mailing list recently. I've > > indicated my own opinions inside brackets! > > > > Proto-1: Default transport protocol. > > Note that there's no question of choosing a single > protocol, there > > never was. The issue is that we need to pick one 'mandatory-to- > > implement' transport, so that users will be able to talk to any > > IPFIX device when they plug it onto their network. > > > > At the moment (following the list discussion) it seems > > that TCP would > > be better for IPFIX collectors, since it's easily > available at user > > level on every host. But SCTP seems to offer > advantages, the most > > obvious being the ability to carry partially reliable data with > > congestion control. > > > > could we agree on TCP 'mandatory to > implement,' > > and assume that vendors who see technical advantages in SCTP will > > also implement SCTP and encourage their customers to use it? > > > > > > IM-1: Counters vs Integers > > We seem to acknowledge that counters (running totals) > and Integers > > (reset to zero when the exporter sends out data about a flow) can > > both be useful, so the Information Model needs to have > both Counter > > and Integer types. > > > > My experience with RTFM is that counters have the advantage that > > it doesn't matter if you loose a few intermediate counts for any > > reason. If that happens you loose some time granularity, but you > > still have most, or at least some, of the packet and byte counts > > for the flow. > > > > I'm not sure that - at least for packet and byte counts - we need > > both. could we agree to only have counters? > > > > > > General-2: Variable-size objects > > There probably are a few objects which really do need > > variable-length > > encodings; they need to be identified, and the Information Model > > must support them. > > > > However, much of the discussion on this has centred on > the need to > > minimise the number of bytes to carry objects, especially small > > integers for packet and byte counts. Almost sounds to me like > > an argument for ASN.1 encodings ..! > > > > I liked the suggestion that this is really an > > encoding issue. The objects should be defined in the Information > > Model with their maximum sizes (64-bit), and the > Protocol document > > should specify how they are encoded into various numbers > of bytes. > > That encoding could be fixed numbers of bytes (specified in the > > template), or a variable-length encoding. > > > > General-3: Timestamps > > I think we have a consensus that timestamps should be UTC-based > > rather than meter-uptime-based - any dissenting opinion on that? > > > > We also have consensus that microsecond precision is needed. > > > > I haven't seen any strong statements for (seconds, microseconds) > > vs (NTP-standard 32.32-bit fixed binary). > > I find NTP-standard easier to work with, but we need a WG > > consensus. > > Lets see some opinions on this, please. > > > > Those are my four 'current' IPSIF issues. Let's try to get > > to consensus > > on these in the next week or so. Also please read the > > drafts, and post > > text to the list for any sections you think need improvement. Don't > > just sit back and assume the draft editors will do it - after all, > > they need your contributed text to edit! > > > > 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/ > > > > > > > -- > 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 Tue Oct 14 13:06: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 NAA19407 for ; Tue, 14 Oct 2003 13:06:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9SJk-0002V3-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Oct 2003 11:46:40 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9SJj-0002Ux-00 for ipfix@net.doit.wisc.edu; Tue, 14 Oct 2003 11:46:39 -0500 Received: from fokus.fraunhofer.de (dhcp166 [195.37.78.166]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h9EGkTD17461; Tue, 14 Oct 2003 18:46:29 +0200 (MEST) Message-ID: <3F8C2830.7010507@fokus.fraunhofer.de> Date: Tue, 14 Oct 2003 18:45:36 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'Peter Lei'" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Congestion management References: <5C8959A16A71B449AE793CF52FBBED6607A6C7@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter, fact is that some media formats are inelastic and are therefore basically unusable with congestion control. IMO IPFIX is still very useful / can be used with congestion control. I agree with you that in some cases UDP may be nice etc. etc. etc. However you have raised an interesting point. Reading RFC 3550 and remembering the IPFIX transport protocol discussion last year all I can say right now is :-) Quoting section 10, p. 67, RFC 3550 (RTP): "Therefore, congestion control SHOULD be defined in each RTP profile as appropriate. For some profiles, it may be sufficient to include an applicability statement restricting the use of that profile to environments where congestion is avoided by engineering. For other profiles, specific methods such as data rate adaptation based on RTCP feedback may be required." Cheers, Sebastian Carter Bullard wrote: > Well, when you have the other Transport WG AD co-authoring > a draft that uses RTP/UDP to transport SMPTE video > at 1.485 Gbps with the intent that it be used over > "the Big-I", and the IESG approves it in 2003 (RFC 3497), > it is very difficult for me to accept the notion that > the IESG has a mandatory requirement that new IP > applications must use congestion friendly transport. > Unless of course RTP/UDP is considered by the IESG to > be congestion friendly. (I didn't think RTP was friendly, > just aware, so I possibly erred when I suggested the > IESG was only concerned about awareness). > > If an IESG mandatory requirement for congestion friendly > transport actually existed and RTP/UDP wasn't a congestion > friendly transport, the Transport WG AD that co-authored > the draft surely would have known there was a problem, but > of course if she missed the meeting, the other Transport > WG AD would have reminded her, the chair of the WG and > possibly the authors of the draft of the problem. Of > course if somehow these mechanisms failed, the draft > surely would not have been approved and promoted to Standards > Track RFC by the IESG itself. Seems like a pretty big > booo-booo for so many checks and balances to have failed on > an IP application that runs at > > 1.485 GIGABITS per second > > minimum. Obviously, RTP/UDP is congestion friendly, but > given the possibility that it is not, then I'm sure that > the IESG has begun the process to retract the RFC, now > that this potential violation of the IESG mandatory > congestion friendly transport requirement has been > identified. > > I don't know, maybe there isn't really a requirement. > > Carter > > > >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Peter Lei >>Sent: Monday, October 13, 2003 5:45 PM >>To: carter@qosient.com >>Cc: ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] Congestion management >> >> >> >>>Hey Peter, >>> The default transport has to have some congestion awareness, >>>and given the IESG recent track record, that doesn't mean >>>integrated congestion control, just awareness. There is no >>>requirement that any other transport bindings must support >>>congestion awareness. >> >>Umm.... are you sure about that?! Randy's (Bush) previous >>email stated "congestion-friendly transport is mandatory to >>implement and the default." In order to be "friendly" the >>transport has to do something to mitigate congestion, not >>just be "aware" that it's happening... >> >> >>> You still work for Cisco, right? So, maybe you can >>>tell us when you guys will be able to demonstrate Netflow over >>>PR-SCTP in an existing router. That really should be the >>>litmus test for getting a binding in the IPFIX protocol. >>>Hopefully without having to put in a specific blade to >>>enable it. >> >> > >> >>>Carter >>> >>> >>> >>> >>>-- >>>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/ > -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.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 Tue Oct 14 17:39:23 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 RAA03869 for ; Tue, 14 Oct 2003 17:39:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9Wk2-00037i-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Oct 2003 16:30:06 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9Wjt-00036k-00; Tue, 14 Oct 2003 16:29:57 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h9ELTOXU022265; Tue, 14 Oct 2003 16:29:25 -0500 (CDT) Message-ID: <3F8C6AB2.E4F17784@alcatel.com> Date: Tue, 14 Oct 2003 16:29:22 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Lei CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A5029603A1@xsun01.ptp.hp.com> <3F8B257E.6040104@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit As far as I know, I don't know of any thing specifically that specifies that any transport protocol must be in USER or KERNEL space. Based on what features are important to you, you could deploy SCTP in kernel space for speed and efficiency, or in user space for flexibility, kernel safety, and ease of coexistence with other protocols. TCP has been deployed both in user and kernel spaces and our in-house SCTP was deployed in user space. Regards Alex. Peter Lei wrote: > > Robert, > > > > I agree with your points, with the one caveat that user vs. kernel space > > (where SCTP belongs) makes the ubiquity step just that much harder. > > Please clarify this statement for me... SCTP is in kernel space for both > Linux and xBSD platforms... there is a normal sockets API for SCTP. There > is even a TCP "compatible" API such that we have been able to port SSH, > FTP, Apache web server, and Mozilla browser by changes a hand few lines of > code (in the socket() call change the IPPROTO_TCP or "0" to IPPROTO_SCTP). > > > I especially agree with the focus on "restrictions imposed by the > > transport". > > > > I believe that the message set defined in the IPFIX protocol to date is > > relatively transport neutral. Hence the additional overhead of specifying > > the binding details to TCP and PR-SCTP seem relatively straightforward, > > i.e. Diameter seemed to have no trouble here. > > > > So all I'd like to see is a preservation of that transport independence > > and explicit bindings to TCP and PR-SCTP (in addition to the existing UDP > > binding which is prevalent today). > > I don't see a problem with this... none of the transports being discussed > places any changes/constraints on the IPFIX protocol itself. It MAY > require the IPFIX application layer choice of "do I want to this reliable > or unreliable" which might mean choose a different socket descriptor or > change a parameter in my send call (in the case of PR-SCTP)... but these > are known apriori by the application. > > > The conversation seems to have devolved into a "You only need SCTP and > > shouldn't use anything else" which I think ignores some practical matters > > in terms of rapid implementation and adoption. > > The question posed (and remains the topic of discussion) is "what should > the default transport for IPFIX be"... I read that as "if you MUST > support only ONE transport, what should it be, given that we want > congestion control and both reliable and unreliable export." > > Diameter essentially makes SCTP the default protocol (it shoud be > tried first), and TCP the "fallback". Servers are required to support > both. > > From RFC 3588: > > 2.1. Transport > > Transport profile is defined in [AAATRANS]. > > The base Diameter protocol is run on port 3868 of both TCP [TCP] and > SCTP [SCTP] transport protocols. > > Diameter clients MUST support either TCP or SCTP, while agents and > servers MUST support both. Future versions of this specification MAY > mandate that clients support SCTP. > > [snip] > > When connecting to a peer and either zero or more transports are > specified, SCTP SHOULD be tried first, followed by TCP. See Section > 5.2 for more information on peer discovery. > > regards, > --peter > > > Regards, > > > > Jeff Meyer > > > > > > -----Original Message----- > > From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > > Sent: Monday, October 13, 2003 1:30 PM > > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; > > carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > > > Hi Jeff! > > > > > >> By availability I mean you take the system out of the box and w/in 5 > >>minutes > >>of booting you are able to use the service. TCP fits this criteria. > >>Perhaps > >>that is also true for SCTP on IOS, I would presume given your arguments. > >>However on no other platform other than Linux am I aware of this > >>availability. > >> > >> SCTP does not come preloaded on Windows, Solaris or HP-UX, and if I go > > > > the > > > >>the > >>Microsoft, Sun and HP sites looking for infomration on how to configure > >>SCTP, I get > >>either nothing or a reference to 3rd party (for fee) products to enable > >>this. > >> > >> So, although in your world this may still count as "available". In the > >>world of delivering multiplatform capable packaged collection SW which can > >>be > >>installed rapidly, it just don't cut it. > > > > > > De-lurking again... ;-) > > > > I assume we're talking about collectors here, not exporters. Where do most > > collectors run today? Just a wild guess, but a majority on Linux or moving > > there? I could be wrong though. > > > > Either way, you're providing the same argumentation that you, and others, > > didn't agree with regarding candidate protocols, i.e. Netflow is more > > widely implemented, making IPFIX more likely to be implemented, therefore > > better. I mean, I can remember a day when Microsoft didn't have their own > > implementation of TCP/IP, and noone worried. I'm not advocating a "build > > it and they will come" approach, but I also recognize that solutions do not > > always win out based solely on technical merit. So are you wrong? Maybe > > not, but as Carter suggests, it is important to ensure that the transport > > is not a hindrance to any of the other requirements. So, if I had any say, > > I'd recommend focusing the discussion on any interactions between any > > proposed transport and other requirements, not overly worrying about what > > the landscape looks like today for both implementers and end-customers, > > other than perhaps architecture, which also has direct bearing on how > > exporter, collector, and any intervening network will behave under stress. > > > > Over and out, > > Robert > > > > -- > > 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 Tue Oct 14 18:20: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 SAA07233 for ; Tue, 14 Oct 2003 18:20:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9XQ7-0004Rq-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Oct 2003 17:13:35 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9XQ6-0004Rg-00; Tue, 14 Oct 2003 17:13:34 -0500 Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by comcast.net (rwcrmhc11) with SMTP id <20031014221331013000p51je>; Tue, 14 Oct 2003 22:13:32 +0000 Message-ID: <3F8C74DA.6060502@ieee.org> Date: Tue, 14 Oct 2003 17:12:42 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A5029603A1@xsun01.ptp.hp.com> <3F8B257E.6040104@ieee.org> <3F8C6AB2.E4F17784@alcatel.com> In-Reply-To: <3F8C6AB2.E4F17784@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Alex Audu wrote: > As far as I know, I don't know of any thing specifically that specifies that > any transport protocol must be in USER or KERNEL space. Based on > what features are important to you, you could deploy SCTP in kernel space > for speed and efficiency, or in user space for flexibility, kernel safety, and > ease of coexistence with other protocols. Exactly... I guess my original comment/question was why was having SCTP in kernel "(where SCTP belongs)" was a "problem"... that SCTP in kernel space places no issues on "ubiquity". Perhaps the original reference was that for his particular situation (and yours too it seems) is that SCTP was only available in user space. --peter > TCP has been deployed both in user and kernel spaces and our in-house > SCTP was deployed in user space. > > Regards > Alex. > > Peter Lei wrote: > > >>>Robert, >>> >>> I agree with your points, with the one caveat that user vs. kernel space >>>(where SCTP belongs) makes the ubiquity step just that much harder. >> >>Please clarify this statement for me... SCTP is in kernel space for both >>Linux and xBSD platforms... there is a normal sockets API for SCTP. There >>is even a TCP "compatible" API such that we have been able to port SSH, >>FTP, Apache web server, and Mozilla browser by changes a hand few lines of >>code (in the socket() call change the IPPROTO_TCP or "0" to IPPROTO_SCTP). >> >> >>> I especially agree with the focus on "restrictions imposed by the >>>transport". >>> >>> I believe that the message set defined in the IPFIX protocol to date is >>>relatively transport neutral. Hence the additional overhead of specifying >>>the binding details to TCP and PR-SCTP seem relatively straightforward, >>>i.e. Diameter seemed to have no trouble here. >>> >>> So all I'd like to see is a preservation of that transport independence >>>and explicit bindings to TCP and PR-SCTP (in addition to the existing UDP >>>binding which is prevalent today). >> >>I don't see a problem with this... none of the transports being discussed >>places any changes/constraints on the IPFIX protocol itself. It MAY >>require the IPFIX application layer choice of "do I want to this reliable >>or unreliable" which might mean choose a different socket descriptor or >>change a parameter in my send call (in the case of PR-SCTP)... but these >>are known apriori by the application. >> >> >>> The conversation seems to have devolved into a "You only need SCTP and >>>shouldn't use anything else" which I think ignores some practical matters >>>in terms of rapid implementation and adoption. >> >>The question posed (and remains the topic of discussion) is "what should >>the default transport for IPFIX be"... I read that as "if you MUST >>support only ONE transport, what should it be, given that we want >>congestion control and both reliable and unreliable export." >> >>Diameter essentially makes SCTP the default protocol (it shoud be >>tried first), and TCP the "fallback". Servers are required to support >>both. >> >> From RFC 3588: >> >>2.1. Transport >> >> Transport profile is defined in [AAATRANS]. >> >> The base Diameter protocol is run on port 3868 of both TCP [TCP] and >> SCTP [SCTP] transport protocols. >> >> Diameter clients MUST support either TCP or SCTP, while agents and >> servers MUST support both. Future versions of this specification MAY >> mandate that clients support SCTP. >> >> [snip] >> >> When connecting to a peer and either zero or more transports are >> specified, SCTP SHOULD be tried first, followed by TCP. See Section >> 5.2 for more information on peer discovery. >> >>regards, >>--peter >> >> >>>Regards, >>> >>> Jeff Meyer >>> >>> >>>-----Original Message----- >>>From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] >>>Sent: Monday, October 13, 2003 1:30 PM >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) >>>Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; >>>carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; >>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] STCP as a default transport not >>> >>> >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: >>> >>>Hi Jeff! >>> >>> >>> >>>> By availability I mean you take the system out of the box and w/in 5 >>>>minutes >>>>of booting you are able to use the service. TCP fits this criteria. >>>>Perhaps >>>>that is also true for SCTP on IOS, I would presume given your arguments. >>>>However on no other platform other than Linux am I aware of this >>>>availability. >>>> >>>> SCTP does not come preloaded on Windows, Solaris or HP-UX, and if I go >>> >>>the >>> >>> >>>>the >>>>Microsoft, Sun and HP sites looking for infomration on how to configure >>>>SCTP, I get >>>>either nothing or a reference to 3rd party (for fee) products to enable >>>>this. >>>> >>>> So, although in your world this may still count as "available". In the >>>>world of delivering multiplatform capable packaged collection SW which can >>>>be >>>>installed rapidly, it just don't cut it. >>> >>> >>>De-lurking again... ;-) >>> >>>I assume we're talking about collectors here, not exporters. Where do most >>>collectors run today? Just a wild guess, but a majority on Linux or moving >>>there? I could be wrong though. >>> >>>Either way, you're providing the same argumentation that you, and others, >>>didn't agree with regarding candidate protocols, i.e. Netflow is more >>>widely implemented, making IPFIX more likely to be implemented, therefore >>>better. I mean, I can remember a day when Microsoft didn't have their own >>>implementation of TCP/IP, and noone worried. I'm not advocating a "build >>>it and they will come" approach, but I also recognize that solutions do not >>>always win out based solely on technical merit. So are you wrong? Maybe >>>not, but as Carter suggests, it is important to ensure that the transport >>>is not a hindrance to any of the other requirements. So, if I had any say, >>>I'd recommend focusing the discussion on any interactions between any >>>proposed transport and other requirements, not overly worrying about what >>>the landscape looks like today for both implementers and end-customers, >>>other than perhaps architecture, which also has direct bearing on how >>>exporter, collector, and any intervening network will behave under stress. >>> >>>Over and out, >>>Robert >>> >>>-- >>>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 Tue Oct 14 21:55:17 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 VAA13233 for ; Tue, 14 Oct 2003 21:55:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9aZG-0002bn-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Oct 2003 20:35:14 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9aZE-0002bb-00; Tue, 14 Oct 2003 20:35:12 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id D330F1C03672; Tue, 14 Oct 2003 21:35:11 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id C88E41C00097; Tue, 14 Oct 2003 21:35:11 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4V7MJM19>; Tue, 14 Oct 2003 21:35:11 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Peter Lei'" , alex.audu@alcatel.com Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Tue, 14 Oct 2003 21:35:06 -0400 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 tried to articulate my reasoning why SCTP may prove to be a barrier for implementors of IPFIX in non-Linux based collectors in the e-mail: http://ipfix.doit.wisc.edu/archive/2044.html The statement, "well, we have an implementation", doesn't mean that other interested parties will have the time/patience to acquire or develop one themselves. In fairness I will note that there is one open source user space implementation that I could find at: http://www.sctp.de/sctp-download.html Links to Linux and FreeBSD kernel implementations are available off of: http://sigtran.org/ and http://www.sctp.org/ Nonetheless, the time and testing effort to get a multiplatform Java based collection engine running on TCP vs. SCTP is significant. Consider the project plan for each activity and tell me there's no barrier associated w/ SCTP. Regards, Jeff Meyer > -----Original Message----- > From: Peter Lei [mailto:peter.lei@ieee.org] > Sent: Tuesday, October 14, 2003 3:13 PM > To: alex.audu@alcatel.com > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Robert Lowe'; > 'Randall Stewart > (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; carter@qosient.com; > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > Alex Audu wrote: > > As far as I know, I don't know of any thing specifically > that specifies that > > any transport protocol must be in USER or KERNEL space. Based on > > what features are important to you, you could deploy SCTP > in kernel space > > for speed and efficiency, or in user space for > flexibility, kernel safety, and > > ease of coexistence with other protocols. > > Exactly... I guess my original comment/question was why was having > SCTP in kernel "(where SCTP belongs)" was a "problem"... that SCTP > in kernel space places no issues on "ubiquity". > > Perhaps the original reference was that for his particular situation > (and yours too it seems) is that SCTP was only available in > user space. > > --peter > > > TCP has been deployed both in user and kernel spaces and > our in-house > > SCTP was deployed in user space. > > > > Regards > > Alex. > > > > Peter Lei wrote: > > > > > >>>Robert, > >>> > >>> I agree with your points, with the one caveat that user > vs. kernel space > >>>(where SCTP belongs) makes the ubiquity step just that much harder. > >> > >>Please clarify this statement for me... SCTP is in kernel > space for both > >>Linux and xBSD platforms... there is a normal sockets API > for SCTP. There > >>is even a TCP "compatible" API such that we have been able > to port SSH, > >>FTP, Apache web server, and Mozilla browser by changes a > hand few lines of > >>code (in the socket() call change the IPPROTO_TCP or "0" to > IPPROTO_SCTP). > >> > >> > >>> I especially agree with the focus on "restrictions imposed by the > >>>transport". > >>> > >>> I believe that the message set defined in the IPFIX > protocol to date is > >>>relatively transport neutral. Hence the additional > overhead of specifying > >>>the binding details to TCP and PR-SCTP seem relatively > straightforward, > >>>i.e. Diameter seemed to have no trouble here. > >>> > >>> So all I'd like to see is a preservation of that > transport independence > >>>and explicit bindings to TCP and PR-SCTP (in addition to > the existing UDP > >>>binding which is prevalent today). > >> > >>I don't see a problem with this... none of the transports > being discussed > >>places any changes/constraints on the IPFIX protocol itself. It MAY > >>require the IPFIX application layer choice of "do I want to > this reliable > >>or unreliable" which might mean choose a different socket > descriptor or > >>change a parameter in my send call (in the case of > PR-SCTP)... but these > >>are known apriori by the application. > >> > >> > >>> The conversation seems to have devolved into a "You only > need SCTP and > >>>shouldn't use anything else" which I think ignores some > practical matters > >>>in terms of rapid implementation and adoption. > >> > >>The question posed (and remains the topic of discussion) is > "what should > >>the default transport for IPFIX be"... I read that as "if you MUST > >>support only ONE transport, what should it be, given that we want > >>congestion control and both reliable and unreliable export." > >> > >>Diameter essentially makes SCTP the default protocol (it shoud be > >>tried first), and TCP the "fallback". Servers are required > to support > >>both. > >> > >> From RFC 3588: > >> > >>2.1. Transport > >> > >> Transport profile is defined in [AAATRANS]. > >> > >> The base Diameter protocol is run on port 3868 of both > TCP [TCP] and > >> SCTP [SCTP] transport protocols. > >> > >> Diameter clients MUST support either TCP or SCTP, while > agents and > >> servers MUST support both. Future versions of this > specification MAY > >> mandate that clients support SCTP. > >> > >> [snip] > >> > >> When connecting to a peer and either zero or more transports are > >> specified, SCTP SHOULD be tried first, followed by TCP. > See Section > >> 5.2 for more information on peer discovery. > >> > >>regards, > >>--peter > >> > >> > >>>Regards, > >>> > >>> Jeff Meyer > >>> > >>> > >>>-----Original Message----- > >>>From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > >>>Sent: Monday, October 13, 2003 1:30 PM > >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) > >>>Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; > 'stbryant@cisco.com'; > >>>carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > >>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > >>>Subject: Re: [ipfix] STCP as a default transport not > >>> > >>> > >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > >>> > >>>Hi Jeff! > >>> > >>> > >>> > >>>> By availability I mean you take the system out of the > box and w/in 5 > >>>>minutes > >>>>of booting you are able to use the service. TCP fits > this criteria. > >>>>Perhaps > >>>>that is also true for SCTP on IOS, I would presume given > your arguments. > >>>>However on no other platform other than Linux am I aware of this > >>>>availability. > >>>> > >>>> SCTP does not come preloaded on Windows, Solaris or > HP-UX, and if I go > >>> > >>>the > >>> > >>> > >>>>the > >>>>Microsoft, Sun and HP sites looking for infomration on > how to configure > >>>>SCTP, I get > >>>>either nothing or a reference to 3rd party (for fee) > products to enable > >>>>this. > >>>> > >>>> So, although in your world this may still count as > "available". In the > >>>>world of delivering multiplatform capable packaged > collection SW which can > >>>>be > >>>>installed rapidly, it just don't cut it. > >>> > >>> > >>>De-lurking again... ;-) > >>> > >>>I assume we're talking about collectors here, not > exporters. Where do most > >>>collectors run today? Just a wild guess, but a majority > on Linux or moving > >>>there? I could be wrong though. > >>> > >>>Either way, you're providing the same argumentation that > you, and others, > >>>didn't agree with regarding candidate protocols, i.e. > Netflow is more > >>>widely implemented, making IPFIX more likely to be > implemented, therefore > >>>better. I mean, I can remember a day when Microsoft > didn't have their own > >>>implementation of TCP/IP, and noone worried. I'm not > advocating a "build > >>>it and they will come" approach, but I also recognize that > solutions do not > >>>always win out based solely on technical merit. So are > you wrong? Maybe > >>>not, but as Carter suggests, it is important to ensure > that the transport > >>>is not a hindrance to any of the other requirements. So, > if I had any say, > >>>I'd recommend focusing the discussion on any interactions > between any > >>>proposed transport and other requirements, not overly > worrying about what > >>>the landscape looks like today for both implementers and > end-customers, > >>>other than perhaps architecture, which also has direct > bearing on how > >>>exporter, collector, and any intervening network will > behave under stress. > >>> > >>>Over and out, > >>>Robert > >>> > >>>-- > >>>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 Tue Oct 14 22:29: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 WAA14205 for ; Tue, 14 Oct 2003 22:29:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9bFa-0003kb-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Oct 2003 21:18:58 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9bFZ-0003kS-00 for ipfix@net.doit.wisc.edu; Tue, 14 Oct 2003 21:18:57 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h9F2IkEE015092; Wed, 15 Oct 2003 15:18:47 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2ACD433EA2; Wed, 15 Oct 2003 15:15:55 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02596-04; Wed, 15 Oct 2003 15:15:55 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0A30933E9A; Wed, 15 Oct 2003 15:15:55 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h9F2Ikn06370; Wed, 15 Oct 2003 15:18:46 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Wed, 15 Oct 2003 15:18:45 +1300 Message-ID: <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> Date: Wed, 15 Oct 2003 15:18:45 +1300 From: Nevil Brownlee To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" Subject: RE: [ipfix] default transport !!! References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.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 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: In an attempt to move the 'default transport' discussion forward a little, can I have some feedback on my suggestion a day or two back, i.e. how about this .. TCP mandatory to implement = easy to make collectors SCTP optional = equipment / flow collector developers can demonstrate advantages for users of IPFIX over SCTP I suggested this because it seems to me that lots of people may develop IPFIX collectors, wheras not too many will be developing exporters. 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 Oct 15 10:51: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 KAA03021 for ; Wed, 15 Oct 2003 10:51:44 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9meK-0003BX-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Oct 2003 09:29:16 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9meI-0003BQ-00; Wed, 15 Oct 2003 09:29:15 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h9FEShYD001080; Wed, 15 Oct 2003 09:28:43 -0500 (CDT) Message-ID: <3F8D5995.40FA7A01@alcatel.com> Date: Wed, 15 Oct 2003 09:28:38 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Peter Lei'" , "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jeffery, I guess my point is I detect something that looks like a tendency to miss-inform so as to make a point. If we are going to chose a protocol to do a job, we chose it based soley on its technical merits. Arguments like "Oh, SCTP is kernel space transport" is just not accurate. That prompted my response about my personal experience in implementing SCTP in user space. And I don't see anything in the SCTP specs that says it must be in kernel space. The bottom line is SCTP is a better transport than TCP. Heck, it was designed to correct issues with TCP in the first place. If members of the technical community don't reccomend it for deployment (because it is not widely available), how is it ever going to be widely available? Regards, Alex. "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > Hi, > > I tried to articulate my reasoning why SCTP may prove to be a > barrier for implementors of IPFIX in non-Linux based collectors > in the e-mail: > > http://ipfix.doit.wisc.edu/archive/2044.html > > The statement, "well, we have an implementation", doesn't mean > that other interested parties will have the time/patience to > acquire or develop one themselves. > > In fairness I will note that there is one open source user > space implementation that I could find at: > > http://www.sctp.de/sctp-download.html > > Links to Linux and FreeBSD kernel implementations are available > off of: > > http://sigtran.org/ and http://www.sctp.org/ > > Nonetheless, the time and testing effort to get a multiplatform > Java based collection engine running on TCP vs. SCTP is significant. > Consider the project plan for each activity and tell me there's no > barrier associated w/ SCTP. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Peter Lei [mailto:peter.lei@ieee.org] > > Sent: Tuesday, October 14, 2003 3:13 PM > > To: alex.audu@alcatel.com > > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Robert Lowe'; > > 'Randall Stewart > > (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; carter@qosient.com; > > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > > ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Alex Audu wrote: > > > As far as I know, I don't know of any thing specifically > > that specifies that > > > any transport protocol must be in USER or KERNEL space. Based on > > > what features are important to you, you could deploy SCTP > > in kernel space > > > for speed and efficiency, or in user space for > > flexibility, kernel safety, and > > > ease of coexistence with other protocols. > > > > Exactly... I guess my original comment/question was why was having > > SCTP in kernel "(where SCTP belongs)" was a "problem"... that SCTP > > in kernel space places no issues on "ubiquity". > > > > Perhaps the original reference was that for his particular situation > > (and yours too it seems) is that SCTP was only available in > > user space. > > > > --peter > > > > > TCP has been deployed both in user and kernel spaces and > > our in-house > > > SCTP was deployed in user space. > > > > > > Regards > > > Alex. > > > > > > Peter Lei wrote: > > > > > > > > >>>Robert, > > >>> > > >>> I agree with your points, with the one caveat that user > > vs. kernel space > > >>>(where SCTP belongs) makes the ubiquity step just that much harder. > > >> > > >>Please clarify this statement for me... SCTP is in kernel > > space for both > > >>Linux and xBSD platforms... there is a normal sockets API > > for SCTP. There > > >>is even a TCP "compatible" API such that we have been able > > to port SSH, > > >>FTP, Apache web server, and Mozilla browser by changes a > > hand few lines of > > >>code (in the socket() call change the IPPROTO_TCP or "0" to > > IPPROTO_SCTP). > > >> > > >> > > >>> I especially agree with the focus on "restrictions imposed by the > > >>>transport". > > >>> > > >>> I believe that the message set defined in the IPFIX > > protocol to date is > > >>>relatively transport neutral. Hence the additional > > overhead of specifying > > >>>the binding details to TCP and PR-SCTP seem relatively > > straightforward, > > >>>i.e. Diameter seemed to have no trouble here. > > >>> > > >>> So all I'd like to see is a preservation of that > > transport independence > > >>>and explicit bindings to TCP and PR-SCTP (in addition to > > the existing UDP > > >>>binding which is prevalent today). > > >> > > >>I don't see a problem with this... none of the transports > > being discussed > > >>places any changes/constraints on the IPFIX protocol itself. It MAY > > >>require the IPFIX application layer choice of "do I want to > > this reliable > > >>or unreliable" which might mean choose a different socket > > descriptor or > > >>change a parameter in my send call (in the case of > > PR-SCTP)... but these > > >>are known apriori by the application. > > >> > > >> > > >>> The conversation seems to have devolved into a "You only > > need SCTP and > > >>>shouldn't use anything else" which I think ignores some > > practical matters > > >>>in terms of rapid implementation and adoption. > > >> > > >>The question posed (and remains the topic of discussion) is > > "what should > > >>the default transport for IPFIX be"... I read that as "if you MUST > > >>support only ONE transport, what should it be, given that we want > > >>congestion control and both reliable and unreliable export." > > >> > > >>Diameter essentially makes SCTP the default protocol (it shoud be > > >>tried first), and TCP the "fallback". Servers are required > > to support > > >>both. > > >> > > >> From RFC 3588: > > >> > > >>2.1. Transport > > >> > > >> Transport profile is defined in [AAATRANS]. > > >> > > >> The base Diameter protocol is run on port 3868 of both > > TCP [TCP] and > > >> SCTP [SCTP] transport protocols. > > >> > > >> Diameter clients MUST support either TCP or SCTP, while > > agents and > > >> servers MUST support both. Future versions of this > > specification MAY > > >> mandate that clients support SCTP. > > >> > > >> [snip] > > >> > > >> When connecting to a peer and either zero or more transports are > > >> specified, SCTP SHOULD be tried first, followed by TCP. > > See Section > > >> 5.2 for more information on peer discovery. > > >> > > >>regards, > > >>--peter > > >> > > >> > > >>>Regards, > > >>> > > >>> Jeff Meyer > > >>> > > >>> > > >>>-----Original Message----- > > >>>From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > > >>>Sent: Monday, October 13, 2003 1:30 PM > > >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > >>>Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; > > 'stbryant@cisco.com'; > > >>>carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > > >>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > >>>Subject: Re: [ipfix] STCP as a default transport not > > >>> > > >>> > > >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > >>> > > >>>Hi Jeff! > > >>> > > >>> > > >>> > > >>>> By availability I mean you take the system out of the > > box and w/in 5 > > >>>>minutes > > >>>>of booting you are able to use the service. TCP fits > > this criteria. > > >>>>Perhaps > > >>>>that is also true for SCTP on IOS, I would presume given > > your arguments. > > >>>>However on no other platform other than Linux am I aware of this > > >>>>availability. > > >>>> > > >>>> SCTP does not come preloaded on Windows, Solaris or > > HP-UX, and if I go > > >>> > > >>>the > > >>> > > >>> > > >>>>the > > >>>>Microsoft, Sun and HP sites looking for infomration on > > how to configure > > >>>>SCTP, I get > > >>>>either nothing or a reference to 3rd party (for fee) > > products to enable > > >>>>this. > > >>>> > > >>>> So, although in your world this may still count as > > "available". In the > > >>>>world of delivering multiplatform capable packaged > > collection SW which can > > >>>>be > > >>>>installed rapidly, it just don't cut it. > > >>> > > >>> > > >>>De-lurking again... ;-) > > >>> > > >>>I assume we're talking about collectors here, not > > exporters. Where do most > > >>>collectors run today? Just a wild guess, but a majority > > on Linux or moving > > >>>there? I could be wrong though. > > >>> > > >>>Either way, you're providing the same argumentation that > > you, and others, > > >>>didn't agree with regarding candidate protocols, i.e. > > Netflow is more > > >>>widely implemented, making IPFIX more likely to be > > implemented, therefore > > >>>better. I mean, I can remember a day when Microsoft > > didn't have their own > > >>>implementation of TCP/IP, and noone worried. I'm not > > advocating a "build > > >>>it and they will come" approach, but I also recognize that > > solutions do not > > >>>always win out based solely on technical merit. So are > > you wrong? Maybe > > >>>not, but as Carter suggests, it is important to ensure > > that the transport > > >>>is not a hindrance to any of the other requirements. So, > > if I had any say, > > >>>I'd recommend focusing the discussion on any interactions > > between any > > >>>proposed transport and other requirements, not overly > > worrying about what > > >>>the landscape looks like today for both implementers and > > end-customers, > > >>>other than perhaps architecture, which also has direct > > bearing on how > > >>>exporter, collector, and any intervening network will > > behave under stress. > > >>> > > >>>Over and out, > > >>>Robert > > >>> > > >>>-- > > >>>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 Oct 15 11:33: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 LAA04963 for ; Wed, 15 Oct 2003 11:33:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9nIa-0004PH-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Oct 2003 10:10:52 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9nIY-0004PB-00; Wed, 15 Oct 2003 10:10:50 -0500 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel11.hp.com (Postfix) with ESMTP id 99BF31C013C0; Wed, 15 Oct 2003 08:10:49 -0700 (PDT) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 6E9081C00A74; Wed, 15 Oct 2003 08:10:49 -0700 (PDT) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <4V0BZB1L>; Wed, 15 Oct 2003 08:10:49 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A5029603B0@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'alex.audu@alcatel.com'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Peter Lei'" , "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] STCP as a default transport not Date: Wed, 15 Oct 2003 08:10:36 -0700 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 Alex, I'm not trying to misinform. It certainly appears that the designers of SCTP have addressed some sticky issues with TCP and UDP. However this is the IPFIX working group, not the SCTP advocacy working group. I believe part of an IETF's group's role is to produce a spec which can be widely utilized quickly. To that end, I see the mandatory requirement of SCTP as being an issue. -- Jeff > -----Original Message----- > From: Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Wednesday, October 15, 2003 7:29 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Peter Lei'; 'Robert Lowe'; 'Randall Stewart (cisco)'; 'Benoit > Claise'; 'stbryant@cisco.com'; carter@qosient.com; 'Reinaldo Penno'; > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > Hi Jeffery, > > I guess my point is I detect something that looks like a tendency to > miss-inform so as to make a point. If we are going to chose a protocol > to do a job, we chose it based soley on its technical merits. > Arguments > like "Oh, SCTP is kernel space transport" is just not accurate. That > prompted > my response about my personal experience in implementing SCTP > in user space. > > And I don't see anything in the SCTP specs that says it must > be in kernel > space. > > The bottom line is SCTP is a better transport than TCP. Heck, it was > designed > to correct issues with TCP in the first place. If members of > the technical > community don't reccomend it for deployment (because it is not widely > available), how is it ever going to be widely available? > > Regards, > Alex. > > "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > > > Hi, > > > > I tried to articulate my reasoning why SCTP may prove to be a > > barrier for implementors of IPFIX in non-Linux based collectors > > in the e-mail: > > > > http://ipfix.doit.wisc.edu/archive/2044.html > > > > The statement, "well, we have an implementation", doesn't mean > > that other interested parties will have the time/patience to > > acquire or develop one themselves. > > > > In fairness I will note that there is one open source user > > space implementation that I could find at: > > > > http://www.sctp.de/sctp-download.html > > > > Links to Linux and FreeBSD kernel implementations are available > > off of: > > > > http://sigtran.org/ and http://www.sctp.org/ > > > > Nonetheless, the time and testing effort to get a multiplatform > > Java based collection engine running on TCP vs. SCTP is significant. > > Consider the project plan for each activity and tell me there's no > > barrier associated w/ SCTP. > > > > Regards, > > > > Jeff Meyer > > > > > -----Original Message----- > > > From: Peter Lei [mailto:peter.lei@ieee.org] > > > Sent: Tuesday, October 14, 2003 3:13 PM > > > To: alex.audu@alcatel.com > > > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Robert Lowe'; > > > 'Randall Stewart > > > (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; > carter@qosient.com; > > > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > > > ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Alex Audu wrote: > > > > As far as I know, I don't know of any thing specifically > > > that specifies that > > > > any transport protocol must be in USER or KERNEL space. Based on > > > > what features are important to you, you could deploy SCTP > > > in kernel space > > > > for speed and efficiency, or in user space for > > > flexibility, kernel safety, and > > > > ease of coexistence with other protocols. > > > > > > Exactly... I guess my original comment/question was why was having > > > SCTP in kernel "(where SCTP belongs)" was a "problem"... that SCTP > > > in kernel space places no issues on "ubiquity". > > > > > > Perhaps the original reference was that for his > particular situation > > > (and yours too it seems) is that SCTP was only available in > > > user space. > > > > > > --peter > > > > > > > TCP has been deployed both in user and kernel spaces and > > > our in-house > > > > SCTP was deployed in user space. > > > > > > > > Regards > > > > Alex. > > > > > > > > Peter Lei wrote: > > > > > > > > > > > >>>Robert, > > > >>> > > > >>> I agree with your points, with the one caveat that user > > > vs. kernel space > > > >>>(where SCTP belongs) makes the ubiquity step just that > much harder. > > > >> > > > >>Please clarify this statement for me... SCTP is in kernel > > > space for both > > > >>Linux and xBSD platforms... there is a normal sockets API > > > for SCTP. There > > > >>is even a TCP "compatible" API such that we have been able > > > to port SSH, > > > >>FTP, Apache web server, and Mozilla browser by changes a > > > hand few lines of > > > >>code (in the socket() call change the IPPROTO_TCP or "0" to > > > IPPROTO_SCTP). > > > >> > > > >> > > > >>> I especially agree with the focus on "restrictions > imposed by the > > > >>>transport". > > > >>> > > > >>> I believe that the message set defined in the IPFIX > > > protocol to date is > > > >>>relatively transport neutral. Hence the additional > > > overhead of specifying > > > >>>the binding details to TCP and PR-SCTP seem relatively > > > straightforward, > > > >>>i.e. Diameter seemed to have no trouble here. > > > >>> > > > >>> So all I'd like to see is a preservation of that > > > transport independence > > > >>>and explicit bindings to TCP and PR-SCTP (in addition to > > > the existing UDP > > > >>>binding which is prevalent today). > > > >> > > > >>I don't see a problem with this... none of the transports > > > being discussed > > > >>places any changes/constraints on the IPFIX protocol > itself. It MAY > > > >>require the IPFIX application layer choice of "do I want to > > > this reliable > > > >>or unreliable" which might mean choose a different socket > > > descriptor or > > > >>change a parameter in my send call (in the case of > > > PR-SCTP)... but these > > > >>are known apriori by the application. > > > >> > > > >> > > > >>> The conversation seems to have devolved into a "You only > > > need SCTP and > > > >>>shouldn't use anything else" which I think ignores some > > > practical matters > > > >>>in terms of rapid implementation and adoption. > > > >> > > > >>The question posed (and remains the topic of discussion) is > > > "what should > > > >>the default transport for IPFIX be"... I read that as > "if you MUST > > > >>support only ONE transport, what should it be, given > that we want > > > >>congestion control and both reliable and unreliable export." > > > >> > > > >>Diameter essentially makes SCTP the default protocol > (it shoud be > > > >>tried first), and TCP the "fallback". Servers are required > > > to support > > > >>both. > > > >> > > > >> From RFC 3588: > > > >> > > > >>2.1. Transport > > > >> > > > >> Transport profile is defined in [AAATRANS]. > > > >> > > > >> The base Diameter protocol is run on port 3868 of both > > > TCP [TCP] and > > > >> SCTP [SCTP] transport protocols. > > > >> > > > >> Diameter clients MUST support either TCP or SCTP, while > > > agents and > > > >> servers MUST support both. Future versions of this > > > specification MAY > > > >> mandate that clients support SCTP. > > > >> > > > >> [snip] > > > >> > > > >> When connecting to a peer and either zero or more > transports are > > > >> specified, SCTP SHOULD be tried first, followed by TCP. > > > See Section > > > >> 5.2 for more information on peer discovery. > > > >> > > > >>regards, > > > >>--peter > > > >> > > > >> > > > >>>Regards, > > > >>> > > > >>> Jeff Meyer > > > >>> > > > >>> > > > >>>-----Original Message----- > > > >>>From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > > > >>>Sent: Monday, October 13, 2003 1:30 PM > > > >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > > >>>Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; > > > 'stbryant@cisco.com'; > > > >>>carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > > > >>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > >>>Subject: Re: [ipfix] STCP as a default transport not > > > >>> > > > >>> > > > >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > > >>> > > > >>>Hi Jeff! > > > >>> > > > >>> > > > >>> > > > >>>> By availability I mean you take the system out of the > > > box and w/in 5 > > > >>>>minutes > > > >>>>of booting you are able to use the service. TCP fits > > > this criteria. > > > >>>>Perhaps > > > >>>>that is also true for SCTP on IOS, I would presume given > > > your arguments. > > > >>>>However on no other platform other than Linux am I > aware of this > > > >>>>availability. > > > >>>> > > > >>>> SCTP does not come preloaded on Windows, Solaris or > > > HP-UX, and if I go > > > >>> > > > >>>the > > > >>> > > > >>> > > > >>>>the > > > >>>>Microsoft, Sun and HP sites looking for infomration on > > > how to configure > > > >>>>SCTP, I get > > > >>>>either nothing or a reference to 3rd party (for fee) > > > products to enable > > > >>>>this. > > > >>>> > > > >>>> So, although in your world this may still count as > > > "available". In the > > > >>>>world of delivering multiplatform capable packaged > > > collection SW which can > > > >>>>be > > > >>>>installed rapidly, it just don't cut it. > > > >>> > > > >>> > > > >>>De-lurking again... ;-) > > > >>> > > > >>>I assume we're talking about collectors here, not > > > exporters. Where do most > > > >>>collectors run today? Just a wild guess, but a majority > > > on Linux or moving > > > >>>there? I could be wrong though. > > > >>> > > > >>>Either way, you're providing the same argumentation that > > > you, and others, > > > >>>didn't agree with regarding candidate protocols, i.e. > > > Netflow is more > > > >>>widely implemented, making IPFIX more likely to be > > > implemented, therefore > > > >>>better. I mean, I can remember a day when Microsoft > > > didn't have their own > > > >>>implementation of TCP/IP, and noone worried. I'm not > > > advocating a "build > > > >>>it and they will come" approach, but I also recognize that > > > solutions do not > > > >>>always win out based solely on technical merit. So are > > > you wrong? Maybe > > > >>>not, but as Carter suggests, it is important to ensure > > > that the transport > > > >>>is not a hindrance to any of the other requirements. So, > > > if I had any say, > > > >>>I'd recommend focusing the discussion on any interactions > > > between any > > > >>>proposed transport and other requirements, not overly > > > worrying about what > > > >>>the landscape looks like today for both implementers and > > > end-customers, > > > >>>other than perhaps architecture, which also has direct > > > bearing on how > > > >>>exporter, collector, and any intervening network will > > > behave under stress. > > > >>> > > > >>>Over and out, > > > >>>Robert > > > >>> > > > >>>-- > > > >>>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 Oct 15 11:52:23 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 LAA05786 for ; Wed, 15 Oct 2003 11:52:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A9ne7-0004zh-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Oct 2003 10:33:07 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A9ne6-0004zb-00; Wed, 15 Oct 2003 10:33:06 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h9FFVK6E008733; Wed, 15 Oct 2003 10:31:20 -0500 (CDT) Message-ID: <3F8D6842.36FF2ABC@alcatel.com> Date: Wed, 15 Oct 2003 10:31:14 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Peter Lei'" , "'Robert Lowe'" , "'Randall Stewart (cisco)'" , "'Benoit Claise'" , "'stbryant@cisco.com'" , carter@qosient.com, "'Reinaldo Penno'" , ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] STCP as a default transport not References: <1D3D2C371FCBD947A7897FABBD3533A5029603B0@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, And I agree, as far as drive for "quick utilization" doesn't lead to a less effective and less robust solution. And by the way, neither is the IPFIX group the advocacy group for TCP. Regards, Alex. "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > Alex, > > I'm not trying to misinform. It certainly appears that the designers > of SCTP have addressed some sticky issues with TCP and UDP. > > However this is the IPFIX working group, not the SCTP advocacy working > group. I believe part of an IETF's group's role is to produce a spec > which can be widely utilized quickly. To that end, I see the mandatory > requirement of SCTP as being an issue. > > -- Jeff > > > -----Original Message----- > > From: Alex Audu [mailto:alex.audu@alcatel.com] > > Sent: Wednesday, October 15, 2003 7:29 AM > > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > Cc: 'Peter Lei'; 'Robert Lowe'; 'Randall Stewart (cisco)'; 'Benoit > > Claise'; 'stbryant@cisco.com'; carter@qosient.com; 'Reinaldo Penno'; > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > Hi Jeffery, > > > > I guess my point is I detect something that looks like a tendency to > > miss-inform so as to make a point. If we are going to chose a protocol > > to do a job, we chose it based soley on its technical merits. > > Arguments > > like "Oh, SCTP is kernel space transport" is just not accurate. That > > prompted > > my response about my personal experience in implementing SCTP > > in user space. > > > > And I don't see anything in the SCTP specs that says it must > > be in kernel > > space. > > > > The bottom line is SCTP is a better transport than TCP. Heck, it was > > designed > > to correct issues with TCP in the first place. If members of > > the technical > > community don't reccomend it for deployment (because it is not widely > > available), how is it ever going to be widely available? > > > > Regards, > > Alex. > > > > "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > > > > > Hi, > > > > > > I tried to articulate my reasoning why SCTP may prove to be a > > > barrier for implementors of IPFIX in non-Linux based collectors > > > in the e-mail: > > > > > > http://ipfix.doit.wisc.edu/archive/2044.html > > > > > > The statement, "well, we have an implementation", doesn't mean > > > that other interested parties will have the time/patience to > > > acquire or develop one themselves. > > > > > > In fairness I will note that there is one open source user > > > space implementation that I could find at: > > > > > > http://www.sctp.de/sctp-download.html > > > > > > Links to Linux and FreeBSD kernel implementations are available > > > off of: > > > > > > http://sigtran.org/ and http://www.sctp.org/ > > > > > > Nonetheless, the time and testing effort to get a multiplatform > > > Java based collection engine running on TCP vs. SCTP is significant. > > > Consider the project plan for each activity and tell me there's no > > > barrier associated w/ SCTP. > > > > > > Regards, > > > > > > Jeff Meyer > > > > > > > -----Original Message----- > > > > From: Peter Lei [mailto:peter.lei@ieee.org] > > > > Sent: Tuesday, October 14, 2003 3:13 PM > > > > To: alex.audu@alcatel.com > > > > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Robert Lowe'; > > > > 'Randall Stewart > > > > (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; > > carter@qosient.com; > > > > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > > > > ipfix@net.doit.wisc.edu > > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > > > > Alex Audu wrote: > > > > > As far as I know, I don't know of any thing specifically > > > > that specifies that > > > > > any transport protocol must be in USER or KERNEL space. Based on > > > > > what features are important to you, you could deploy SCTP > > > > in kernel space > > > > > for speed and efficiency, or in user space for > > > > flexibility, kernel safety, and > > > > > ease of coexistence with other protocols. > > > > > > > > Exactly... I guess my original comment/question was why was having > > > > SCTP in kernel "(where SCTP belongs)" was a "problem"... that SCTP > > > > in kernel space places no issues on "ubiquity". > > > > > > > > Perhaps the original reference was that for his > > particular situation > > > > (and yours too it seems) is that SCTP was only available in > > > > user space. > > > > > > > > --peter > > > > > > > > > TCP has been deployed both in user and kernel spaces and > > > > our in-house > > > > > SCTP was deployed in user space. > > > > > > > > > > Regards > > > > > Alex. > > > > > > > > > > Peter Lei wrote: > > > > > > > > > > > > > > >>>Robert, > > > > >>> > > > > >>> I agree with your points, with the one caveat that user > > > > vs. kernel space > > > > >>>(where SCTP belongs) makes the ubiquity step just that > > much harder. > > > > >> > > > > >>Please clarify this statement for me... SCTP is in kernel > > > > space for both > > > > >>Linux and xBSD platforms... there is a normal sockets API > > > > for SCTP. There > > > > >>is even a TCP "compatible" API such that we have been able > > > > to port SSH, > > > > >>FTP, Apache web server, and Mozilla browser by changes a > > > > hand few lines of > > > > >>code (in the socket() call change the IPPROTO_TCP or "0" to > > > > IPPROTO_SCTP). > > > > >> > > > > >> > > > > >>> I especially agree with the focus on "restrictions > > imposed by the > > > > >>>transport". > > > > >>> > > > > >>> I believe that the message set defined in the IPFIX > > > > protocol to date is > > > > >>>relatively transport neutral. Hence the additional > > > > overhead of specifying > > > > >>>the binding details to TCP and PR-SCTP seem relatively > > > > straightforward, > > > > >>>i.e. Diameter seemed to have no trouble here. > > > > >>> > > > > >>> So all I'd like to see is a preservation of that > > > > transport independence > > > > >>>and explicit bindings to TCP and PR-SCTP (in addition to > > > > the existing UDP > > > > >>>binding which is prevalent today). > > > > >> > > > > >>I don't see a problem with this... none of the transports > > > > being discussed > > > > >>places any changes/constraints on the IPFIX protocol > > itself. It MAY > > > > >>require the IPFIX application layer choice of "do I want to > > > > this reliable > > > > >>or unreliable" which might mean choose a different socket > > > > descriptor or > > > > >>change a parameter in my send call (in the case of > > > > PR-SCTP)... but these > > > > >>are known apriori by the application. > > > > >> > > > > >> > > > > >>> The conversation seems to have devolved into a "You only > > > > need SCTP and > > > > >>>shouldn't use anything else" which I think ignores some > > > > practical matters > > > > >>>in terms of rapid implementation and adoption. > > > > >> > > > > >>The question posed (and remains the topic of discussion) is > > > > "what should > > > > >>the default transport for IPFIX be"... I read that as > > "if you MUST > > > > >>support only ONE transport, what should it be, given > > that we want > > > > >>congestion control and both reliable and unreliable export." > > > > >> > > > > >>Diameter essentially makes SCTP the default protocol > > (it shoud be > > > > >>tried first), and TCP the "fallback". Servers are required > > > > to support > > > > >>both. > > > > >> > > > > >> From RFC 3588: > > > > >> > > > > >>2.1. Transport > > > > >> > > > > >> Transport profile is defined in [AAATRANS]. > > > > >> > > > > >> The base Diameter protocol is run on port 3868 of both > > > > TCP [TCP] and > > > > >> SCTP [SCTP] transport protocols. > > > > >> > > > > >> Diameter clients MUST support either TCP or SCTP, while > > > > agents and > > > > >> servers MUST support both. Future versions of this > > > > specification MAY > > > > >> mandate that clients support SCTP. > > > > >> > > > > >> [snip] > > > > >> > > > > >> When connecting to a peer and either zero or more > > transports are > > > > >> specified, SCTP SHOULD be tried first, followed by TCP. > > > > See Section > > > > >> 5.2 for more information on peer discovery. > > > > >> > > > > >>regards, > > > > >>--peter > > > > >> > > > > >> > > > > >>>Regards, > > > > >>> > > > > >>> Jeff Meyer > > > > >>> > > > > >>> > > > > >>>-----Original Message----- > > > > >>>From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > > > > >>>Sent: Monday, October 13, 2003 1:30 PM > > > > >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > > > >>>Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; > > > > 'stbryant@cisco.com'; > > > > >>>carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > > > > >>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > > >>>Subject: Re: [ipfix] STCP as a default transport not > > > > >>> > > > > >>> > > > > >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > > > >>> > > > > >>>Hi Jeff! > > > > >>> > > > > >>> > > > > >>> > > > > >>>> By availability I mean you take the system out of the > > > > box and w/in 5 > > > > >>>>minutes > > > > >>>>of booting you are able to use the service. TCP fits > > > > this criteria. > > > > >>>>Perhaps > > > > >>>>that is also true for SCTP on IOS, I would presume given > > > > your arguments. > > > > >>>>However on no other platform other than Linux am I > > aware of this > > > > >>>>availability. > > > > >>>> > > > > >>>> SCTP does not come preloaded on Windows, Solaris or > > > > HP-UX, and if I go > > > > >>> > > > > >>>the > > > > >>> > > > > >>> > > > > >>>>the > > > > >>>>Microsoft, Sun and HP sites looking for infomration on > > > > how to configure > > > > >>>>SCTP, I get > > > > >>>>either nothing or a reference to 3rd party (for fee) > > > > products to enable > > > > >>>>this. > > > > >>>> > > > > >>>> So, although in your world this may still count as > > > > "available". In the > > > > >>>>world of delivering multiplatform capable packaged > > > > collection SW which can > > > > >>>>be > > > > >>>>installed rapidly, it just don't cut it. > > > > >>> > > > > >>> > > > > >>>De-lurking again... ;-) > > > > >>> > > > > >>>I assume we're talking about collectors here, not > > > > exporters. Where do most > > > > >>>collectors run today? Just a wild guess, but a majority > > > > on Linux or moving > > > > >>>there? I could be wrong though. > > > > >>> > > > > >>>Either way, you're providing the same argumentation that > > > > you, and others, > > > > >>>didn't agree with regarding candidate protocols, i.e. > > > > Netflow is more > > > > >>>widely implemented, making IPFIX more likely to be > > > > implemented, therefore > > > > >>>better. I mean, I can remember a day when Microsoft > > > > didn't have their own > > > > >>>implementation of TCP/IP, and noone worried. I'm not > > > > advocating a "build > > > > >>>it and they will come" approach, but I also recognize that > > > > solutions do not > > > > >>>always win out based solely on technical merit. So are > > > > you wrong? Maybe > > > > >>>not, but as Carter suggests, it is important to ensure > > > > that the transport > > > > >>>is not a hindrance to any of the other requirements. So, > > > > if I had any say, > > > > >>>I'd recommend focusing the discussion on any interactions > > > > between any > > > > >>>proposed transport and other requirements, not overly > > > > worrying about what > > > > >>>the landscape looks like today for both implementers and > > > > end-customers, > > > > >>>other than perhaps architecture, which also has direct > > > > bearing on how > > > > >>>exporter, collector, and any intervening network will > > > > behave under stress. > > > > >>> > > > > >>>Over and out, > > > > >>>Robert > > > > >>> > > > > >>>-- > > > > >>>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 Oct 17 11:35:13 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 LAA06981 for ; Fri, 17 Oct 2003 11:35:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAWGk-0002Eh-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 10:11:58 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1AAWGj-0002EW-00 for ipfix@net.doit.wisc.edu; Fri, 17 Oct 2003 10:11:57 -0500 Received: (qmail 69353 invoked from network); 17 Oct 2003 15:11:56 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 17 Oct 2003 15:11:56 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9HFBpX02310; Fri, 17 Oct 2003 11:11:56 -0400 Reply-To: From: "Carter Bullard" To: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: "'Peter Lei'" , "'Robert Lowe'" , "'Randall Stewart \(cisco\)'" , "'Benoit Claise'" , , "'Reinaldo Penno'" , , Subject: RE: [ipfix] STCP as a default transport not Date: Fri, 17 Oct 2003 11:11:45 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6CA@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <5C8959A16A71B449AE793CF52FBBED661CE53D@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Alex, I don't think anyone on the list thinks that IPFIX shouldn't be able to use SCTP. But SCTP as the default, or SCTP as the only transport protocol? I think there is a lot of enthusiasm behind the sell job, but its more like a Chia pet ad than an engineering effort. Just add water, it will be beautiful. An engineering effort would take the SCTP applicability RFC and apply it to the IPFIX requirements to see that there is a fit. No one has done that!!!! That is how you chose a protocol to do a job! Time will tell if SCTP becomes the preferred transport for IPFIX, but without a real demonstration that includes an implementation of IPFIX over SCTP in a commercial router/switch, having the IPFIX working group specify the current standard of practice for IPFIX technology is not a bad idea. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Alex Audu > Sent: Wednesday, October 15, 2003 9:29 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Peter Lei'; 'Robert Lowe'; 'Randall Stewart (cisco)'; > 'Benoit Claise'; 'stbryant@cisco.com'; carter@qosient.com; > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] STCP as a default transport not > > > Hi Jeffery, > > I guess my point is I detect something that looks like a tendency to > miss-inform so as to make a point. If we are going to chose a protocol > to do a job, we chose it based soley on its technical merits. > Arguments > like "Oh, SCTP is kernel space transport" is just not accurate. That > prompted > my response about my personal experience in implementing SCTP > in user space. > > And I don't see anything in the SCTP specs that says it must > be in kernel > space. > > The bottom line is SCTP is a better transport than TCP. Heck, it was > designed > to correct issues with TCP in the first place. If members of > the technical > community don't reccomend it for deployment (because it is not widely > available), how is it ever going to be widely available? > > Regards, > Alex. > > "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > > > Hi, > > > > I tried to articulate my reasoning why SCTP may prove to be a > > barrier for implementors of IPFIX in non-Linux based collectors > > in the e-mail: > > > > http://ipfix.doit.wisc.edu/archive/2044.html > > > > The statement, "well, we have an implementation", doesn't mean > > that other interested parties will have the time/patience to > > acquire or develop one themselves. > > > > In fairness I will note that there is one open source user > > space implementation that I could find at: > > > > http://www.sctp.de/sctp-download.html > > > > Links to Linux and FreeBSD kernel implementations are available > > off of: > > > > http://sigtran.org/ and http://www.sctp.org/ > > > > Nonetheless, the time and testing effort to get a multiplatform > > Java based collection engine running on TCP vs. SCTP is significant. > > Consider the project plan for each activity and tell me there's no > > barrier associated w/ SCTP. > > > > Regards, > > > > Jeff Meyer > > > > > -----Original Message----- > > > From: Peter Lei [mailto:peter.lei@ieee.org] > > > Sent: Tuesday, October 14, 2003 3:13 PM > > > To: alex.audu@alcatel.com > > > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Robert Lowe'; > > > 'Randall Stewart > > > (cisco)'; 'Benoit Claise'; 'stbryant@cisco.com'; > carter@qosient.com; > > > 'Reinaldo Penno'; ipfix-chairs@net.doit.wisc.edu; > > > ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] STCP as a default transport not > > > > > > > > > Alex Audu wrote: > > > > As far as I know, I don't know of any thing specifically > > > that specifies that > > > > any transport protocol must be in USER or KERNEL space. Based on > > > > what features are important to you, you could deploy SCTP > > > in kernel space > > > > for speed and efficiency, or in user space for > > > flexibility, kernel safety, and > > > > ease of coexistence with other protocols. > > > > > > Exactly... I guess my original comment/question was why was having > > > SCTP in kernel "(where SCTP belongs)" was a "problem"... that SCTP > > > in kernel space places no issues on "ubiquity". > > > > > > Perhaps the original reference was that for his > particular situation > > > (and yours too it seems) is that SCTP was only available in > > > user space. > > > > > > --peter > > > > > > > TCP has been deployed both in user and kernel spaces and > > > our in-house > > > > SCTP was deployed in user space. > > > > > > > > Regards > > > > Alex. > > > > > > > > Peter Lei wrote: > > > > > > > > > > > >>>Robert, > > > >>> > > > >>> I agree with your points, with the one caveat that user > > > vs. kernel space > > > >>>(where SCTP belongs) makes the ubiquity step just that > much harder. > > > >> > > > >>Please clarify this statement for me... SCTP is in kernel > > > space for both > > > >>Linux and xBSD platforms... there is a normal sockets API > > > for SCTP. There > > > >>is even a TCP "compatible" API such that we have been able > > > to port SSH, > > > >>FTP, Apache web server, and Mozilla browser by changes a > > > hand few lines of > > > >>code (in the socket() call change the IPPROTO_TCP or "0" to > > > IPPROTO_SCTP). > > > >> > > > >> > > > >>> I especially agree with the focus on "restrictions > imposed by the > > > >>>transport". > > > >>> > > > >>> I believe that the message set defined in the IPFIX > > > protocol to date is > > > >>>relatively transport neutral. Hence the additional > > > overhead of specifying > > > >>>the binding details to TCP and PR-SCTP seem relatively > > > straightforward, > > > >>>i.e. Diameter seemed to have no trouble here. > > > >>> > > > >>> So all I'd like to see is a preservation of that > > > transport independence > > > >>>and explicit bindings to TCP and PR-SCTP (in addition to > > > the existing UDP > > > >>>binding which is prevalent today). > > > >> > > > >>I don't see a problem with this... none of the transports > > > being discussed > > > >>places any changes/constraints on the IPFIX protocol > itself. It MAY > > > >>require the IPFIX application layer choice of "do I want to > > > this reliable > > > >>or unreliable" which might mean choose a different socket > > > descriptor or > > > >>change a parameter in my send call (in the case of > > > PR-SCTP)... but these > > > >>are known apriori by the application. > > > >> > > > >> > > > >>> The conversation seems to have devolved into a "You only > > > need SCTP and > > > >>>shouldn't use anything else" which I think ignores some > > > practical matters > > > >>>in terms of rapid implementation and adoption. > > > >> > > > >>The question posed (and remains the topic of discussion) is > > > "what should > > > >>the default transport for IPFIX be"... I read that as > "if you MUST > > > >>support only ONE transport, what should it be, given > that we want > > > >>congestion control and both reliable and unreliable export." > > > >> > > > >>Diameter essentially makes SCTP the default protocol > (it shoud be > > > >>tried first), and TCP the "fallback". Servers are required > > > to support > > > >>both. > > > >> > > > >> From RFC 3588: > > > >> > > > >>2.1. Transport > > > >> > > > >> Transport profile is defined in [AAATRANS]. > > > >> > > > >> The base Diameter protocol is run on port 3868 of both > > > TCP [TCP] and > > > >> SCTP [SCTP] transport protocols. > > > >> > > > >> Diameter clients MUST support either TCP or SCTP, while > > > agents and > > > >> servers MUST support both. Future versions of this > > > specification MAY > > > >> mandate that clients support SCTP. > > > >> > > > >> [snip] > > > >> > > > >> When connecting to a peer and either zero or more > transports are > > > >> specified, SCTP SHOULD be tried first, followed by TCP. > > > See Section > > > >> 5.2 for more information on peer discovery. > > > >> > > > >>regards, > > > >>--peter > > > >> > > > >> > > > >>>Regards, > > > >>> > > > >>> Jeff Meyer > > > >>> > > > >>> > > > >>>-----Original Message----- > > > >>>From: Robert Lowe [mailto:Robert.H.Lowe@lawrence.edu] > > > >>>Sent: Monday, October 13, 2003 1:30 PM > > > >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > > >>>Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; > > > 'stbryant@cisco.com'; > > > >>>carter@qosient.com; alex.audu@alcatel.com; 'Reinaldo Penno'; > > > >>>ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu > > > >>>Subject: Re: [ipfix] STCP as a default transport not > > > >>> > > > >>> > > > >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > > >>> > > > >>>Hi Jeff! > > > >>> > > > >>> > > > >>> > > > >>>> By availability I mean you take the system out of the > > > box and w/in 5 > > > >>>>minutes > > > >>>>of booting you are able to use the service. TCP fits > > > this criteria. > > > >>>>Perhaps > > > >>>>that is also true for SCTP on IOS, I would presume given > > > your arguments. > > > >>>>However on no other platform other than Linux am I > aware of this > > > >>>>availability. > > > >>>> > > > >>>> SCTP does not come preloaded on Windows, Solaris or > > > HP-UX, and if I go > > > >>> > > > >>>the > > > >>> > > > >>> > > > >>>>the > > > >>>>Microsoft, Sun and HP sites looking for infomration on > > > how to configure > > > >>>>SCTP, I get > > > >>>>either nothing or a reference to 3rd party (for fee) > > > products to enable > > > >>>>this. > > > >>>> > > > >>>> So, although in your world this may still count as > > > "available". In the > > > >>>>world of delivering multiplatform capable packaged > > > collection SW which can > > > >>>>be > > > >>>>installed rapidly, it just don't cut it. > > > >>> > > > >>> > > > >>>De-lurking again... ;-) > > > >>> > > > >>>I assume we're talking about collectors here, not > > > exporters. Where do most > > > >>>collectors run today? Just a wild guess, but a majority > > > on Linux or moving > > > >>>there? I could be wrong though. > > > >>> > > > >>>Either way, you're providing the same argumentation that > > > you, and others, > > > >>>didn't agree with regarding candidate protocols, i.e. > > > Netflow is more > > > >>>widely implemented, making IPFIX more likely to be > > > implemented, therefore > > > >>>better. I mean, I can remember a day when Microsoft > > > didn't have their own > > > >>>implementation of TCP/IP, and noone worried. I'm not > > > advocating a "build > > > >>>it and they will come" approach, but I also recognize that > > > solutions do not > > > >>>always win out based solely on technical merit. So are > > > you wrong? Maybe > > > >>>not, but as Carter suggests, it is important to ensure > > > that the transport > > > >>>is not a hindrance to any of the other requirements. So, > > > if I had any say, > > > >>>I'd recommend focusing the discussion on any interactions > > > between any > > > >>>proposed transport and other requirements, not overly > > > worrying about what > > > >>>the landscape looks like today for both implementers and > > > end-customers, > > > >>>other than perhaps architecture, which also has direct > > > bearing on how > > > >>>exporter, collector, and any intervening network will > > > behave under stress. > > > >>> > > > >>>Over and out, > > > >>>Robert > > > >>> > > > >>>-- > > > >>>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 Oct 17 14:06: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 OAA13866 for ; Fri, 17 Oct 2003 14:06:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAYsE-0006um-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 12:58:50 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AAYsC-0006ub-00 for ipfix@net.doit.wisc.edu; Fri, 17 Oct 2003 12:58:48 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9HHwi2q045378 for ; Fri, 17 Oct 2003 19:58:46 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9HHwfUH045372 for ; Fri, 17 Oct 2003 19:58:41 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9HHwd2o045370; Fri, 17 Oct 2003 19:58:41 +0200 (CEST) Received: from ccrle.nec.de (molina.office [10.1.1.126]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A7A68D5115; Fri, 17 Oct 2003 19:24:57 +0200 (CEST) Message-ID: <3F902DCF.3020509@ccrle.nec.de> Date: Fri, 17 Oct 2003 19:58:39 +0200 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com Cc: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] CUrrent issues, Draft deadlines References: <5C8959A16A71B449AE793CF52FBBED6607A6C6@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil, Carter, my position would be to support both Counters and Integers in the information model, and to NOT make any default choice, but rather request with a MUST that the IPFIX devices support both. In fact, on the ML we had arguments pro/against Integers and arguments pro/against Counters, and all of them are probably correct given the application that had in mind who wrote them. But that's exacly the point: in theory ANY application receiving flow records and making something out of them could work both with Integers and Counters (provided it knows what it is receiving...). Of course there are applications that care most about variations (e.g. load monitoring) and therefore are happy with Integers, but can also work with Counters (they just need more processing). Simmetrically, there are applications that need the total amount of traffic of a flow (e.g. Charging) and therefore are happy with Counters, but can also work with Integers (they just need more processing). But I can envisage that there can be "poor" or legacy applications that can only work with either Integers or Counters (not both), and if the probe cannot support the data in the format they need they cannot work at all. Of course, making a default choice gives more chance for market differentiation ("good" probes will support both...) but opens the door to interoperability problems. Maurizio Carter Bullard wrote: >Hey Nevil, > With regard to counters vs integers. I would suggest that >the better default choice would be integers. Counters >would require that originators of IPFIX always support the >largest data type possible, where an integers strategy can >be used by a probe to limit the size of the reported metrics. >This would provide the opportunity to control the >memory demands of a probe, and minimize the amount of >data on the wire. > > Because counters have roll-over behaviors, regardless >of the size of the counters you support, the counter strategy >is fundamentally the same as integers, except that with >counters you throw away some intermediate records and keep >others. This introduces possible uncertainty. The reader is >throwing away data, did it throw away the right data? I >would rather like to avoid having any IPFIX component >throw away data as a part of its basic function. > >Carter > > > > >> >>IM-1: Counters vs Integers >> We seem to acknowledge that counters (running totals) and Integers >> (reset to zero when the exporter sends out data about a flow) can >> both be useful, so the Information Model needs to have both Counter >> and Integer types. >> >> My experience with RTFM is that counters have the advantage that >> it doesn't matter if you loose a few intermediate counts for any >> reason. If that happens you loose some time granularity, but you >> still have most, or at least some, of the packet and byte counts >> for the flow. >> >> I'm not sure that - at least for packet and byte counts - we need >> both. could we agree to only have counters? >> >> >> >> > > -- 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 Oct 17 14:21:00 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 OAA14552 for ; Fri, 17 Oct 2003 14:21:00 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAZ7A-0007OE-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 13:14:16 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AAZ79-0007O9-00 for ipfix@net.doit.wisc.edu; Fri, 17 Oct 2003 13:14:15 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9HIEE2o046148 for ; Fri, 17 Oct 2003 20:14:14 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9HIEA4Q046146 for ; Fri, 17 Oct 2003 20:14:10 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9HIEA2o046145; Fri, 17 Oct 2003 20:14:10 +0200 (CEST) Received: from ccrle.nec.de (molina.office [10.1.1.126]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8D271AAE75; Fri, 17 Oct 2003 19:40:27 +0200 (CEST) Message-ID: <3F903171.20108@ccrle.nec.de> Date: Fri, 17 Oct 2003 20:14:09 +0200 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brown, Mark R, ALABS" Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] reporting about tossed data References: <9473683187ADC049A855ED2DA739ABCA2378B5@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Mark, I changed the subject replying to your e-mail because it was on the thread "STCP as a default transport not", which is not my intention to discuss here. Rather, I wanted to point you to the ID I've just posted to the IPFIX list on "Flow selection support in IPFIX" http://www.ietf.org/internet-drafts/draft-molina-flow-selection-00.txt where there is some reasoning (even if in a different context) about what can be reported about data tossed by the exporter. May be it can be a starting point? Maurizio >I agree that it would be desireable to have a mechanism in IPFIX to >to report to the collector on the amount of data tossed by the exporter >due to buffer >overflow (e.g., total flows, bytes, start and end times) once the >congestion period has cleared. Could such a mechanism be defined so >that it would require a fixed maximum amount of memory (ignoring >possible counter wrap) regardless of the length of the congestion >period(s) or the amount of data loss? > >Mark Brown >AT&T > > > -- 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 Oct 17 14:29: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 OAA14989 for ; Fri, 17 Oct 2003 14:29:32 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAZF5-0007jA-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 13:22:27 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AAZF4-0007j2-00 for ipfix@net.doit.wisc.edu; Fri, 17 Oct 2003 13:22:26 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id D6A831C028BC; Fri, 17 Oct 2003 14:22:25 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id CF15A1C00A5D; Fri, 17 Oct 2003 14:22:25 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4V7MYPYG>; Fri, 17 Oct 2003 14:22:25 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A507D0864B@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Maurizio Molina'" , carter@qosient.com Cc: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] CUrrent issues, Draft deadlines Date: Fri, 17 Oct 2003 14:22:19 -0400 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 Maurizio, I agree with your sentiments around requiring both. I disagree with your statement that counters benefit charging. Again, most flows are single export records which you either receive or you don't. State management for counters, make them most useful if you have a relatively constrained space (i.e. it may be OK for exporter based aggregation schemes such as NFv8), but in the situation where each flow has a unique src/dstIP and src/dstPort we're talking about millions of possible counters to maintain. Integers are how deployed Netflow works today, and I would not recommend changing something which works. Regards, Jeff Meyer > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Maurizio Molina > Sent: Friday, October 17, 2003 10:59 AM > To: carter@qosient.com > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] CUrrent issues, Draft deadlines > > > Nevil, Carter, > my position would be to support both Counters and Integers in the > information model, and to NOT make any default choice, but rather > request with a MUST that the IPFIX devices support both. > > In fact, on the ML we had arguments pro/against Integers and > arguments > pro/against Counters, and all of them are probably correct given the > application that had in mind who wrote them. > But that's exacly the point: in theory ANY application receiving flow > records and making something out of them could work both with > Integers > and Counters (provided it knows what it is receiving...). Of course > there are applications that care most about variations (e.g. load > monitoring) and therefore are happy with Integers, but can also work > with Counters (they just need more processing). > Simmetrically, there are > applications that need the total amount of traffic of a flow (e.g. > Charging) and therefore are happy with Counters, but can also > work with > Integers (they just need more processing). > But I can envisage that there can be "poor" or legacy > applications that > can only work with either Integers > or Counters (not both), and if the probe cannot support the > data in the > format they need they cannot work at all. > > Of course, making a default choice gives more chance for market > differentiation ("good" probes will support both...) but > opens the door > to interoperability problems. > > Maurizio > > Carter Bullard wrote: > > >Hey Nevil, > > With regard to counters vs integers. I would suggest that > >the better default choice would be integers. Counters > >would require that originators of IPFIX always support the > >largest data type possible, where an integers strategy can > >be used by a probe to limit the size of the reported metrics. > >This would provide the opportunity to control the > >memory demands of a probe, and minimize the amount of > >data on the wire. > > > > Because counters have roll-over behaviors, regardless > >of the size of the counters you support, the counter strategy > >is fundamentally the same as integers, except that with > >counters you throw away some intermediate records and keep > >others. This introduces possible uncertainty. The reader is > >throwing away data, did it throw away the right data? I > >would rather like to avoid having any IPFIX component > >throw away data as a part of its basic function. > > > >Carter > > > > > > > > > >> > >>IM-1: Counters vs Integers > >> We seem to acknowledge that counters (running totals) > and Integers > >> (reset to zero when the exporter sends out data about a flow) can > >> both be useful, so the Information Model needs to have > both Counter > >> and Integer types. > >> > >> My experience with RTFM is that counters have the advantage that > >> it doesn't matter if you loose a few intermediate counts for any > >> reason. If that happens you loose some time granularity, but you > >> still have most, or at least some, of the packet and byte counts > >> for the flow. > >> > >> I'm not sure that - at least for packet and byte counts - we need > >> both. could we agree to only have counters? > >> > >> > >> > >> > > > > > > > -- > 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 Oct 17 14:44: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 OAA15384 for ; Fri, 17 Oct 2003 14:44:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAZUb-0000Md-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 13:38:29 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1AAZUa-0000MW-00 for ipfix@net.doit.wisc.edu; Fri, 17 Oct 2003 13:38:28 -0500 Received: (qmail 81506 invoked from network); 17 Oct 2003 18:38:27 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 17 Oct 2003 18:38:27 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9HIcRX02392; Fri, 17 Oct 2003 14:38:27 -0400 Reply-To: From: "Carter Bullard" To: "'Maurizio Molina'" Cc: "'Nevil Brownlee'" , Subject: RE: [ipfix] CUrrent issues, Draft deadlines Date: Fri, 17 Oct 2003 14:38:23 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6CD@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <5C8959A16A71B449AE793CF52FBBED661CE6A1@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Maurizio, I completely agree with your arguments, but I'd rather not put a requirement on the probe that it MUST support counters. My reason for choosing integers is based solely from the perspective of the probe, with a desire to help them be inexpensive and perform well in demanding environments. I think this perspective is appropriate because an application can adjust, regardless of what strategy the data originator uses. But my experience is that it is easier for the application to deal with integers over counters because it reduces the states that the application must hold. Consider the situation where the probe is a high performance probe in a demanding environment, say supporting 10M+ simultaneous flows. The probe wants to support small metrics, say 16-bit ints for the packet and byte values, because most flows don't really live very long. For the small percentage of long lived flows, a counter method quickly reduces to a complex integer strategy, because the roll-over condition occurs very frequently, forcing the reader to recover the counter strategy with a large metric size, say 32-bit ints. It would be inefficient for the probe to keep 64-bit counters for every metric in order to give an application a counter view for a very small percentage of the traffic. Carter > -----Original Message----- > From: Maurizio Molina [mailto:molina@ccrle.nec.de] > Sent: Friday, October 17, 2003 12:59 PM > To: carter@qosient.com > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] CUrrent issues, Draft deadlines > > > Nevil, Carter, > my position would be to support both Counters and Integers in the > information model, and to NOT make any default choice, but rather > request with a MUST that the IPFIX devices support both. > > In fact, on the ML we had arguments pro/against Integers and > arguments > pro/against Counters, and all of them are probably correct given the > application that had in mind who wrote them. > But that's exacly the point: in theory ANY application receiving flow > records and making something out of them could work both with > Integers > and Counters (provided it knows what it is receiving...). Of course > there are applications that care most about variations (e.g. load > monitoring) and therefore are happy with Integers, but can also work > with Counters (they just need more processing). > Simmetrically, there are > applications that need the total amount of traffic of a flow (e.g. > Charging) and therefore are happy with Counters, but can also > work with > Integers (they just need more processing). > But I can envisage that there can be "poor" or legacy > applications that > can only work with either Integers > or Counters (not both), and if the probe cannot support the > data in the > format they need they cannot work at all. > > Of course, making a default choice gives more chance for market > differentiation ("good" probes will support both...) but > opens the door > to interoperability problems. > > Maurizio > > Carter Bullard wrote: > > >Hey Nevil, > > With regard to counters vs integers. I would suggest that > >the better default choice would be integers. Counters > >would require that originators of IPFIX always support the > >largest data type possible, where an integers strategy can > >be used by a probe to limit the size of the reported metrics. > >This would provide the opportunity to control the > >memory demands of a probe, and minimize the amount of > >data on the wire. > > > > Because counters have roll-over behaviors, regardless > >of the size of the counters you support, the counter strategy > >is fundamentally the same as integers, except that with > >counters you throw away some intermediate records and keep > >others. This introduces possible uncertainty. The reader is > >throwing away data, did it throw away the right data? I > >would rather like to avoid having any IPFIX component > >throw away data as a part of its basic function. > > > >Carter > > > > > > > > > >> > >>IM-1: Counters vs Integers > >> We seem to acknowledge that counters (running totals) > and Integers > >> (reset to zero when the exporter sends out data about a flow) can > >> both be useful, so the Information Model needs to have > both Counter > >> and Integer types. > >> > >> My experience with RTFM is that counters have the advantage that > >> it doesn't matter if you loose a few intermediate counts for any > >> reason. If that happens you loose some time granularity, but you > >> still have most, or at least some, of the packet and byte counts > >> for the flow. > >> > >> I'm not sure that - at least for packet and byte counts - we need > >> both. could we agree to only have counters? > >> > >> > >> > >> > > > > > -- 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 Oct 17 14:54:11 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 OAA15710 for ; Fri, 17 Oct 2003 14:54:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAZde-0000gS-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 13:47:50 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AAZdd-0000gM-00; Fri, 17 Oct 2003 13:47:49 -0500 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HIli425515; Fri, 17 Oct 2003 11:47:44 -0700 (PDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HIleA29288; Fri, 17 Oct 2003 13:47:41 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Oct 2003 11:47:41 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F9303D7C808@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: carter@qosient.com, alex.audu@alcatel.com, "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: Peter Lei , Robert Lowe , "Randall Stewart (cisco)" , Benoit Claise , stbryant@cisco.com, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Tentative summary (was RE: [ipfix] STCP as a default transport not) Date: Fri, 17 Oct 2003 11:47:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C394DF.22F26B5A" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C394DF.22F26B5A Content-Type: text/plain; charset="ISO-8859-1" I'm trying to understand something. Is there anyone that proposes SCTP to be the ONLY protocol? I'm following the discussions on which is better, time to market, etc, but this is not clear to me. Is there someone that does NOT agree with having TCP as default and SCTP as optional? In the protocol draft we would specify mappings, template management, fail-over, etc for both of them. SCTP would not be ditched from the draft in any way. Is this a good compromise? There is no need to send your list of objections either way, I'm trying to understand the positions on SCTP only vs (TCP and SCTP) with TCP as default. Thanks, Reinaldo ------_=_NextPart_001_01C394DF.22F26B5A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tentative summary (was RE: [ipfix] STCP as a default transport = not)

I'm trying to understand something. Is there anyone = that proposes SCTP to be the ONLY protocol? I'm following the = discussions on which is better, time to market, etc, but this is not = clear to me.


Is there someone that does NOT agree with having TCP = as default and SCTP as optional? In the protocol draft we would specify = mappings, template management, fail-over, etc for both of them. SCTP = would not be ditched from the draft in any way. Is this a good = compromise?

There is no need to send your list of objections = either way, I'm trying to understand the positions on SCTP only vs (TCP = and SCTP) with TCP as default.


Thanks,

Reinaldo




------_=_NextPart_001_01C394DF.22F26B5A-- -- 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 Oct 17 14:59: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 OAA15830 for ; Fri, 17 Oct 2003 14:59:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAZiC-0000kQ-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 13:52:32 -0500 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AAZiB-0000kL-00 for ipfix@net.doit.wisc.edu; Fri, 17 Oct 2003 13:52:31 -0500 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h9HJ1WC21523; Fri, 17 Oct 2003 12:01:33 -0700 From: "Tal Givoly" To: "Maurizio Molina" , Cc: "'Nevil Brownlee'" , Subject: RE: [ipfix] CUrrent issues, Draft deadlines Date: Fri, 17 Oct 2003 11:51:51 -0700 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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F902DCF.3020509@ccrle.nec.de> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I tend to support the notion of having both in the information model. However, I can see that devices would clearly prefer one or the other and we shouldn't mandate what the device internally uses and exports. I believe here that the downstream system should have the flexibility to deal with either of them rather than both being mandatory. A few examples of where it may be more complex to maintain both counters and delta (integers) in the device: For a (current) NetFlow exporter to maintain running counters could imply considerable re-engineering, because flows cannot merely be aged and sent out - you need to retain state. On the other hand, if you previously maintained counter (for instance ifEntry), and you support multiple collectors, and you are now forced to have "delta" output - you need to keep state for each one of the consumers or mandate that all consumers see the same events at the same time - and retain the value of that event. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Maurizio Molina Sent: Friday, October 17, 2003 10:59 AM To: carter@qosient.com Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] CUrrent issues, Draft deadlines Nevil, Carter, my position would be to support both Counters and Integers in the information model, and to NOT make any default choice, but rather request with a MUST that the IPFIX devices support both. In fact, on the ML we had arguments pro/against Integers and arguments pro/against Counters, and all of them are probably correct given the application that had in mind who wrote them. But that's exacly the point: in theory ANY application receiving flow records and making something out of them could work both with Integers and Counters (provided it knows what it is receiving...). Of course there are applications that care most about variations (e.g. load monitoring) and therefore are happy with Integers, but can also work with Counters (they just need more processing). Simmetrically, there are applications that need the total amount of traffic of a flow (e.g. Charging) and therefore are happy with Counters, but can also work with Integers (they just need more processing). But I can envisage that there can be "poor" or legacy applications that can only work with either Integers or Counters (not both), and if the probe cannot support the data in the format they need they cannot work at all. Of course, making a default choice gives more chance for market differentiation ("good" probes will support both...) but opens the door to interoperability problems. Maurizio Carter Bullard wrote: >Hey Nevil, > With regard to counters vs integers. I would suggest that >the better default choice would be integers. Counters >would require that originators of IPFIX always support the >largest data type possible, where an integers strategy can >be used by a probe to limit the size of the reported metrics. >This would provide the opportunity to control the >memory demands of a probe, and minimize the amount of >data on the wire. > > Because counters have roll-over behaviors, regardless >of the size of the counters you support, the counter strategy >is fundamentally the same as integers, except that with >counters you throw away some intermediate records and keep >others. This introduces possible uncertainty. The reader is >throwing away data, did it throw away the right data? I >would rather like to avoid having any IPFIX component >throw away data as a part of its basic function. > >Carter > > > > >> >>IM-1: Counters vs Integers >> We seem to acknowledge that counters (running totals) and Integers >> (reset to zero when the exporter sends out data about a flow) can >> both be useful, so the Information Model needs to have both Counter >> and Integer types. >> >> My experience with RTFM is that counters have the advantage that >> it doesn't matter if you loose a few intermediate counts for any >> reason. If that happens you loose some time granularity, but you >> still have most, or at least some, of the packet and byte counts >> for the flow. >> >> I'm not sure that - at least for packet and byte counts - we need >> both. could we agree to only have counters? >> >> >> >> > > -- 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 Oct 17 15:00: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 PAA15884 for ; Fri, 17 Oct 2003 15:00:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AAZj8-0000py-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Oct 2003 13:53:30 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1AAZj7-0000pp-00 for ipfix@net.doit.wisc.edu; Fri, 17 Oct 2003 13:53:29 -0500 Received: (qmail 89207 invoked from network); 17 Oct 2003 18:53:27 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 17 Oct 2003 18:53:27 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h9HIrSX02397; Fri, 17 Oct 2003 14:53:28 -0400 Reply-To: From: "Carter Bullard" To: "'Reinaldo Penno'" , , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: "'Peter Lei'" , "'Robert Lowe'" , "'Randall Stewart \(cisco\)'" , "'Benoit Claise'" , , , Subject: RE: Tentative summary (was RE: [ipfix] STCP as a default transport not) Date: Fri, 17 Oct 2003 14:53:24 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6CE@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <5C8959A16A71B449AE793CF52FBBED661CE6B1@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Hey Reinaldo, Well, yes, that was the position of the 4-5 Cisco employees that sent mail. Benoit, Randall, Peter Lei, and Stevan Bryant, (there maybe another, I'm sorry if I'm not keeping up) all suggested that SCTP would be perfect for both the reliable and unreliable transport needs of IPFIX, so they proposed a single protocol, which of course would be the default. Carter -----Original Message----- From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] Sent: Friday, October 17, 2003 1:48 PM To: carter@qosient.com; alex.audu@alcatel.com; MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: Peter Lei; Robert Lowe; Randall Stewart (cisco); Benoit Claise; stbryant@cisco.com; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: Tentative summary (was RE: [ipfix] STCP as a default transport not) I'm trying to understand something. Is there anyone that proposes SCTP to be the ONLY protocol? I'm following the discussions on which is better, time to market, etc, but this is not clear to me. Is there someone that does NOT agree with having TCP as default and SCTP as optional? In the protocol draft we would specify mappings, template management, fail-over, etc for both of them. SCTP would not be ditched from the draft in any way. Is this a good compromise? There is no need to send your list of objections either way, I'm trying to understand the positions on SCTP only vs (TCP and SCTP) with TCP as default. Thanks, Reinaldo -- 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 Sun Oct 19 09:32:18 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 JAA07724 for ; Sun, 19 Oct 2003 09:32:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ABDGl-0001hd-00 for ipfix-list@mil.doit.wisc.edu; Sun, 19 Oct 2003 08:06:51 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ABDGk-0001hX-00; Sun, 19 Oct 2003 08:06:50 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9JD6jjP014887; Sun, 19 Oct 2003 06:06:46 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANH36036; Sun, 19 Oct 2003 06:06:44 -0700 (PDT) Message-ID: <3F928C66.90801@cisco.com> Date: Sun, 19 Oct 2003 08:06:46 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: carter@qosient.com CC: "'Reinaldo Penno'" , alex.audu@alcatel.com, "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" , "'Peter Lei'" , "'Robert Lowe'" , "'Benoit Claise'" , stbryant@cisco.com, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: Tentative summary (was RE: [ipfix] STCP as a default transport not) References: <5C8959A16A71B449AE793CF52FBBED6607A6CE@ptah.newyork.qosient.com> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6CE@ptah.newyork.qosient.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter: I think there may have been one or two others not at Cisco that have taken this position as well.. but since I can't speak for anyone but myself.. let me state it explicitly for me.. 1) I see no need to specify TCP at all.. it gains you nothing. 2) SCTP is available on at least 30 or more platforms and is currently deployed in the big I doing SS7 call control over the network.. its available and there so I see no deployment issues. 3) PR-SCTP may not yet be there in all of the implementations.. but that is not a problem either since if you don't have PR-SCTP then you end up with a basic SCTP wth full reliability.. which is no different than TCP. 4) I would be strongly against any "mandatory to implement" TCP. 5) If you want to make it mandatory to impelment SCTP and optional to implement TCP .. I would accept that as a compromise. 6) As an alternative make NEITHER protocol mandatory and let the market decide. R Carter Bullard wrote: >Hey Reinaldo, > Well, yes, that was the position of the 4-5 Cisco employees >that sent mail. Benoit, Randall, Peter Lei, and Stevan Bryant, >(there maybe another, I'm sorry if I'm not keeping up) all >suggested that SCTP would be perfect for both the reliable and >unreliable transport needs of IPFIX, so they proposed a single >protocol, which of course would be the default. > >Carter > > >-----Original Message----- >From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] >Sent: Friday, October 17, 2003 1:48 PM >To: carter@qosient.com; alex.audu@alcatel.com; MEYER,JEFFREY D >(HP-Cupertino,ex1) >Cc: Peter Lei; Robert Lowe; Randall Stewart (cisco); Benoit Claise; >stbryant@cisco.com; ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu >Subject: Tentative summary (was RE: [ipfix] STCP as a default transport not) > > >I'm trying to understand something. Is there anyone that proposes SCTP to be >the ONLY protocol? I'm following the discussions on which is better, time to >market, etc, but this is not clear to me. > > >Is there someone that does NOT agree with having TCP as default and SCTP as >optional? In the protocol draft we would specify mappings, template >management, fail-over, etc for both of them. SCTP would not be ditched from >the draft in any way. Is this a good compromise? >There is no need to send your list of objections either way, I'm trying to >understand the positions on SCTP only vs (TCP and SCTP) with TCP as default. > > >Thanks, >Reinaldo > > > > >-- >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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Oct 20 11:53:30 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 LAA01494 for ; Mon, 20 Oct 2003 11:53:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ABbwA-0000NF-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Oct 2003 10:27:14 -0500 Received: from sv1.eng.oar.net ([192.148.251.86]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1ABbwA-0000N9-00 for ipfix@net.doit.wisc.edu; Mon, 20 Oct 2003 10:27:14 -0500 Received: (qmail 54967 invoked from network); 20 Oct 2003 15:27:13 -0000 Received: from dev1.eng.oar.net (192.148.251.71) by sv1.eng.oar.net with SMTP; 20 Oct 2003 15:27:13 -0000 Received: (qmail 15689 invoked by uid 4454); 20 Oct 2003 15:27:13 -0000 Date: Mon, 20 Oct 2003 11:27:13 -0400 From: Mark Fullmer To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] default transport !!! Message-ID: <20031020112713.A15682@net.ohio-state.edu> References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz>; from n.brownlee@auckland.ac.nz on Wed, Oct 15, 2003 at 03:18:45PM +1300 Precedence: bulk Sender: majordomo listserver How about if we skip the mandatory and optional section for now and just specify TCP and SCTP. This allows us to move forward with the ID, implementations with both protocols can be developed, etc. The decision on which protocol is mandatory should be based on working implementations, not speculation. mark On Wed, Oct 15, 2003 at 03:18:45PM +1300, Nevil Brownlee wrote: > > Hi all: > > In an attempt to move the 'default transport' discussion forward a little, > can I have some feedback on my suggestion a day or two back, i.e. how > about this .. > > TCP mandatory to implement = easy to make collectors > > SCTP optional = equipment / flow collector developers > can demonstrate advantages for users > of IPFIX over SCTP > > I suggested this because it seems to me that lots of people may develop > IPFIX collectors, wheras not too many will be developing exporters. > > 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/ -- 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 Oct 20 13:14:16 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 NAA04228 for ; Mon, 20 Oct 2003 13:14:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ABdLe-0002o5-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Oct 2003 11:57:38 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ABdLd-0002o0-00 for ipfix@net.doit.wisc.edu; Mon, 20 Oct 2003 11:57:38 -0500 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 18:55:40 +0200 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9KGvXiw014064; Mon, 20 Oct 2003 09:57:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANH85389; Mon, 20 Oct 2003 09:57:32 -0700 (PDT) Message-ID: <3F9413FF.1020700@cisco.com> Date: Mon, 20 Oct 2003 11:57:35 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Fullmer CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] default transport !!! References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> <20031020112713.A15682@net.ohio-state.edu> In-Reply-To: <20031020112713.A15682@net.ohio-state.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Mark: I could live with that for now :> It might be a way forward... Nevil? R Mark Fullmer wrote: >How about if we skip the mandatory and optional section for now and >just specify TCP and SCTP. This allows us to move forward with the >ID, implementations with both protocols can be developed, etc. > >The decision on which protocol is mandatory should be based >on working implementations, not speculation. > >mark > >On Wed, Oct 15, 2003 at 03:18:45PM +1300, Nevil Brownlee wrote: > > >>Hi all: >> >>In an attempt to move the 'default transport' discussion forward a little, >>can I have some feedback on my suggestion a day or two back, i.e. how >>about this .. >> >> TCP mandatory to implement = easy to make collectors >> >> SCTP optional = equipment / flow collector developers >> can demonstrate advantages for users >> of IPFIX over SCTP >> >>I suggested this because it seems to me that lots of people may develop >>IPFIX collectors, wheras not too many will be developing exporters. >> >>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/ >> >> > >-- >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/ > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Oct 20 14:36:52 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 OAA07120 for ; Mon, 20 Oct 2003 14:36:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ABehl-00052m-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Oct 2003 13:24:33 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ABehk-00052g-00 for ipfix@net.doit.wisc.edu; Mon, 20 Oct 2003 13:24:32 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABehk-000Dky-4G; Mon, 20 Oct 2003 18:24:32 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABehj-0006fl-E4; Mon, 20 Oct 2003 13:24:31 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 20 Oct 2003 13:24:30 -0500 To: Mark Fullmer Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] default transport !!! References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> <20031020112713.A15682@net.ohio-state.edu> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > How about if we skip the mandatory and optional section for now and > just specify TCP and SCTP. the goal is for end users to be able to plug together prodcuts from different vendors and have them interoperate. without a transport being known to be available, i.e., mandatory to implement, please explain how this will work? randy -- 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 Oct 21 13:50:08 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 NAA28072 for ; Tue, 21 Oct 2003 13:50:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC03U-0002EP-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 12:12:24 -0500 Received: from sv1.eng.oar.net ([192.148.251.86]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1AC03T-0002EK-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 12:12:23 -0500 Received: (qmail 64554 invoked from network); 21 Oct 2003 17:12:22 -0000 Received: from dev1.eng.oar.net (192.148.251.71) by sv1.eng.oar.net with SMTP; 21 Oct 2003 17:12:22 -0000 Received: (qmail 25628 invoked by uid 4454); 21 Oct 2003 17:12:22 -0000 Date: Tue, 21 Oct 2003 13:12:22 -0400 From: Mark Fullmer To: Randy Bush Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] default transport !!! Message-ID: <20031021131222.A25535@net.ohio-state.edu> References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> <20031020112713.A15682@net.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from randy@psg.com on Mon, Oct 20, 2003 at 01:24:30PM -0500 Precedence: bulk Sender: majordomo listserver Moving forward with TCP and SCTP/PR-SCTP in the ID will allow the decision process for which one gets the "mandatory" tag to have some input from running code. I just don't think this is worth arguing about right now because there are no IPFIX implementations. mark On Mon, Oct 20, 2003 at 01:24:30PM -0500, Randy Bush wrote: > > How about if we skip the mandatory and optional section for now and > > just specify TCP and SCTP. > > the goal is for end users to be able to plug together prodcuts > from different vendors and have them interoperate. without a > transport being known to be available, i.e., mandatory to > implement, please explain how this will work? > > randy > > > -- > 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 Tue Oct 21 14:20:28 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 OAA29009 for ; Tue, 21 Oct 2003 14:20:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC0oI-0003V5-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 13:00:46 -0500 Received: from mailhub.lawrence.edu ([143.44.65.14] helo=lawrence.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC0oH-0003Uw-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 13:00:45 -0500 Received: from [143.44.97.19] (HELO lawrence.edu) by lawrence.edu (CommuniGate Pro SMTP 4.0.6) with ESMTP id 1845578; Tue, 21 Oct 2003 13:36:06 -0500 Message-ID: <3F95744D.2080202@lawrence.edu> Date: Tue, 21 Oct 2003 13:00:45 -0500 From: Robert Lowe Organization: Lawrence University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Fullmer CC: Randy Bush , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] default transport !!! References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> <20031020112713.A15682@net.ohio-state.edu> <20031021131222.A25535@net.ohio-state.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Mark Fullmer wrote: > Moving forward with TCP and SCTP/PR-SCTP in the ID will allow > the decision process for which one gets the "mandatory" tag to > have some input from running code. > > I just don't think this is worth arguing about right now because > there are no IPFIX implementations. And who will write one if something as basic as the default transport hasn't been decided? What's the use of having a standard without a standard? What good is it if I purchase a router from vendor X, a probe from vendor Y, and a collector from vendor Z, and I can't make them work together? Avoiding a hard decision won't help anything. -Robert > On Mon, Oct 20, 2003 at 01:24:30PM -0500, Randy Bush wrote: > >>>How about if we skip the mandatory and optional section for now and >>>just specify TCP and SCTP. >> >>the goal is for end users to be able to plug together prodcuts >>from different vendors and have them interoperate. without a >>transport being known to be available, i.e., mandatory to >>implement, please explain how this will work? >> >>randy >> >> >>-- >>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 Tue Oct 21 14:51: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 OAA00223 for ; Tue, 21 Oct 2003 14:51:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC1Fd-0004GH-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 13:29:01 -0500 Received: from sv1.eng.oar.net ([192.148.251.86]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1AC1Fc-0004GC-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 13:29:00 -0500 Received: (qmail 65078 invoked from network); 21 Oct 2003 18:28:57 -0000 Received: from dev1.eng.oar.net (192.148.251.71) by sv1.eng.oar.net with SMTP; 21 Oct 2003 18:28:57 -0000 Received: (qmail 26181 invoked by uid 4454); 21 Oct 2003 18:28:57 -0000 Date: Tue, 21 Oct 2003 14:28:57 -0400 From: Mark Fullmer To: Robert Lowe Cc: Randy Bush , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] default transport !!! Message-ID: <20031021142857.A26130@net.ohio-state.edu> References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> <20031020112713.A15682@net.ohio-state.edu> <20031021131222.A25535@net.ohio-state.edu> <3F95744D.2080202@lawrence.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3F95744D.2080202@lawrence.edu>; from Robert.H.Lowe@lawrence.edu on Tue, Oct 21, 2003 at 01:00:45PM -0500 Precedence: bulk Sender: majordomo listserver I'm not advocating avoiding the decision, just letting this rest for a little while and moving the ID ahead with TCP and SCTP defined. mark On Tue, Oct 21, 2003 at 01:00:45PM -0500, Robert Lowe wrote: > > > Mark Fullmer wrote: > > Moving forward with TCP and SCTP/PR-SCTP in the ID will allow > > the decision process for which one gets the "mandatory" tag to > > have some input from running code. > > > > I just don't think this is worth arguing about right now because > > there are no IPFIX implementations. > > And who will write one if something as basic as the default transport > hasn't been decided? What's the use of having a standard without a > standard? What good is it if I purchase a router from vendor X, a > probe from vendor Y, and a collector from vendor Z, and I can't make > them work together? Avoiding a hard decision won't help anything. > > -Robert > > > On Mon, Oct 20, 2003 at 01:24:30PM -0500, Randy Bush wrote: > > > >>>How about if we skip the mandatory and optional section for now and > >>>just specify TCP and SCTP. > >> > >>the goal is for end users to be able to plug together prodcuts > >>from different vendors and have them interoperate. without a > >>transport being known to be available, i.e., mandatory to > >>implement, please explain how this will work? > >> > >>randy > >> > >> > >>-- > >>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 Tue Oct 21 18:07:31 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 SAA13637 for ; Tue, 21 Oct 2003 18:07:30 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC4Wh-0001rO-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 16:58:51 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC4Wg-0001rH-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 16:58:50 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC4Wd-000DLb-4r for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 21:58:47 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC4Wc-0008EB-Gq for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 16:58:46 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Oct 2003 16:58:46 -0500 To: ipfix wg Subject: [ipfix] draft-claise-netflow-9-06.txt Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit does the wg object to publication of draft-claise-netflow-9-06.txt as an informational rfc? randy -- 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 Oct 21 18:31:40 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 SAA15676 for ; Tue, 21 Oct 2003 18:31:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC4sP-0002KK-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 17:21:17 -0500 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC4sO-0002KE-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 17:21:16 -0500 Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1AC4sO-0006oi-00; Tue, 21 Oct 2003 18:21:16 -0400 Reply-To: From: "Carter Bullard" To: "'Mark Fullmer'" , "'Robert Lowe'" Cc: "'Randy Bush'" , Subject: RE: [ipfix] default transport !!! Date: Tue, 21 Oct 2003 18:21:13 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6D5@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE918@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Mark, Since Netflow has been identified as the basic starting point for IPFIX, it is not true that there are no IPFIX implementations. There are existing systems that transport Netflow records and/or its derivatives over UDP or TCP, so, it seems pretty clear to me that any requirements for implementations leads one to choose TCP, since UDP doesn't appear to be on the list this week. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Mark Fullmer > Sent: Tuesday, October 21, 2003 2:29 PM > To: Robert Lowe > Cc: Randy Bush; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] default transport !!! > > > I'm not advocating avoiding the decision, just letting this rest > for a little while and moving the ID ahead with TCP and SCTP > defined. > > mark > > On Tue, Oct 21, 2003 at 01:00:45PM -0500, Robert Lowe wrote: > > > > > > Mark Fullmer wrote: > > > Moving forward with TCP and SCTP/PR-SCTP in the ID will allow > > > the decision process for which one gets the "mandatory" tag to > > > have some input from running code. > > > > > > I just don't think this is worth arguing about right now because > > > there are no IPFIX implementations. > > > > And who will write one if something as basic as the default > transport > > hasn't been decided? What's the use of having a standard without a > > standard? What good is it if I purchase a router from vendor X, a > > probe from vendor Y, and a collector from vendor Z, and I can't make > > them work together? Avoiding a hard decision won't help anything. > > > > -Robert > > > > > On Mon, Oct 20, 2003 at 01:24:30PM -0500, Randy Bush wrote: > > > > > >>>How about if we skip the mandatory and optional section > for now and > > >>>just specify TCP and SCTP. > > >> > > >>the goal is for end users to be able to plug together prodcuts > > >>from different vendors and have them interoperate. without a > > >>transport being known to be available, i.e., mandatory to > > >>implement, please explain how this will work? > > >> > > >>randy > > >> > > >> > > >>-- > > >>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 Tue Oct 21 20:17: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 UAA20940 for ; Tue, 21 Oct 2003 20:17:44 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC6Xd-0004xk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 19:07:57 -0500 Received: from [130.216.191.4] (helo=mailhost2.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC6Xb-0004xd-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 19:07:55 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h9M07mD6013980; Wed, 22 Oct 2003 13:07:48 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 76AF133EEC; Wed, 22 Oct 2003 13:02:46 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21979-17; Wed, 22 Oct 2003 13:02:46 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5DA7433EB5; Wed, 22 Oct 2003 13:02:46 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h9M07ln01469; Wed, 22 Oct 2003 13:07:47 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Wed, 22 Oct 2003 13:07:47 +1300 Message-ID: <1066781267.81a7762578c7f@hotlava.auckland.ac.nz> Date: Wed, 22 Oct 2003 13:07:47 +1300 From: Nevil Brownlee To: Mark Fullmer Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: default transport ! and other issues 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 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Mark: > I'm not advocating avoiding the decision, just letting this rest > for a little while and moving the ID ahead with TCP and SCTP > defined. As you said, sooner or later we (IPFIX WG) have to make a choice on this. But the draft deadline for Minneapolis is now very close, let's get the next rev of the drafts done, and (hopefully) some of the other issues resolved. We'll get back to the 'selecting a default transport' issue in the week or two before the meeting! Speaking of other issues: IM-1: Counters vs Integers Consensus seems to be MUST for integers, MAY for counters (counters can be useful, but they require collectors to keep lots of state, and to know the counter size so as to detect counter wrap) General-2: Variable-size objects No clear consensus. From items on the list, I haven't seen anything better than 'Info Model defines size of all objects, integer size in IPFIX datagrams is specified in the template for any particular (set of) flows.' That seems workable. However, does anyone have opinions on what objects actually need variable-length objects? And how should they be be encoded / appear in templates? General-3: Timestamps Consensus seems to be timestamps UTC-based (rather than uptime-based). Microseconds precision. No comment on actual format. I still like NTP-style (32.32 binary seconds) [Nevil's own opinion]. We need some discussion on this! At this stage, lets have some positive contribution to help our draft editors get their next revs in on time! 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 Tue Oct 21 20:19:13 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 UAA20985 for ; Tue, 21 Oct 2003 20:19:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC6WM-0004wv-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 19:06:38 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC6WL-0004wo-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 19:06:37 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h9M06YD6013529 for ; Wed, 22 Oct 2003 13:06:35 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 227FC33F2B for ; Wed, 22 Oct 2003 13:01:33 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22262-01 for ; Wed, 22 Oct 2003 13:01:33 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EE20433F2A for ; Wed, 22 Oct 2003 13:01:32 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h9M06YD01457 for ipfix@net.doit.wisc.edu; Wed, 22 Oct 2003 13:06:34 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Wed, 22 Oct 2003 13:06:34 +1300 Message-ID: <1066781194.93801a9a11bd0@hotlava.auckland.ac.nz> Date: Wed, 22 Oct 2003 13:06:34 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Congestion management MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_7b47e91f909a1ea284b790" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver This message is in MIME format. --=_7b47e91f909a1ea284b790 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit Forwarded message from Jon Peterson ...................... Carter, all, > Well, when you have the other Transport WG AD co-authoring > a draft that uses RTP/UDP to transport SMPTE video > at 1.485 Gbps with the intent that it be used over > "the Big-I", and the IESG approves it in 2003 (RFC 3497), > it is very difficult for me to accept the notion that > the IESG has a mandatory requirement that new IP > applications must use congestion friendly transport. To start with (RFC3497): Since congestion control is not possible for SMPTE 292M over RTP flows, use of the payload SHOULD be narrowly limited to suitably connected network endpoints, or to networks where QoS guarantees are available. One could argue that this should have been a MUST, but the message is clear - this RTP profile is intended for use in constrained (non-public-Internet) environments. This is not intended to be used over "the Big-I", as you state above. Okay? Secondly, no, there is no absolute IESG requirement that every new Internet protocol MUST NOT use UDP. That would be a self-defeating policy - clearly that are places where UDP can usefully be employed today. This sort of decision needs to be made on a case-by-case basis. It was made when the IPFIX charter was approved by the IESG. For RTP, a different decision was made. Why? Because things like HDTV streaming video transmission have certain requirements and constraints that make RTP an appropriate underlying protocol. "Current" video information should not be retransmitted if it is lost in network transit - by the time lost packets could be detected and retransmitted, they would no longer be current, and the receiver would ultimately rather get the latest information than stale data from three seconds ago. This is why TCP is unsuitable for real-time protocol applications like RFC3497 - reliability is actually bad for HDTV. > Unless of course RTP/UDP is considered by the IESG to > be congestion friendly. (I didn't think RTP was friendly, > just aware, so I possibly erred when I suggested the > IESG was only concerned about awareness). You're right - RTP/UDP is not considered "congestion friendly". Though over the long term, we intend that RTP will run over DCCP rather than UDP, which will provide the necessary congestion control properties to applications like streaming HDTV without incurring any of the undesired behavior of TCP. It's not at all clear to me that IPFIX protocols would actually be broken if they ran over TCP or SCTP. On the contrary, the IPFIX applicability document singles out gathering accounting information as one use of IPFIX data - that strikes me as an environment in which reliability is likely to be important. It also seems that IPFIX protocols are intended for use on "the Big-I", unlike RFC3497. > If an IESG mandatory requirement for congestion friendly > transport actually existed and RTP/UDP wasn't a congestion > friendly transport, the Transport WG AD that co-authored > the draft surely would have known there was a problem, but > of course if she missed the meeting, the other Transport > WG AD would have reminded her, the chair of the WG and > possibly the authors of the draft of the problem. Of > course if somehow these mechanisms failed, the draft > surely would not have been approved and promoted to Standards > Track RFC by the IESG itself. Seems like a pretty big > booo-booo for so many checks and balances to have failed on > an IP application that runs at > > 1.485 GIGABITS per second > > minimum. Obviously, RTP/UDP is congestion friendly, but > given the possibility that it is not, then I'm sure that > the IESG has begun the process to retract the RFC, now > that this potential violation of the IESG mandatory > congestion friendly transport requirement has been > identified. > Hopefully the misunderstandings that motivate this argument are obvious from the above. > I don't know, maybe there isn't really a requirement. The requirement that I see is in IPFIX's charter, which was created with the oversight of the IESG, and which states: The protocol must run over an IETF approved congestion-aware transport protocol such as TCP or SCTP. It is likely that the IESG will hold this working group to that, yes. Jon Peterson NeuStar, Inc. (Transport Co-AD) > Carter ----- End forwarded message ----- ----------------------------------------------------------------------- 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/ --=_7b47e91f909a1ea284b790 Content-Type: message/rfc822 Content-Description: Re: [ipfix] Congestion management MIME-Version: 1.0 Message-ID: From: "Peterson, Jon" To: "'ipfix@net.doit.wisc.edu'" Subject: Re: [ipfix] Congestion management Date: Sun, 19 Oct 2003 20:21:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Carter, all, > Well, when you have the other Transport WG AD co-authoring > a draft that uses RTP/UDP to transport SMPTE video > at 1.485 Gbps with the intent that it be used over > "the Big-I", and the IESG approves it in 2003 (RFC 3497), > it is very difficult for me to accept the notion that > the IESG has a mandatory requirement that new IP > applications must use congestion friendly transport. To start with (RFC3497): Since congestion control is not possible for SMPTE 292M over RTP flows, use of the payload SHOULD be narrowly limited to suitably connected network endpoints, or to networks where QoS guarantees are available. One could argue that this should have been a MUST, but the message is clear - this RTP profile is intended for use in constrained (non-public-Internet) environments. This is not intended to be used over "the Big-I", as you state above. Okay? Secondly, no, there is no absolute IESG requirement that every new Internet protocol MUST NOT use UDP. That would be a self-defeating policy - clearly that are places where UDP can usefully be employed today. This sort of decision needs to be made on a case-by-case basis. It was made when the IPFIX charter was approved by the IESG. For RTP, a different decision was made. Why? Because things like HDTV streaming video transmission have certain requirements and constraints that make RTP an appropriate underlying protocol. "Current" video information should not be retransmitted if it is lost in network transit - by the time lost packets could be detected and retransmitted, they would no longer be current, and the receiver would ultimately rather get the latest information than stale data from three seconds ago. This is why TCP is unsuitable for real-time protocol applications like RFC3497 - reliability is actually bad for HDTV. > Unless of course RTP/UDP is considered by the IESG to > be congestion friendly. (I didn't think RTP was friendly, > just aware, so I possibly erred when I suggested the > IESG was only concerned about awareness). You're right - RTP/UDP is not considered "congestion friendly". Though over the long term, we intend that RTP will run over DCCP rather than UDP, which will provide the necessary congestion control properties to applications like streaming HDTV without incurring any of the undesired behavior of TCP. It's not at all clear to me that IPFIX protocols would actually be broken if they ran over TCP or SCTP. On the contrary, the IPFIX applicability document singles out gathering accounting information as one use of IPFIX data - that strikes me as an environment in which reliability is likely to be important. It also seems that IPFIX protocols are intended for use on "the Big-I", unlike RFC3497. > If an IESG mandatory requirement for congestion friendly > transport actually existed and RTP/UDP wasn't a congestion > friendly transport, the Transport WG AD that co-authored > the draft surely would have known there was a problem, but > of course if she missed the meeting, the other Transport > WG AD would have reminded her, the chair of the WG and > possibly the authors of the draft of the problem. Of > course if somehow these mechanisms failed, the draft > surely would not have been approved and promoted to Standards > Track RFC by the IESG itself. Seems like a pretty big > booo-booo for so many checks and balances to have failed on > an IP application that runs at > > 1.485 GIGABITS per second > > minimum. Obviously, RTP/UDP is congestion friendly, but > given the possibility that it is not, then I'm sure that > the IESG has begun the process to retract the RFC, now > that this potential violation of the IESG mandatory > congestion friendly transport requirement has been > identified. > Hopefully the misunderstandings that motivate this argument are obvious from the above. > I don't know, maybe there isn't really a requirement. The requirement that I see is in IPFIX's charter, which was created with the oversight of the IESG, and which states: The protocol must run over an IETF approved congestion-aware transport protocol such as TCP or SCTP. It is likely that the IESG will hold this working group to that, yes. Jon Peterson NeuStar, Inc. (Transport Co-AD) > Carter --=_7b47e91f909a1ea284b790-- -- 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 Oct 21 21:27: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 VAA22639 for ; Tue, 21 Oct 2003 21:27:11 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC7bi-0006VW-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 20:16:14 -0500 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC7bh-0006VR-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 20:16:13 -0500 Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1AC7bg-0000Z4-00; Tue, 21 Oct 2003 21:16:12 -0400 Reply-To: From: "Carter Bullard" To: "'Nevil Brownlee'" , Subject: RE: [ipfix] Re: Congestion management Date: Tue, 21 Oct 2003 21:16:09 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6D7@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE952@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Nevil, The second paragraph in the introduction of RFC 3497 states: The use of a dedicated serial interconnect is appropriate in a studio environment, but it is desirable to leverage the widespread availability of high bandwidth IP connectivity to allow efficient wide area delivery of SMPTE 292M content. Accordingly, this memo defines an RTP payload format for SMPTE 292M format video. While they do indicate throughout the RFC that this strategy is not congestion controlled, the above sentence describing the intent is very clear. They state unambiguously, in paragraph 3, that if you use this in public networks, there should be resource reservation and enhanced quality of service. Interesting that the RFC doesn't mention DCCP as a remedy for the lack of congestion control. Must not have been heavy on the minds of the Transport AD's or the IESG at the time the RFC was written. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > Sent: Tuesday, October 21, 2003 8:07 PM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] Re: Congestion management > > > > > Forwarded message from Jon Peterson ...................... > > Carter, all, > > > Well, when you have the other Transport WG AD co-authoring > > a draft that uses RTP/UDP to transport SMPTE video > > at 1.485 Gbps with the intent that it be used over > > "the Big-I", and the IESG approves it in 2003 (RFC 3497), > > it is very difficult for me to accept the notion that > > the IESG has a mandatory requirement that new IP > > applications must use congestion friendly transport. > > To start with (RFC3497): > > Since > congestion control is not possible for SMPTE 292M over RTP > flows, use > of the payload SHOULD be narrowly limited to suitably connected > network endpoints, or to networks where QoS guarantees are > available. > > One could argue that this should have been a MUST, but the > message is clear > - this RTP profile is intended for use in constrained > (non-public-Internet) > environments. This is not intended to be used over "the > Big-I", as you state > above. Okay? > > Secondly, no, there is no absolute IESG requirement that > every new Internet > protocol MUST NOT use UDP. That would be a self-defeating > policy - clearly > that are places where UDP can usefully be employed today. This sort of > decision needs to be made on a case-by-case basis. It was > made when the > IPFIX charter was approved by the IESG. For RTP, a different > decision was > made. > > Why? Because things like HDTV streaming video transmission > have certain > requirements and constraints that make RTP an appropriate underlying > protocol. "Current" video information should not be > retransmitted if it is > lost in network transit - by the time lost packets could be > detected and > retransmitted, they would no longer be current, and the receiver would > ultimately rather get the latest information than stale data > from three > seconds ago. This is why TCP is unsuitable for real-time protocol > applications like RFC3497 - reliability is actually bad for HDTV. > > > Unless of course RTP/UDP is considered by the IESG to > > be congestion friendly. (I didn't think RTP was friendly, > > just aware, so I possibly erred when I suggested the > > IESG was only concerned about awareness). > > You're right - RTP/UDP is not considered "congestion > friendly". Though over > the long term, we intend that RTP will run over DCCP rather > than UDP, which > will provide the necessary congestion control properties to > applications > like streaming HDTV without incurring any of the undesired > behavior of TCP. > > It's not at all clear to me that IPFIX protocols would > actually be broken if > they ran over TCP or SCTP. On the contrary, the IPFIX > applicability document > singles out gathering accounting information as one use of > IPFIX data - that > strikes me as an environment in which reliability is likely > to be important. > It also seems that IPFIX protocols are intended for use on > "the Big-I", > unlike RFC3497. > > > If an IESG mandatory requirement for congestion friendly > > transport actually existed and RTP/UDP wasn't a congestion > > friendly transport, the Transport WG AD that co-authored > > the draft surely would have known there was a problem, but > > of course if she missed the meeting, the other Transport > > WG AD would have reminded her, the chair of the WG and > > possibly the authors of the draft of the problem. Of > > course if somehow these mechanisms failed, the draft > > surely would not have been approved and promoted to Standards > > Track RFC by the IESG itself. Seems like a pretty big > > booo-booo for so many checks and balances to have failed on > > an IP application that runs at > > > > 1.485 GIGABITS per second > > > > minimum. Obviously, RTP/UDP is congestion friendly, but > > given the possibility that it is not, then I'm sure that > > the IESG has begun the process to retract the RFC, now > > that this potential violation of the IESG mandatory > > congestion friendly transport requirement has been > > identified. > > > > Hopefully the misunderstandings that motivate this argument > are obvious from > the above. > > > I don't know, maybe there isn't really a requirement. > > The requirement that I see is in IPFIX's charter, which was > created with the > oversight of the IESG, and which states: > > The protocol must run over an IETF approved > congestion-aware transport > protocol such as TCP or SCTP. > > It is likely that the IESG will hold this working group to that, yes. > > Jon Peterson > NeuStar, Inc. > (Transport Co-AD) > > > Carter > > > ----- End forwarded message ----- > > > -------------------------------------------------------------- > --------- > 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 Tue Oct 21 22:15:08 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 WAA23805 for ; Tue, 21 Oct 2003 22:15:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC8OE-00003E-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 21:06:22 -0500 Received: from dog.tcb.net ([64.78.150.133]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC8OD-000039-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 21:06:21 -0500 Received: from tcb.net (unknown [205.168.100.9]) by dog.tcb.net (Postfix) with ESMTP id 63D0F20299; Tue, 21 Oct 2003 20:06:20 -0600 (MDT) Date: Tue, 21 Oct 2003 20:06:19 -0600 Subject: Re: [ipfix] draft-claise-netflow-9-06.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipfix wg To: Randy Bush From: Danny McPherson In-Reply-To: Message-Id: <53C57EAA-0434-11D8-877C-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit On Tuesday, October 21, 2003, at 03:58 PM, Randy Bush wrote: > does the wg object to publication of draft-claise-netflow-9-06.txt > as an informational rfc? I'd like to see it published... -danny -- 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 Oct 22 00:00: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 AAA26525 for ; Wed, 22 Oct 2003 00:00:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC9sm-0002Bp-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 22:42:00 -0500 Received: from psg.com ([147.28.0.62]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC9sl-0002Bf-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 22:41:59 -0500 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC9sk-0007tB-Sr; Wed, 22 Oct 2003 03:41:58 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC9sk-0008Rb-8N; Tue, 21 Oct 2003 22:41:58 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Oct 2003 22:41:57 -0500 To: Danny McPherson Cc: ipfix wg Subject: Re: [ipfix] draft-claise-netflow-9-06.txt References: <53C57EAA-0434-11D8-877C-000393D54EA6@tcb.net> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit >> does the wg object to publication of draft-claise-netflow-9-06.txt >> as an informational rfc? > I'd like to see it published... to be clear o i do not expect objection, after all, it is just a vendor publishing the spec for their protocol as info o but in cases of info that come in via rfc-ed, we do 'end run' checks to be sure it is not damaging to the work or process of a wg. randy -- 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 Oct 22 00:09:47 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 AAA26744 for ; Wed, 22 Oct 2003 00:09:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AC9wT-0002EJ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Oct 2003 22:45:49 -0500 Received: from dog.tcb.net ([64.78.150.133]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AC9wS-0002ED-00 for ipfix@net.doit.wisc.edu; Tue, 21 Oct 2003 22:45:48 -0500 Received: from tcb.net (unknown [151.118.13.197]) by dog.tcb.net (Postfix) with ESMTP id A48F320299; Tue, 21 Oct 2003 21:45:47 -0600 (MDT) Date: Tue, 21 Oct 2003 21:45:46 -0600 Subject: Re: [ipfix] draft-claise-netflow-9-06.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ipfix wg To: Randy Bush From: Danny McPherson In-Reply-To: Message-Id: <3840A15A-0442-11D8-877C-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit On Tuesday, October 21, 2003, at 09:41 PM, Randy Bush wrote: > > to be clear > o i do not expect objection, after all, it is just a vendor > publishing the spec for their protocol as info > o but in cases of info that come in via rfc-ed, we do 'end > run' checks to be sure it is not damaging to the work or > process of a wg. I realize that. I'd like to see it published. -danny -- 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 Oct 22 16:13: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 QAA25820 for ; Wed, 22 Oct 2003 16:13:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ACP2u-0004MK-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Oct 2003 14:53:28 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ACP2t-0004MC-00 for ipfix@net.doit.wisc.edu; Wed, 22 Oct 2003 14:53:27 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2003 12:54:25 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9MJrOQY015418; Wed, 22 Oct 2003 12:53:24 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK54257; Wed, 22 Oct 2003 12:53:23 -0700 (PDT) Message-ID: <3F96E032.5000306@cisco.com> Date: Wed, 22 Oct 2003 14:53:22 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Lowe CC: Mark Fullmer , Randy Bush , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] default transport !!! References: <1D3D2C371FCBD947A7897FABBD3533A5029603AE@xsun01.ptp.hp.com> <1066184325.fd2a6b4f52d2e@hotlava.auckland.ac.nz> <20031020112713.A15682@net.ohio-state.edu> <20031021131222.A25535@net.ohio-state.edu> <3F95744D.2080202@lawrence.edu> In-Reply-To: <3F95744D.2080202@lawrence.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Robert: a quick little comment ... with code even :> Robert Lowe wrote: > > > Mark Fullmer wrote: > >> Moving forward with TCP and SCTP/PR-SCTP in the ID will allow >> the decision process for which one gets the "mandatory" tag to >> have some input from running code. >> >> I just don't think this is worth arguing about right now because >> there are no IPFIX implementations. > > > And who will write one if something as basic as the default transport > hasn't been decided? What's the use of having a standard without a > standard? What good is it if I purchase a router from vendor X, a > probe from vendor Y, and a collector from vendor Z, and I can't make > them work together? Avoiding a hard decision won't help anything. > As far as writting an actual collector goes aka TCP or SCTP(SCTP/PR) there is really only one thing different: sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); or sd = socket(AF_INET,SOCK_STREAM, IPPROTO_SCTP); thats it... from a collector standpoint. Since the collector is only collecting/reading.. and will not be using any of the advanced features of SCTP... it really is a one line change. So I would hope a one line change would not stop a vendor.. I can point you to several web sites that have things like apache mozilla ftp and the ssh suite All that have made a one line change to do SCTP... well.. I guess I am lying on mozilla it was actually 2 lines of code... Now that being said, none of the above took advantage of any advance features... but as I said, since the collector is not the source of the data it will not effect how it collects if it is using TCP or SCTP.. R > -Robert > >> On Mon, Oct 20, 2003 at 01:24:30PM -0500, Randy Bush wrote: >> >>>> How about if we skip the mandatory and optional section for now and >>>> just specify TCP and SCTP. >>> >>> >>> the goal is for end users to be able to plug together prodcuts >>> from different vendors and have them interoperate. without a >>> transport being known to be available, i.e., mandatory to >>> implement, please explain how this will work? >>> >>> randy >>> >>> >>> -- >>> 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/ > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- 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 Oct 22 17:46:53 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 RAA29271 for ; Wed, 22 Oct 2003 17:46:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ACQdd-000717-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Oct 2003 16:35:29 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ACQdb-00070z-00 for ipfix@net.doit.wisc.edu; Wed, 22 Oct 2003 16:35:28 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h9MLZOD6012391 for ; Thu, 23 Oct 2003 10:35:24 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0440533EEF for ; Thu, 23 Oct 2003 10:30:06 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16809-09 for ; Thu, 23 Oct 2003 10:30:00 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CAB2A33F3F for ; Thu, 23 Oct 2003 10:30:00 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id h9MLYf719870 for ipfix@net.doit.wisc.edu; Thu, 23 Oct 2003 10:34:41 +1300 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by motoko.itss.auckland.ac.nz (Horde) with HTTP for ; Thu, 23 Oct 2003 10:34:41 +1300 Message-ID: <1066858481.8a615a52f88aa@motoko.itss.auckland.ac.nz> Date: Thu, 23 Oct 2003 10:34:41 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: FW: [ipfix] Re: Congestion management 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 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit ----- Forwarded message from jon.peterson@neustar.biz ----- Date: Wed, 22 Oct 2003 16:42:24 -0400 From: "Peterson, Jon" Reply-To: "Peterson, Jon" Subject: FW: [ipfix] Re: Congestion management To: "'n.brownlee@auckland.ac.nz'" Pls fwd to ipfix. Thanks again! - J ---- Carter, The text that you cite here is non-normative (unlike the text that I cited) and it is contextualized by the following paragraph, which says that the "use of this payload format should be tightly controlled and limited to private networks". It also mentions resource reservation, which I would say essentially entails a virtual, tightly-controlled network, yes. Your contention that this document encourages the use of this 1.5G payload format on the "Big-I" Internet simply is not substantiated by the document. In any event, I don't think any of this argues that the IESG will not hold IPFIX to its charter. To your second point, while it might seem interesting that RFC3497 doesn't mention DCCP, I'd note that the string 'UDP' doesn't appear in the RFC either. This RFC merely defines a payload type for RTP, which will work over DCCP or UDP as necessary. Jon Peterson NeuStar, Inc. ------- start of forwarded message ------- From: "Carter Bullard" To: "'Nevil Brownlee'" , Subject: RE: [ipfix] Re: Congestion management Date: Tue, 21 Oct 2003 21:16:09 -0400 Hey Nevil, The second paragraph in the introduction of RFC 3497 states: The use of a dedicated serial interconnect is appropriate in a studio environment, but it is desirable to leverage the widespread availability of high bandwidth IP connectivity to allow efficient wide area delivery of SMPTE 292M content. Accordingly, this memo defines an RTP payload format for SMPTE 292M format video. While they do indicate throughout the RFC that this strategy is not congestion controlled, the above sentence describing the intent is very clear. They state unambiguously, in paragraph 3, that if you use this in public networks, there should be resource reservation and enhanced quality of service. Interesting that the RFC doesn't mention DCCP as a remedy for the lack of congestion control. Must not have been heavy on the minds of the Transport AD's or the IESG at the time the RFC was written. Carter ----- End forwarded message ----- ----------------------------------------------------------------------- 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 Oct 22 20:50:03 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 UAA11417 for ; Wed, 22 Oct 2003 20:50:03 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ACTRi-0003jl-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Oct 2003 19:35:22 -0500 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ACTRh-0003jg-00 for ipfix@net.doit.wisc.edu; Wed, 22 Oct 2003 19:35:21 -0500 Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1ACTRg-0005bE-00; Wed, 22 Oct 2003 20:35:20 -0400 Reply-To: From: "Carter Bullard" To: "'Nevil Brownlee'" , Cc: Subject: RE: [ipfix] Re: Congestion management Date: Wed, 22 Oct 2003 20:35:16 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6DC@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661F61D5@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Jon, The text I provided was the complete 2nd paragraph from the introduction, that states the motivation for the RFC. It doesn't get any more "normative" than that. Your snippet of text came from section 9. "Security Considerations" discussing denial of service potential. Here is the complete paragraph that contains your "normative" text: The bandwidth of this payload format is high enough (1.485 Gbps without the RTP overhead) to cause potential for denial-of-service if transmitted onto most currently available Internet paths. Since congestion control is not possible for SMPTE 292M over RTP flows, use of the payload SHOULD be narrowly limited to suitably connected network endpoints, or to networks where QoS guarantees are available. The "if transmitted onto most currently available Internet paths" seems to be an important phrase. It is obvious that the authors expect this protocol to run on "currently available Internet paths", or they would not provide guidance for this condition. The point is, and you have confirmed it now twice, that there is no IESG moratorium restricting WG's from using transports that are not congestion aware. This is unfortunate, as the IPFIX charter was developed with this basic myth as its foundation. The result will be that the IPFIX protocol will not be designed to meet the needs of the existing IP flow record community, and I believe that it is safe to say that no existing commercial router will be able to support the default IPFIX protocol. I was hoping for a better outcome. Carter > > ---- > > Carter, > > The text that you cite here is non-normative (unlike the text > that I cited) > and it is contextualized by the following paragraph, which > says that the > "use of this payload format should be tightly controlled and > limited to > private networks". It also mentions resource reservation, > which I would say > essentially entails a virtual, tightly-controlled network, yes. Your > contention that this document encourages the use of this 1.5G > payload format > on the "Big-I" Internet simply is not substantiated by the document. > > In any event, I don't think any of this argues that the IESG > will not hold > IPFIX to its charter. > > To your second point, while it might seem interesting that > RFC3497 doesn't > mention DCCP, I'd note that the string 'UDP' doesn't appear in the RFC > either. This RFC merely defines a payload type for RTP, which > will work over > DCCP or UDP as necessary. > > Jon Peterson > NeuStar, Inc. > > ------- start of forwarded message ------- > From: "Carter Bullard" > To: "'Nevil Brownlee'" , > > Subject: RE: [ipfix] Re: Congestion management > Date: Tue, 21 Oct 2003 21:16:09 -0400 > > Hey Nevil, > The second paragraph in the introduction of RFC 3497 states: > > The use of a dedicated serial interconnect is appropriate in a > studio environment, but it is desirable to leverage the widespread > availability of high bandwidth IP connectivity to allow efficient > wide area delivery of SMPTE 292M content. Accordingly, this memo > defines an RTP payload format for SMPTE 292M format video. > > While they do indicate throughout the RFC that this strategy is > not congestion controlled, the above sentence describing the > intent is very clear. They state unambiguously, in paragraph 3, > that if you use this in public networks, there should be resource > reservation and enhanced quality of service. Interesting > that the RFC doesn't mention DCCP as a remedy for the lack of > congestion control. Must not have been heavy on the minds of > the Transport AD's or the IESG at the time the RFC was written. > > Carter > > > ----- End forwarded message ----- > > > -------------------------------------------------------------- > --------- > 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/ > -- 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 Oct 22 21:03: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 VAA11851 for ; Wed, 22 Oct 2003 21:03:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ACTl0-0004Dn-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Oct 2003 19:55:18 -0500 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ACTkz-0004Dg-00 for ipfix@net.doit.wisc.edu; Wed, 22 Oct 2003 19:55:17 -0500 Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1ACTkz-0002FT-00; Wed, 22 Oct 2003 20:55:17 -0400 Reply-To: From: "Carter Bullard" To: "'Nevil Brownlee'" , Cc: Subject: RE: [ipfix] Re: Congestion management Date: Wed, 22 Oct 2003 20:55:13 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6DD@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A6DC@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Jon, > > > > To your second point, while it might seem interesting that > > RFC3497 doesn't > > mention DCCP, I'd note that the string 'UDP' doesn't appear > in the RFC > > either. This RFC merely defines a payload type for RTP, which > > will work over > > DCCP or UDP as necessary. > > I think its pretty clear that SMPTE video distribution will want to use UDP's support for multicast. That would only seem logical for distributing a 1.485 Gbps stream to multiple downstream receivers. DCCP doesn't support multicast. I was working under the impression that the "UDP" part was understood. I could be wrong, of course. Carter > > Jon Peterson > > NeuStar, Inc. > > -- 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 Oct 23 10:32: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 KAA25836 for ; Thu, 23 Oct 2003 10:32:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ACgBt-0001e9-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Oct 2003 09:11:53 -0500 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ACgBs-0001e2-00 for ipfix@net.doit.wisc.edu; Thu, 23 Oct 2003 09:11:52 -0500 Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1ACgBr-0004Ag-00; Thu, 23 Oct 2003 10:11:51 -0400 Reply-To: From: "Carter Bullard" To: "'Nevil Brownlee'" Cc: Subject: RE: [ipfix] Re: default transport ! and other issues Date: Thu, 23 Oct 2003 10:11:42 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6DE@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE953@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Nevil, > > General-2: Variable-size objects > No clear consensus. From items on the list, I haven't > seen anything > better than 'Info Model defines size of all objects, integer size > in IPFIX datagrams is specified in the template for any particular > (set of) flows.' That seems workable. > However, does anyone have opinions on what objects actually need > variable-length objects? And how should they be be > encoded / appear > in templates? I am a fan of variable length objects, say for example packet counts and byte values. I would like for the probe to be able to send an 8-bit, 16-bit or 32-bit value depending on the specific activity of a given flow, as needed. I have implemented it by defining an Argus record as a collection of data objects, where each object is a TLV. The record has a total record length, so a reader can parse the stream without any knowledge of the contents, and each data object, like the flow descriptor, the transport ids, the metrics, layer specific identifiers, are in their own TLV. I use 3, 1-byte type specifies, so I can provide enough information for the reader to figure it out, and a 1-byte length field to indicate how many long words are in the data object. This gives me enough flexibility to be able to specify a METRIC/BI-DIRECTIONAL PKT COUNT/8-BIT INT, object. The next record could have a METRIC/UNI-DIRECTIONAL PKT COUNT/32-BIT INT, or a METRIC/BI-DIRECTIONAL PKT-BYTE COUNT/ 16-BIT INT. I don't support templates, as I haven't found a need for them yet, but if I did I would declare that the probe may include a METRIC object in the record. Understood that it will have a TLV structure, since they all do, no other description is necessary, but some may want to see the largest size allowable, which would be very easy to accommodate. > > General-3: Timestamps > Consensus seems to be timestamps UTC-based (rather than > uptime-based). Microseconds precision. > No comment on actual format. I still like NTP-style (32.32 binary > seconds) [Nevil's own opinion]. We need some discussion on this! I'm not fond of 32-bits of fractional seconds in a timestamp. I would prefer that it be absolute uSeconds. The precision is simple to derive from the data, and implementation on the probe side is pretty trivial, as there is no need for floating-point operations to transport a record. Don't want to have to do floating-point in the kernel if you don't have to. And, most OS's provide absolute timestamps ('struct timeval') for system time, possibly for that reason. I have found that both are nice to have, but I use absolute uSeconds more than fractional seconds. As a result I would always need to convert. Floating point may seem convenient, but its not a good performing data type, even in modern computers. Carter > > At this stage, lets have some positive contribution to help our draft > editors get their next revs in on time! > > 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/ > -- 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 Oct 23 22: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 WAA29512 for ; Thu, 23 Oct 2003 22:17:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ACr5g-00030V-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Oct 2003 20:50:12 -0500 Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ACr5f-00030N-00 for ipfix@net.doit.wisc.edu; Thu, 23 Oct 2003 20:50:11 -0500 Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1ACr5e-0006Wu-00; Thu, 23 Oct 2003 21:50:10 -0400 Reply-To: From: "Carter Bullard" To: "'Peterson, Jon'" , "'Nevil Brownlee'" , Subject: RE: [ipfix] Re: Congestion management Date: Thu, 23 Oct 2003 21:50:04 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6DF@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661F626E@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Hey Jon, You know, RFC 2119 doesn't have the word "normative" in it anywhere. I must be missing something. Well, its clear that the discussion has come to the point where the AD declares that the IESG is in control and its heart is pure, thus bringing to a close yet another insightful technical discussion. Sorry we didn't get to discuss why the IESG thinks IPFIX MUST (evidently, the first normative keyword) have congestion control, and 1.485 Gbps SMPTE video SHOULD. Really, 1.485 Gbps minimum. The single most demanding application stream in the history of the IETF, and it SHOULD consider congestion control, but IPFIX where 95% of implementations today have directly connected collection, is a MUST. It really is a mystery. Carter > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Thursday, October 23, 2003 3:16 PM > To: 'carter@qosient.com'; 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] Re: Congestion management > > > > > > > Hey Jon, > > The text I provided was the complete 2nd paragraph > > from the introduction, that states the motivation for > > the RFC. It doesn't get any more "normative" than > > that. > > By "normative" here I refer to the use of RFC2119 keywords, > which actually > define qualia for conformance with a specification. > > [snip] > > The point is, and you have confirmed it now twice, > > that there is no IESG moratorium restricting WG's > > from using transports that are not congestion aware. > > This is unfortunate, as the IPFIX charter was developed > > with this basic myth as its foundation. > > > > Well, you seem to be under some sort of misapprehension that > the IESG has > moratoriums, or policies, or something. The IESG is a > collection of people > who hold individual positions on particular charters or > documents, not a > group that is subservient to a rigid canon of pre-established > policies. > > What I have confirmed twice is that IPFIX will be held to its > charter. If > the IPFIX group produces a protocol that does not conform to > the constraints > identified in its charter, that protocol will not pass the IESG. This > constraint was placed on IPFIX at the time of its inception > because the IESG > believed that there was a material risk in deploying such a > protocol without > congestion control. The charter does not contain this > constraint because of > a "myth" that no protocols are allowed to run over UDP - it > was because of a > reasoned decision that IPFIX in particular needed something > safer. One size > does not fit all. > > > The result will be that the IPFIX protocol will not be > > designed to meet the needs of the existing IP flow record > > community, and I believe that it is safe to say that no existing > > commercial router will be able to support the default IPFIX > > protocol. > > And that would be regrettable. Understand, though, that the IESG hears > arguments of this form all of the time, especially from > participants who > want to avoid building security into their protocols. Security and > congestion control can make a protocol more heavyweight, > sure, and it is > frequently argued that by requiring such things, we risk > irrelevance. By not > requring things like security and congestion control, we risk > releasing > low-quality protocols that can damage the networks or > implementations of our > participants. On balance, I think it's clear which risk we > should tolerate > and which we should not. > > > > > I was hoping for a better outcome. > > Sorry. > > Jon Peterson > NeuStar, Inc. > > > > > Carter > > > > > -- 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 Oct 27 23:58:14 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 XAA10011 for ; Mon, 27 Oct 2003 23:58:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AELUc-0002W6-00 for ipfix-list@mil.doit.wisc.edu; Mon, 27 Oct 2003 22:30:06 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AELUa-0002Vu-00 for ipfix@net.doit.wisc.edu; Mon, 27 Oct 2003 22:30:04 -0600 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h9S4U1Qj027959 for ; Tue, 28 Oct 2003 17:30:02 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5121C33E8A for ; Tue, 28 Oct 2003 17:29:44 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08477-10 for ; Tue, 28 Oct 2003 17:29:44 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 00D1233E6C for ; Tue, 28 Oct 2003 17:29:44 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h9S4U1w24953 for ipfix@net.doit.wisc.edu; Tue, 28 Oct 2003 17:30:01 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Tue, 28 Oct 2003 17:30:01 +1300 Message-ID: <1067315401.0fd0ced64513a@hotlava.auckland.ac.nz> Date: Tue, 28 Oct 2003 17:30:01 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Draft agenda for Minneapolis IETF 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 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit IPFIX Agenda for IETF 58, Minneapolis ------------------------------------- The IPFIX WG meeting is scheduled for Monday 9 Nov 03 at 0900 (first session Monday morning) minutes 5 1) Agenda Review 2) Requirements draft, Juergen Quittek (status as at 28 Oct 03: waiting for IESG feedback on anonymisation) 10 draft-ietf-ipfix-reqs-11.txt 3) New drafts - brief overview presentation for each, discussion of as-yet-unwritten sections and unresolved issues. The drafts are 15 * draft-ietf-ipfix-arch-02.txt 15 * draft-ietf-ipfix-info-01.txt 15 * draft-ietf-ipfix-protocol-01.txt 15 * draft-ietf-ipfix-as-01.txt 4) Short Presentations * IPFIX Vendor Specific Information Elements (dor IPFIX and PSAMP) 15 draft-bryant-ipfix-vendor-ie-00.txt 5) Discussion: IPFIX transport and Congestion Control 45 The IPFIX charter clearly says "must run over a congestion-aware transport protocol." So far we have identified SCTP and TCP as suitable transport protocols, with both being discussed in the IPFIX protocol draft. We need to select a default transport, i.e. one wich will be 'mandatory to implement.' This will be an open-mike . search for consensus discussion, be prepared to make compelling *technical* arguments. Also, maybe we should recognise that there will be situations which any chosen default may not be the 'most suitable,' i.e. vendors can implement other protocols besides the default. Note that there's no question of IPFIX being limited to any one transport protocol. 5 6) Review of WG Milestones 5 7) Anything else If you have other items you'd like to see discussed, please advise the WG chairs, by email to ipfix-chairs@net.doit.wisc.edu ----------------------------------------------------------------------- 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 Oct 29 05:27:49 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 FAA01806 for ; Wed, 29 Oct 2003 05:27:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AEn8v-0004yo-00 for ipfix-list@mil.doit.wisc.edu; Wed, 29 Oct 2003 04:01:33 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AEn8t-0004yc-00 for ipfix@net.doit.wisc.edu; Wed, 29 Oct 2003 04:01:32 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9TA1RqL079808 for ; Wed, 29 Oct 2003 11:01:27 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 58AD7DA1BC for ; Wed, 29 Oct 2003 10:25:52 +0100 (CET) Date: Wed, 29 Oct 2003 11:02:37 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] changes in IPFIX requirements from -10 to -11 Message-ID: <2147483647.1067425357@[10.1.1.171]> In-Reply-To: <200310282041.PAA24883@ietf.org> References: <200310282041.PAA24883@ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Below please find the list of changes from version -10 to version -11. Not listed is a set of 20 minor changes, most of them based on comments from Randy Presuhn, including - having two spaces after each period at the end of a sentence - fixing references - correcting grammar (commas, typos, word oder, ...) - removing "confidentiality" in overview sentences Cheers, Juergen --On 28.10.2003 15:41 Uhr -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : Requirements for IP Flow Information Export > Author(s) : J. Quittek > Filename : draft-ietf-ipfix-reqs-11.txt > Pages : 31 > Date : 2003-10-28 > > This memo defines requirements for the export of measured IP flow > information out of routers, traffic measurement probes and > middleboxes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-11.txt > ========================= IPFIX Requirements Issues ========================= ======================================================================== 15. Confidentiality from SHOULD to MUST (issue 12 revisited) ======================================================================== Problem Description: ------------------------------------------------------------------------ Requirements on the ipfix implementation - the document is long and I wonder if the working group really meant the protocol's confidentiality and anonymization features to be so optional - SHOULD confidentiality, MAY anonymization. Just for implementation. raised by Allison Mankin ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "Confidentiality of flow specific data transferred from an exporting process to a collecting process SHOULD be ensured." by "Confidentiality of flow specific data transferred from an exporting process to a collecting process MUST be ensured." change confidentality from SHOULD to MUST in appendix ======================================================================== Status: solution committed ======================================================================== ======================================================================== 16. Anonymization from MAY to MUST (issue 13 revisited) ======================================================================== Problem Description: ------------------------------------------------------------------------ Requirements on the ipfix implementation - the document is long and I wonder if the working group really meant the protocol's confidentiality and anonymization features to be so optional - SHOULD confidentiality, MAY anonymization. Just for implementation. raised by Allison Mankin ======================================================================== Suggested solution: ------------------------------------------------------------------------ After a long discussion, it was agreed to completely remove the issue of anonymization from the requirements. The main reason is that there are neither standardized anonymisation methods available, nor is there a solid knowledge base about the effectiveness of existing anonymization methods. Here is work to be done by the IETf for recommending which anonymization should be applied in which case (and having which effect). Since the goal of the IPFIX WG is targeted rather at standardizing existing technology rather than developing new technologies (confirmed several times by our AD rendy Bush), the WG identified this issue to be out of scope. In order to still document the need of anonymization, the security considerations section was extended. remove Section "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 anonymized flow data is exported, this MUST be clearly indicated to all receiving collecting processes, such that they can distinguish anonymized data from non-anonymized data." remove from Section 7.2 (configuration requirements) "5. flow anonymization This requirement only applies if the exporting process supports flow anonymization." remove confidentiality from appendix append to Section 10.1 (security considerations) "Also the privacy of users acting as sender or receiver of the measured traffic needs to be protected when they use the Internet. In many contries the right to store user-specific data (including the user's traffic profiles) is restricted by law or by regulations. In addition to encryption, this kind of privacy can also be protected by anonymizing flow records. For many traffic flow measurements, anonymized data is as useful as precise data. Therefore, it is desirable to support anonymization in IPFIX implementations. It is beyond the scope of the IPFIX working group to develop and standardize anonymization methods. However, the requirements for extensibility of the IPFIX protocol are sufficient to support anonymized flow records when appropriate methods are standardized." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 17. For distinguishing flows, consider also SCTP ======================================================================== Problem Description: ------------------------------------------------------------------------ Section 4.3 requests the meter to be able to distinguish traffic by TCP and UDP port numbers. Also SCTP should be mentioned here. raised by Steve Bellovin ======================================================================== Suggested solution: ------------------------------------------------------------------------ Section 4.3 (Steve Bellovin's request to consider SCTP) replaced "4.3. Transport Header Fields The metering process MUST be able to separate flows by the port numbers of the transport header in case of TCP or UDP being used as transport protocol. Both, source and destination port number MUST be supported for distinguishing flows, individually as well as in combination." by "4.3. Transport Header Fields The metering process MUST be able to separate flows by the port numbers of the transport header in case of TCP or UDP being used as transport protocol. The metering process SHOULD be able to separate flows by the port numbers of the transport header in case of SCTP [RFC2960]. For separation, both, source and destination port number MUST be supported for distinguishing flows, individually as well as in combination." add reference "[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 18. Dubious header compression in section 4.6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Steve Bellovin: 4.6 strikes me as dubious for compression ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "4.6. Header Compression and Encryption If header compression or encryption is used, the metering process might not be able to access all header fields. A metering process MUST meet the requirements stated in this section 4 only for packets that have the relevant header fields not compressed and not encrypted." by "4.6. Encryption If encryption is used, the metering process might not be able to access all header fields. A metering process MUST meet the requirements stated in this section 4 only for packets that have the relevant header fields not encrypted." ======================================================================== Status: solution committed ======================================================================== -- 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/