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

From: "Carter Bullard" <[email-masked]>
Date: Tue, 8 Jan 2002 17:09:30 -0500

[sorry for the delay on this, it bounced and this is a resend]

Hey Vamsi,
   I'm one for allowing the most flexible flow descriptors possible.
If a switch vendor wants to report on internal switch path performance,
I want to support that.  Whether that is uni-directional or
bi-directional, I don't care. The vendor decided it wanted to generate
the record, and IPFIX should support transporting it.  If someone
wants to do bi-directional MPLS flows, I won't understand why, but
I'm not going to get in the way of them doing it.

   The idea is that if a vendor engineers its box to generate
a particular type of flow data, IPFIX should be able to transport
it, because if IPFIX is not the protocol of choice, it will
fail as a standard.

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

-----Original Message-----
From: Vamsidhar Valluri [mailto:[email-masked]]=20
Sent: Monday, January 07, 2002 7:52 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:

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

> SRC interface and a DST interface, so that a flow is simply all the=20

> packets moving from SRC -> DST.  The return flow would be all the=20 
> 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,=20 that the two records cannot be correlated at all.

Hi Carter,
    True, but there are certain high end platforms which will take
considerable hit if destination interface has to become part of "keys".
Other way of looking at it is to take away "interfaces" from keys so
that bi-directional flows map to the same flow record but here we may
lose interface information because birectional flows might take
different interfaces at different point of time, if not then we are
fine.

-vamsi

>
>
> 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=20 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. =20 
> > > 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=20 
> > descriptors and keys are all same for both unidirectional and=20 
> > bi-directional flow records" mentioned above because SRC 
> > interface=20 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=20 in uni-directional flow data models, supporting  
> > >metrics that=20 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=20 
> > > 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=20 
> > > 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=20 a uni-directional flow data model the best solution for 
> > > reporting=20 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?=20 
> > > 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=20 
> > > > unidirectional or bidirectional flow definition was a hot
> > topic at
> > > > the WG meeting.
> > > >
> > > > I think that specifying *something* gets us far along in=20 
> > > > communicating what a "flow" is.  Personally, I would like us 
> > > > to=20 specify one or the other and I am in favor a unidirection 
> > > > flow=20 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=20 instance, a single packet counter for a given=20 
> > > > protocol/srcaddr/srcport/dstaddr/dstport n-tuple.  However,=20 
> > > > since the exporter is somewhat of a "black box", it need not 
> > > > be=20 constrained to a unidirectional model internally.
> > > >
> > > > A unidirectional flow definition does not prevent a collector=20

> > > > implementor from using a bi-directional notion of flows
> > internally
> > > > nor does it prevent it from being stored in a bidirectional 
> > > > way=20 prior to export.  Conversely if we specify a 
> > > > bidirectional=20 definition, it does disqualify unidirectional 
> > > > implementations.
> > > >
> > > > For those that wish to perform measurements which may require=20

> > > > bidirectional flow information (perhaps because start/end
> > timestamp
> > > > synchronization is required for flow pairs), the IPFIX data=20 
> > > > 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=20 an attribute of both flow records.  Of course only 
> > > > bidirectional

> > > > collectors would understand this convention, but a 
> > > > unidirection=20 collector could ignore it and still make use of 
> > > > the exported=20 flow information from an exporter that 
> > > > implemented this=20 "bidirectional flow pairing" feature.
> > > >
> > > > Dave
> > > >
> > > > --
> > > > ":) You will make many changes before settling 
> > > > satisfactorily.=20 :)"
> > > >  - 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=20 
> > > "unsubscribe ipfix" in message body
> > > Archive     http://ipfix.doit.wisc.edu/archive/
> > >
> >
> >
> >
>
>
>

----- End forwarded message -----

-- 
"Give a man a fish,  and he'll resent you for a day.
   Teach a man to fish,  and he'll resent you all his life."
 - from the Tenets of Pragmatism (Pragmatic Society)

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