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

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

Carter and all,

I'm not sure I understand the note below

From the last WG meeting minutes, I can read:
   "We were reminded that this group was chartered to standardize
   existing practice, and that specifying new measurement techniques is
   out of scope."

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

From the requirements draft:
1.1 IP Flows

   There are several definitions of the term 'flow' being used by the
   Internet community. Within this document we use the following one:

      A flow is a set of packets passing an observation point in the
      network during a certain time interval. All packets belonging to a
      particular flow have a set of common properties derived from the
      data contained in the packet and from the packet treatment at the
      observation point.

   The observation point may be a network interface of a device or an
   entire router, a probe, or a middlebox with several interfaces.
   Properties derived from packet treatment include for example the
   interface at which the packet arrived, the interface the packet will
   be forwarded to and potentially some other information.

If the observation point is interface 1 of line card 1 and the output interface interface the interface 1 of line card 2, this is extremely difficult (if not impossible) to correlate the flow going forth and the flow going back. Because most of the processing for a "ipfix like" protocol will be done on the incoming line card.
As a conclusion, I think this only solution is that a flow is unidirectional.

Regards, Benoit.
> 
>     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: Dave Plonka <[email-masked]>
Date: Tue, 8 Jan 2002 11:01:58 -0600

Benoit made this point that I was going to follow-up with, in a
slightly more general way (below):

On Tue, Jan 08, 2002 at 04:08:15PM +0100, Benoit Claise wrote:
<snip>
> If the observation point is interface 1 of line card 1 and the output
> interface interface the interface 1 of line card 2, this is extremely
> difficult (if not impossible) to correlate the flow going forth and the
> flow going back. Because most of the processing for a "ipfix like"
> protocol will be done on the incoming line card.
>

In other words, a given observation point within an exporter may only
see a portion of the traffic for a given application-level stream.  The
result is that, in some circumstances, it can only report the one
direction.  Like in Benoit's example, asymmetric routing would further
exacerbate this since each direction is observed by a different
router/exporter.

Now - on to the more general part...
There are two operations that are sometimes performed during flow
analysis: "flow pasting" and "flow matching" (my terms).

"Flow pasting" is the sequencing and coalescing/concatenating of flow
records into larger flow records. "Flow matching" is the identifying of
corresponding flow records in each direction, that are ostensibly part
of the same application-level stream.

Usually the purpose of "flow pasting" and "flow matching" is to
discover something about the underlying application-level stream.  Note
that this is not necessarily useful for some IPFIX applications
(Usage-based Accounting, Traffic Profiling, Traffic Engineering), but
is sometimes advantageous for others (Attack/Intrusion Detection, QoS
Monitoring).

For those applications that benefit from flow pasting and/or matching,
these operations are still necessary _even_ if a bi-directional flow
definition and export record is used.  It is still necessary for the
collector (or subsequent post-processor) to perform pasting and
matching functions because sometimes the (bidirectional) flow records
will be from multiple sources.  From this I conclude that using a
bidirectional flow export record does not simplify the implementation
of the collector and others have said that it complicates the exporter
implementation.

I started off this thread by saying that a unidirectional flow
definition (and export record) does not preclude someone from
implementing an exporter which adds additional flow record attributes
that facilitate "flow pasting" and "flow matching".

Since IPFIX won't specify a file-format for flow records for persistant
storage, implementors would be free to create their own bidirectional
records, which they are free to refer to as "Foobar(tm) IP flows"
rather than "IPFIX standard IP flows".

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