Subject: RE: [ipfix-req] unidirection vs. bidirectional flows

From: Benoit Claise <[email-masked]>
Date: Tue, 8 Jan 2002 16:56:20 +0100 (CET)

Hi Carter,
> 
> Hey Juergen,
>    You know, you have to buy special cards to get netflow
> support in a Cisco router.  I'm interested in how your
> going to make uni-directional flow record reporting cheap.

This is not correct! This function is part of the software.
I know of only device which needs a special daughter card, and I don't think this still applies.

Regards, Benoit.

> 
> Carter
> 
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 18K
> New York, New York  10022
> 
> [email-masked]
> Phone +1 212 588-9133
> Fax   +1 212 588-9134
> http://qosient.com
> 
> > -----Original Message-----
> > From: Juergen Quittek [mailto:[email-masked]] 
> > Sent: Tuesday, January 08, 2002 8:23 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [ipfix-req] unidirection vs. bidirectional flows
> > 
> > 
> > --On 08 January 2002 07:34 -0500 Carter Bullard wrote:
> > 
> > > Hey Juergen,
> > > Just a note, the majority of switches and routers
> > > today (> 90%) cannot support uni-directional flow record
> > 
> > What routers are you talking about? Isn't NetFlow available
> > for most CisCo and Juniper boxes?
> > 
> > > reporting.  However, virtually all switches and routers
> > > (> 99%) support RMON-style interface statistics, which
> > > are L1/L2 bi-directional flow metrics.
> > >
> > > I believe that adoption of a uni-directional flow model excludes 
> > > basically the entire population of legacy networking devices that 
> > > could easily report their existing bi-directional flow 
> > metrics using 
> > > IPFIX.
> > >
> > > Wouldn't this violate your fundamental constraint?
> > 
> > Not at all. No one is trying to forbid existing technologies. 
> > But this is about IPFIX requirements. I said I am not sure 
> > whether we should specify uni- or bi-directional in the 
> > requirements at all, but I am sure I do not want to have 
> > "expensive" requirements. If you explain to me how to make 
> > bi-directional flows cheap, I will find it easier considering 
> > them as a potential requirement.
> > 
> >     Juergen
> > -- 
> > Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
> > NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
> > Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
> > 
> > >
> > > Carter
> > >
> > > Carter Bullard
> > > QoSient, LLC
> > > 300 E. 56th Street, Suite 18K
> > > New York, New York  10022
> > >
> > > [email-masked]
> > > Phone +1 212 588-9133
> > > Fax   +1 212 588-9134
> > > http://qosient.com
> > >
> > >
> > >> -----Original Message-----
> > >> From: majordomo listserver [mailto:[email-masked]] On 
> > >> Behalf Of Juergen Quittek
> > >> Sent: Tuesday, January 08, 2002 6:24 AM
> > >> To: [email-masked]; 'Vamsidhar Valluri'
> > >> Cc: [email-masked]; [email-masked]
> > >> Subject: RE: [ipfix-req] unidirection vs. bidirectional flows
> > >>
> > >>
> > >> Hi Carter,
> > >>
> > >> One of the very important constraints we applied to each 
> > requirements 
> > >> so far, is that it must be possible to for routers as well as for 
> > >> probes to implement the respective requirement with reasonable 
> > >> effort.
> > >>
> > >> (If anyone finds out that one or more of the requirements 
> > appears to 
> > >> be expensive, then please speak up!)
> > >>
> > >> Facing the hardware acrchitecture of a modern router,
> > >> I consider a bi-directional flow model to be too expensive 
> > to be part 
> > >> of the requirements (and consequently also too expensive 
> > to be part 
> > >> of the general architecture on the exporter side).
> > >>
> > >> The reason is that at line interface cards you typically 
> > spent very 
> > >> different effort on treatment on incoming and outgoing 
> > packets. For 
> > >> incoming packets you do a lot of
> > >> processing: checksums, TTL processing, routing based on cached 
> > >> routing tables, ... Here you touch header fields anyway and it is 
> > >> relatively easy and relatively cheap to add metering 
> > functions. For 
> > >> outgoing packets the treatment is different. You just try 
> > to get rid 
> > >> of them as fast as possible (except from scheduling thme 
> > first). Here 
> > >> it would be rather expensive to investigate header fields again and
> > >> it might also reduce your maximum thoughput. Therefore a
> > >> device just metering incoming packets should be able to
> > >> match the requirements.
> > >>
> > >> Now, if we have a bi-directional flow model, you require such a 
> > >> device to merge all its input measurements performed at different 
> > >> line cards by looking for measured uni-directional flows 
> > belongig to 
> > >> the same bi-directinal one. This task might be done at a control 
> > >> processor, but it creates additional cost and it might 
> > slow down the 
> > >> system. I believe that merging of these measurements is a 
> > perfect job 
> > >> for an analysis application and not for a meter.
> > >>
> > >> Definitely it is nothing we should ask every meter to perform by 
> > >> making it a MUST requirement!
> > >>
> > >> Consequently, my position is that IF we add a flow model to the 
> > >> requirements, then it should be the uni-diractional one. 
> > However, I 
> > >> am not yet convinced, that we should specify the model at 
> > all in the 
> > >> requirements.
> > >>
> > >> Best wishes,
> > >>
> > >>     Juergen
> > >> --
> > >> Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
> > >> NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
> > >> Adenauerplatz 6, 69115 Heidelberg, Germany   
> > http://www.ccrle.nec.de
> > >>
> > >>
> > >> --On 07 January 2002 19:42 -0500 Carter Bullard 
> > <[email-masked]> 
> > >> wrote:
> > >>
> > >> > Hey Vamsi,
> > >> >     Hmmm, is the interface a part of the flow defintion? Not a 
> > >> > problem.  Lets look at how this may work.  Suppose there 
> > is a SRC 
> > >> > interface and a DST interface, so that a flow is simply all the 
> > >> > packets moving from SRC -> DST.  The return flow would 
> > be all the 
> > >> > packets moving from DST -> SRC.
> > >> >
> > >> >    So the flow is reported as SRC <-> DST, with the 
> > simple addition 
> > >> > of the DST -> SRC metrics.  Makes more sense than independantly 
> > >> > reporting two half-duplex flow records, which could be skewed in 
> > >> > time so badly, that the two records cannot be correlated at all.
> > >> >
> > >> >
> > >> > Carter
> > >> >
> > >> > Carter Bullard
> > >> > QoSient, LLC
> > >> > 300 E. 56th Street, Suite 18K
> > >> > New York, New York  10022
> > >> >
> > >> > [email-masked]
> > >> > Phone +1 212 588-9133
> > >> > Fax   +1 212 588-9134
> > >> > http://qosient.com
> > >> >
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Vamsidhar Valluri [mailto:[email-masked]]
> > >> >> Sent: Monday, January 07, 2002 6:58 PM
> > >> >> To: Carter Bullard
> > >> >> Cc: [email-masked]; [email-masked]
> > >> >> Subject: RE: [ipfix-req] unidirection vs. bidirectional flows
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Mon, 7 Jan 2002, Carter Bullard wrote:
> > >> >>
> > >> >> > Gentle people,
> > >> >> > There is absolutely no reason for IPFIX to limit the type of 
> > >> >> > flow data that it supports.  The difference between
> > >> >> uni-directional
> > >> >> > and bi-directional flow records is simply the type of
> > >> >> metrics that are
> > >> >> > reported.  The flow descriptors and keys are all the
> > >> same.  Because
> > >> >> > IPFIX must support
> > >> >>      ^^^^^
> > >> >>
> > >> >> If "keys" you are refering to are the fields used to identify a 
> > >> >> flow then "SRC interface" do not fit into the statement 
> > "The flow 
> > >> >> descriptors and keys are all same for both unidirectional and 
> > >> >> bi-directional flow records" mentioned above because 
> > SRC interface 
> > >> >> will make it unidirectional.
> > >> >>
> > >> >> -vamsi
> > >> >>
> > >> >>
> > >> >> > reporting metrics that each vendors will not implement, such
> > >> >>  as jitter
> > >> >> > and one-way delay, which are the few metrics that  are
> > >> meaningful in
> > >> >> > uni-directional flow data models, supporting  metrics
> > >> that report on
> > >> >> > return traffic should not be a  hardship for IPFIX.
> > >> >> >
> > >> >> > But, I believe that if you are going to make a design
> > >> >> choice it should
> > >> >> > be motivated by design goals.  What benefit do you gain
> > >> by limiting
> > >> >> > IPFIX to a simple uni-directional
> > >> >> > flow model?   Is a uni-directional flow data model the best
> > >> >> > data model for reporting all the metrics and network
> > >> behaviors that
> > >> >> > relate to network flows?  Is it the best data model for
> > >> >> supporting all
> > >> >> > the existing commercial network flow data?
> > >> >> >
> > >> >> > But what about even the simplest of applications of flow
> > >> data? Is a
> > >> >> > uni-directional flow data model the best solution for
> > >> reporting the
> > >> >> > RTT of a ping volley?  The empirical bulk transfer
> > >> >> properties of a TCP
> > >> >> > connection?  How about TCP packet retransmission? Existence
> > >> >> of routing
> > >> >> > failures in an OSPF routed network? Application 
> > response time? 
> > >> >> > Rerouting indications?  Reachability fault detection?
> > >> >> Access policy
> > >> >> > validation?  Connectivity status?
> > >> >> >
> > >> >> > Even FTP supports both ASCII and binary data transfer.
> > >> >> Handling both
> > >> >> > uni-directional data and bi-directional data in IPFIX
> > >> >> should be pretty
> > >> >> > easy stuff.
> > >> >> >
> > >> >> >
> > >> >> > Carter
> > >> >> >
> > >> >> > Carter Bullard
> > >> >> > QoSient, LLC
> > >> >> > 300 E. 56th Street, Suite 18K
> > >> >> > New York, New York  10022
> > >> >> >
> > >> >> > [email-masked]
> > >> >> > Phone +1 212 588-9133
> > >> >> > Fax   +1 212 588-9134
> > >> >> > http://qosient.com
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > > -----Original Message-----
> > >> >> > > From: majordomo listserver
> > >> >> [mailto:[email-masked]] On
> > >> >> > > Behalf Of Dave Plonka
> > >> >> > > Sent: Monday, January 07, 2002 4:52 PM
> > >> >> > > To: [email-masked]
> > >> >> > > Subject: [ipfix-req] unidirection vs. bidirectional flows
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > IPFIX folks,
> > >> >> > >
> > >> >> > > As many of you recall, whether or not IPFIX should 
> > specify a 
> > >> >> > > unidirectional or bidirectional flow definition was a hot
> > >> >> topic at
> > >> >> > > the WG meeting.
> > >> >> > >
> > >> >> > > I think that specifying *something* gets us far along in 
> > >> >> > > communicating what a "flow" is.  Personally, I 
> > would like us 
> > >> >> > > to specify one or the other and I am in favor a 
> > unidirection 
> > >> >> > > flow definition.
> > >> >> > >
> > >> >> > > Here are some thoughts about arguments made for
> > >> >> bidirectional flows:
> > >> >> > >
> > >> >> > > A unidirectional flow definition means that the atomic
> > >> >> flow report
> > >> >> > > record is unidirection during the reporting/export 
> > phase.  For 
> > >> >> > > instance, a single packet counter for a given 
> > >> >> > > protocol/srcaddr/srcport/dstaddr/dstport n-tuple.
> > >> However, since
> > >> >> > > the exporter is somewhat of a "black box", it need not be 
> > >> >> > > constrained to a unidirectional model internally.
> > >> >> > >
> > >> >> > > A unidirectional flow definition does not prevent a 
> > collector 
> > >> >> > > implementor from using a bi-directional notion of flows
> > >> >> internally
> > >> >> > > nor does it prevent it from being stored in a bidirectional 
> > >> >> > > way prior to export.  Conversely if we specify a 
> > bidirectional 
> > >> >> > > definition, it does disqualify unidirectional 
> > implementations.
> > >> >> > >
> > >> >> > > For those that wish to perform measurements which 
> > may require 
> > >> >> > > bidirectional flow information (perhaps because start/end
> > >> >> timestamp
> > >> >> > > synchronization is required for flow pairs), the IPFIX
> > >> data model
> > >> >> > > and transport could define a mechanism by which the
> > >> >> exporter could
> > >> >> > > inform the collector about which unidirectional flow
> > >> records are
> > >> >> > > matched pairs.  That is, the exporter could help the
> > >> >> collector find
> > >> >> > > the matched pairs of flow information, perhaps by
> > >> >> exporting the flow
> > >> >> > > records in pairs or by generating a numeric identifier
> > >> that is an
> > >> >> > > attribute of both flow records.  Of course only 
> > bidirectional 
> > >> >> > > collectors would understand this convention, but a 
> > >> >> > > unidirection collector could ignore it and still 
> > make use of 
> > >> >> > > the exported flow information from an exporter that 
> > >> >> > > implemented this "bidirectional flow pairing" feature.
> > >> >> > >
> > >> >> > > Dave
> > >> >> > >
> > >> >> > > --
> > >> >> > > ":) You will make many changes before settling
> > >> satisfactorily. :)"
> > >> >> > >  - the actual message (complete with smiley faces) that I
> > >> >> received
> > >> >> > > in a
> > >> >> > >    fortune cookie at dinner after the IPFIX WG meeting
> > >> >> during IETF 52
> > >> >> > >    in Salt Lake City
> > >> >> > >
> > >> >> > > --
> > >> >> > > Help        mailto:[email-masked] and 
> > say "help"
> > >> >> > > in message body
> > >> >> > > Unsubscribe mailto:[email-masked] and say
> > >> >> "unsubscribe
> > >> >> > > ipfix" in message body
> > >> >> > > Archive     http://ipfix.doit.wisc.edu/archive/
> > >> >> > >
> > >> >> > >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > Help        mailto:[email-masked] and say
> > >> >> "help" in message body
> > >> >> > Unsubscribe mailto:[email-masked] and say
> > >> "unsubscribe
> > >> >> > ipfix" in message body
> > >> >> > Archive     http://ipfix.doit.wisc.edu/archive/
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Help        mailto:[email-masked] and say
> > >> "help" in message body
> > >> > Unsubscribe mailto:[email-masked] and say 
> > "unsubscribe 
> > >> > ipfix" in message body
> > >> > Archive     http://ipfix.doit.wisc.edu/archive/
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Help        mailto:[email-masked] and say "help"
> > >> in message body
> > >> Unsubscribe mailto:[email-masked] and say 
> > "unsubscribe 
> > >> ipfix" in message body
> > >> Archive     http://ipfix.doit.wisc.edu/archive/
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Help        mailto:[email-masked] and say 
> > "help" in message body
> > > Unsubscribe mailto:[email-masked] and say "unsubscribe 
> > > ipfix" in message body
> > > Archive     http://ipfix.doit.wisc.edu/archive/
> > >
> > 
> > 
> > 
> > 
> 
> 
> 
> --
> Help        mailto:[email-masked] and say "help" in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: "Carter Bullard" <[email-masked]>
Date: Tue, 8 Jan 2002 11:20:43 -0500

Hey Benoit,
   You know you don't support netflow on the complete line
of Cisco routers and switches.

Carter

Carter Bullard
QoSient, LLC

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> [mailto:[email-masked]] On Behalf Of Benoit Claise
> Sent: Tuesday, January 08, 2002 10:56 AM
> To: [email-masked]; [email-masked]
> support in a 
> > Cisco router.  I'm interested in how your going to make 
> > uni-directional flow record reporting cheap.
> 
> > > What routers are you talking about? Isn't NetFlow 
> available for most 
> > > CisCo and Juniper boxes?
> > > 
> > > > reporting.  However, virtually all switches and routers (> 99%) 
> > > > support RMON-style interface statistics, which are L1/L2 
> > > > bi-directional flow metrics.
> > > >
> > > >> it would be rather expensive to investigate header 
> fields again 
> > > >> and it might also reduce your maximum thoughput. Therefore a 
> > > >> device just metering incoming packets should be able 
> to match the 
> > > >> requirements.
> > > >>
> > > >> >> If "keys" you are refering to are the fields used 
> to identify 
> > > >> >> a