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

From: Dave Plonka <[email-masked]>
Date: Mon, 7 Jan 2002 15:51:32 -0600

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/

---

From: "Will Eatherton" <[email-masked]>
Date: Mon, 7 Jan 2002 14:14:10 -0800

> Conversely if we specify a bidirectional definition, it does

I think this is a key point and I agree that bidirectional definition
disqualifies or at the very least encumbers unidirection implementations.
Also based on currently developed and deployed traffic export mechanisms
(i.e. netflow) unidirectional definition has a leg up.

Will Eatherton

---

From: "Carter Bullard" <[email-masked]>
Date: Mon, 7 Jan 2002 18:31:08 -0500

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

---

From: Vamsidhar Valluri <[email-masked]>
Date: Mon, 7 Jan 2002 15:57:30 -0800 (PST)

> 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

---

From: Vamsidhar Valluri <[email-masked]>
Date: Mon, 7 Jan 2002 16:51:56 -0800 (PST)

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

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

> > 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
> >
> >
> >
> >
> > 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
> >
> >
> >  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
> > > 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
> > topic at
> > > > the WG meeting.
> > > > 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.
> > > >
> > > > 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.
> > > >
> > 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.
> > > >
> > 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
> > > >  - the actual message (complete with smiley faces) that I
> > received
> > > > in a
> > > Unsubscribe mailto:[email-masked] and say "unsubscribe
> > > ipfix" in message body

---

From: "Carter Bullard" <[email-masked]>
Date: Mon, 7 Jan 2002 19:42:22 -0500

Hey Vamsi,

Carter

Carter Bullard
QoSient, LLC

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

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 08 Jan 2002 12:24:24 +0100

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

---

From: "Carter Bullard" <[email-masked]>
Date: Tue, 8 Jan 2002 07:34:47 -0500

Hey Juergen,
Just a note, the majority of switches and routers
today (> 90%) cannot support uni-directional flow record
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?

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 Juergen Quittek
> Sent: Tuesday, January 08, 2002 6:24 AM
> To: [email-masked]; 'Vamsidhar Valluri'

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 08 Jan 2002 14:22:53 +0100

> today (> 90%) cannot support uni-directional flow record

What routers are you talking about? Isn't NetFlow available
for most CisCo and Juniper boxes?

> 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

---

From: "Carter Bullard" <[email-masked]>
Date: Tue, 8 Jan 2002 10:51:13 -0500

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.

Carter

Carter Bullard
QoSient, LLC

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

> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2002 8:23 AM
> To: [email-masked]
> > 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.
> >
> >> From: majordomo listserver [mailto:[email-masked]] On 
> >> Behalf Of Juergen Quittek
> 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.
> >>
> to be part 
> >> of the requirements (and consequently also too expensive 
> to be part 
> >> of the general architecture on the exporter side).
> >>
> 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
> >> 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
> >> --
> >> --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
> >> >> > There is absolutely no reason for IPFIX to limit the type of 
> >> >> > flow data that it supports.  The difference between
> >> >> uni-directional
> >> >> 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
> >> >>
> >> >>
> >> >> > > nor does it prevent it from being stored in a bidirectional 
> >> >> > > way prior to export.  Conversely if we specify a 
> bidirectional 
> >> >> > > Help        mailto:[email-masked] and 
> say "help"
> >> >> > > in message body

---

From: Vamsidhar Valluri <[email-masked]>
Date: Tue, 8 Jan 2002 07:55:22 -0800 (PST)

Carter,
   Catalyst platform may need cards but c4500, c7200, RSP, GSR routers do
not need special cards.

-vamsi

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 08 Jan 2002 17:00:26 +0100

Hi Carter,

I'm not making anything cheaper as it is, I'm just claiming
that bi-directional measurements in big routers are expensive,
IMO too expensive.

    Juergen

---

From: [email-masked]
Date: Tue, 08 Jan 2002 11:29:34 -0500

Carter,

I'm a bit confused. Why doesn't the ability to provide bi-directional
info, as Dave described, meet your needs? Those devices that
can do bi-directional will report it that way, those that can't
will report it as uni-directional. Some down stream application
will have to do the work to turn 2 uni-directional flows into
one bi-directional one, if that is what's needed. And if uni-directional
is needed the app will split it apart.

But if you require bi-directional reporting, many devices wont
be able to do it. Which then eliminates any down stream analysis.

Paul

---

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

Hey Juergen,
   There are a significant number of Cisco routers and switches
that do not support netflow.  And Cisco/Riverstone do not
constitute the complete set of router/switch vendors on
the planet.

   My entire position is that IPFIX should not make any
requirements/restrictions on the data model.

Carter

Carter Bullard
QoSient, LLC

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

---

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

Hey Paul,
   So I have a flow monitor that generates RTT times for DNS
transactions.  How do I report RTT for a DNS transaction using
IPFIX if it has the restriction that I must report my metrics
using a uni-directional semantic?  

So how do I do it?  Break the records in two, and somehow
tag that the two records are unambiguously related, and
where do I put the bi-directional semantic?  In both of
the records, in the first one, the last one, in a separate
third record?

Doesn't seem very efficient.

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 
> [email-masked]
> Sent: Tuesday, January 08, 2002 11:30 AM
> Subject: Re: [ipfix-req] unidirection vs. bidirectional flows
> 
> 
> 
> Carter,
>

---

From: [email-masked]
Date: Tue, 08 Jan 2002 11:41:34 -0500

> > bi-directional flow metrics using IPFIX.

	Why wouldn't they report them as 2 uni-directionals?

> >> <[email-masked]> wrote:
> >>
> >> > Hey Vamsi,

---

From: [email-masked]
Date: Tue, 08 Jan 2002 11:51:08 -0500

I'm not sure. Can you tell me the fields reported today?
I'll see if I can make sense of it as 2 uni-directional
flows.

Paul

---

From: Dave Plonka <[email-masked]>
Date: Tue, 8 Jan 2002 11:08:00 -0600

On Mon, Jan 07, 2002 at 06:31:08PM -0500, Carter Bullard wrote:
<snip>
> flow model?

I'll try to explain why it may be important that the "unidirection vs.
bidirectional" decision be made (in the requirements) and address how
it is in accordance with our goals (which is a good point that Carter
made, IMO):

Here's the goals that a unidirectional flow defintion helps to address:

1) Define the notion of a "standard IP flow." [...]

   In the "real world", flows of water or lava have a single general
   direction which defines them as a flow.  While it may be circuitous,
   material traveling in another direction is not part of the same
   flow.

   By this analogy and precedent, a unidirectional flow definition will
   be easier to understand by readers of our documents, and prospective
   implementors.

   Personally, I want one of the benefits of IPFIX to be able to use
   the term "IPFIX flow" or "standard IP flow" (in conversation) and
   know what it is that the speaker meant.  The direction of traffic
   Internet traffic seems to me to be one of the most fundamental
   things we want to know.

2) Devise data encodings that support analysis of IPv4 and IPv6 unicast
   and multicast flows [...]

   Although this is an afterthought, it's interesting that we said
   "support analysis".  Flow pasting and matching can be considered
   forms of analysis.  So bidirectional flows could be considered the
   product, rather than the requisite input, to analysis.

3) Specify the transport mapping for carrying IP flow information, one
   which is amenable to router and instrumentation implementors, and to
   deployment.

   If the "standarde existing practice" fits, it probably fits here
   best.  There are a number of hardware/ASIC based implementations
   that understand unidirectional flows.  Only devices such as end
   hosts, stateful firewalls, and NAT routers, have all the information
   necessary to report accurate bidirectional flows.

While there is still the nebulous(?) option of supporting both uni- and
bi-directional flow defintions in IPFIX, I'd like to pare down the work
we have ahead of us by making IPFIX as simple as possible, but no
simpler.  Unidirectional is simpler, and it is possible as existing
implementations can attest.  Bidirectional is likewise possible as
there are also existing implementations, but it makes more work for the
exporter.  That work can be done by the collectors and in some cases
must be done by the collector because the traffic in each direction
will have been reported by discrete exporters.

Dave

---

From: "Will Eatherton" <[email-masked]>
Date: Tue, 8 Jan 2002 10:26:05 -0800

Carter,

Providing customized export of data of this type seems beyond the scope of
first pass IPFIX goals to me (it is not flow export, strictly speaking).  In
the main stream router environment (i.e. cisco/juniper/etc..) this sort of
functionality would be done by SW sitting behond or integrated into a
collector.  So this sort of summarization is one level above the stack from
where I believe we want to be with IPFIX.

I think this is a fundamental narrowing that we need to do in order to move
forward.

Will
cisco

> From: majordomo listserver [mailto:[email-masked]]On Behalf
> Of Carter Bullard
> Sent: Tuesday, January 08, 2002 8:41 AM
> To: [email-masked]; [email-masked]

---

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

Hey Paul,
   The RTT metric in the example is Duration.  If your
uni-directional flow record's have start and stop times,
then you could derive the Duration by subtracting
the start times of one record from the stop times of the
other record, but you need to have something that states
that these records are related.  You won't be able to infer
this from the 5-tuple flow descriptor in either record,
so you'll need some type of binding identifier.

   My problem with this is that you get 2 complete records
for a single network event.  They include redundant headers,
redundant flow descriptors, two unused time-stamps, and we
introduce new requirements to guarantee that the binding
identifiers be unique.  The added bandwidth requirements
for transmitting the redundant information can get pretty
big in high end monitors.  A 5 tuple flow descriptor for
IPv4 addresses is 16 bytes.  For IPv6 its 38 bytes.  The
redundant timestamps are 16 bytes, and an IPFIX record
header will probably be around 16-32 bytes.  So the
redundant information is around 64-128 bytes.  That's pretty
significant in my book.

   The XML schema for the data that Argus generates is at
http://qosient.com/argus/Xml/ArgusRecord_xsd/ArgusRecord.htm
Argus is a bi-directional flow monitor that generates very
flexible flow records.  Lots of optional fields.  Now I am
not recommending Argus's data strategy for IPFIX, I'm just
pointing out that Argus like schemas can handle uni-directional
and bi-directional reports at the same time, because it
supports optional fields.

Carter

Carter Bullard
QoSient, LLC

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

> From: calato [mailto:calato] On Behalf Of [email-masked]
> Sent: Tuesday, January 08, 2002 11:51 AM
> To: [email-masked]
> Cc: [email-masked]
> > transactions.  How do I report RTT for a DNS transaction 
> using IPFIX 
> > if it has the restriction that I must report my metrics using a 
> > uni-directional semantic?
> > 
> > the records, in the first one, the last one, in a separate third 
> > record?
> > 
> [mailto:[email-masked]] On 
> > > Behalf Of [email-masked]
> > > I'm a bit confused. Why doesn't the ability to provide 
> > > bi-directional info, as Dave described, meet your needs? Those 
> > > devices that can do bi-directional will report it that way, those 
> > > that can't will report it as uni-directional. Some down stream 
> > > application will have to do the work to turn 2 
> uni-directional flows 
> > > into one bi-directional one, if that is what's needed. And if 
> > > uni-directional is needed the app will split it apart.
> > >
> > > But if you require bi-directional reporting, many devices wont be 
> > > able to do it. Which then eliminates any down stream analysis.
> > >
> > > Paul
> > >
> > >
> > > Carter Bullard wrote:
> > > >
> > > > Hey Vamsi,
> > > > problem.  Lets look at how this may work.  Suppose 
> there is a SRC 
> > > > 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
> > > > > 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
> > > > >
> > > > >
> > > > > > > specify one or the other and I am in favor a unidirection 
> > > > > > > flow definition.
> > > > > > >
> > > > > > > record is unidirection during the 
> reporting/export phase.  
> > > > > > > For instance, a single packet counter for a given 
> > > > > > > A unidirectional flow definition does not prevent a 
> > > > > > > collector implementor from using a bi-directional 
> notion of 
> > > > > > > flows
> > > > > internally
> > > > > > > For those that wish to perform measurements which may 
> > > > > > > require bidirectional flow information (perhaps because 
> > > > > > > start/end
> > > > > timestamp
> > > > > > > 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 
> > > > > > > Help        mailto:[email-masked] 
> and say "help"
> > > > > > > in message body

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 09 Jan 2002 16:01:04 +0100

--On 08 January 2002 11:33 -0500 Carter Bullard <[email-masked]> wrote:

Hi Carter,

> constitute the complete set of router/switch vendors on

I think I was talking about Juniper and Cisco, but this does
not matter at all. This talking about 99% of all routers do
this and that without any proove does lead us nowhere.

> requirements/restrictions on the data model.

I tend to agree when talking about the requirements, but when
it comes to the architecture, it might get hard to avoid it
completely.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 09 Jan 2002 16:08:55 +0100

> so you'll need some type of binding identifier.

Exactly. Now who's work should it be to find the binding?
The exporter? Why not the application analyzing the data
at the collector. It is much better suited for this job and
can do it online or offline depending of capabilities and
requirements for this analysis. But I would not ask the
exporter to do this job.

> redundant information is around 64-128 bytes.  That's pretty

You are right. This dumb approach wastes resources. But that's
why we require flexible flow records for IPFIX. If this above
is your only measurement, then reduce the flow record to just
two tomestamps and a rule (set) identifier and you waste much
less bandwidth.

    Juergen

>> > > > > > > Behalf Of Dave Plonka

---

From: Dave Plonka <[email-masked]>
Date: Wed, 9 Jan 2002 09:51:48 -0600

<snip>
> > but you need to have something that states

(But what if the exporter _volunteers_ to do that job? ;^)

That binding is what I called "flow matching" in an earlier post:

   http://ipfix.doit.wisc.edu/archive/0356.html

I take it that Carter's point is that some exporters already know that
binding (before they export) - i.e. it will know which flows match.

This is what I was trying to accommodate, in my first posting:

      http://ipfix.doit.wisc.edu/archive/0330.html

in this thread when I said:

   [...] 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.

and Paul reiterated here:

     http://ipfix.doit.wisc.edu/archive/0349.html

I've been giving this some more thought, and would like to have some
email-friendly format for us to run through examples.  How about this:
I'll show individual unidirectional flows as a single line in
pseudo-syntax sort of like that produced by the argus ra(1) command or
my "flowdumper -s" utility with NetFlow or LFAP, i.e.:

   +----------------------------------------------------------------------+
   | FLOW: src_addr:src_port -> dst_addr:dstport PROTO ...                |
   +----------------------------------------------------------------------+

Consider this example of a SSH session:

Current Unidirectional exporters will report it like this (essentially
two records, minimum):

   +----------------------------------------------------------------------+
   | FLOW: 10.42.69.10:1024 -> 10.10.10.69:22   TCP                       |
   +----------------------------------------------------------------------+
   | FLOW: 10.10.10.69:22   -> 10.42.69.10:1024 TCP                       |
   +----------------------------------------------------------------------+

If the data model and architecture is sufficiently feature-rich, a
bidirectional exporter could export those flows, perhaps, as two flow
records wrapped as one "Flow Information Record" or whatever you'd like
to call it.  E.g.:

   +----------------------------------------------------------------------+
   | FIR: (unicast, "normal" TCP session)                                 |
   |+--------------------------------------------------------------------+|
   ||FLOW: 10.42.69.10:1024 -> 10.10.10.69:22   TCP                      ||
   |+--------------------------------------------------------------------+|
   ||FLOW: 10.10.10.69:22   -> 10.42.69.10:1024 TCP                      ||
   |+--------------------------------------------------------------------+|
   +----------------------------------------------------------------------+

Note that the two unidirectional flow records are wrapped in what I
called a FIR, or "Flow Information Record".

(This ASCII art is just meant to be a logical representation, I'm not
suggestion a typedef struct, TLV, or anything specific.)

The advantage of this would be that the embedded flow records could be
understood by either an unidirectional or bidirectionally aware
collecter.  The encapsulating "FIR" (that binds the two together) could
essentially turn into a "no-op" for collectors that don't need to
understand any application-level relationship between those flows, for
the given application.

I've worked through other examples for ping, traceroute, multicast
w/multiple egress ifIndex numbers, etc. but I'll hold off until I see
if this is understandable.

All in all, I like the clarity of unidirectional flow definition, and
also only requiring unidirectional support as the common-denominator,
but I do agree that and the adopting of a unidirectional flow
definition (if we do so) should not make more work for the collector
when the exporter could pass that info along.

Dave

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 09 Jan 2002 18:05:25 +0100

I am trying to summarize the discussion from the requirements viewpoint:

Do we need to add a requirement on the flow model to the requirements draft?

If yes then looking at the discussion it seems that there is rough consensus
on: MUST support uni-directional, additionally MAY/SHOULD(?) support 
bi-directional if the exporter supports flow matching.

Correct?

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
FhI FOKUS / Global Networking (GloNe)    Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287 
D-10589 Berlin, Germany                  www.fokus.fhg.de/usr/sebastian.zander

---

From: "Carter Bullard" <[email-masked]>
Date: Wed, 9 Jan 2002 13:27:57 -0500

Hey Juergen,
   Hmmmm, if you have such flexible support, why not
support adding the return metrics as optional data?
Why generate all this work?

Carter

Carter Bullard
QoSient, LLC

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

> Sent: Wednesday, January 09, 2002 10:09 AM
> To: [email-masked]; [email-masked]
> > flow record's have start and stop times, then you could derive the 
> > Duration by subtracting the start times of one record from the stop 
> > times of the other record, but you need to have something 
> that states
> >    My problem with this is that you get 2 complete records for a 
> > single network event.  They include redundant headers, 
> redundant flow 
> > descriptors, two unused time-stamps, and we introduce new 
> requirements 
> > to guarantee that the binding identifiers be unique.  The added 
> > bandwidth requirements for transmitting the redundant 
> information can 
> > get pretty big in high end monitors.  A 5 tuple flow descriptor for
> You are right. This dumb approach wastes resources. But 
> that's why we require flexible flow records for IPFIX. If 
> this above is your only measurement, then reduce the flow 
> record to just two tomestamps and a rule (set) identifier and 
> you waste much less bandwidth.
> 
>     Juergen
> -- 
> > Argus is a bi-directional flow monitor that generates very flexible 
> > flow records.  Lots of optional fields.  Now I am not recommending 
> > Argus's data strategy for IPFIX, I'm just pointing out that 
> Argus like 
> > schemas can handle uni-directional and bi-directional 
> reports at the 
> > same time, because it supports optional fields.
> >
> >
> > Carter
> >
> > Carter Bullard
> > QoSient, LLC
> I'll see if 
> >> I can make sense of it as 2 uni-directional flows.
> >>
> >> Paul
> >>
> >> Carter Bullard wrote:
> >> >
> >> > Hey Paul,
> >> > So how do I do it?  Break the records in two, and 
> somehow tag that 
> >> > the two records are unambiguously related, and where do 
> I put the 
> >> > bi-directional semantic?  In both of the records, in the 
> first one, 
> >> > the last one, in a separate third record?
> >> >

---

From: Jc Martin <[email-masked]>
Date: Wed, 09 Jan 2002 14:08:07 -0800

Dave 

[snip]
> records wrapped as one "Flow Information Record" or whatever you'd like

This suggestion could be seen has adding application level semantic to
the flow exported.
In some ways, this seems to extend the grouping that a collector can do
based on exported attributes (like the 5 tuple), with information that
is known only by the exporter.
I think that this is valuable, but should not be restricted in grouping
together flows that are "pairs", but could be used to group flows that
are part of a transaction, or "dialogue" involving multiple flows.

JC

---

From: Dave Plonka <[email-masked]>
Date: Wed, 9 Jan 2002 17:29:04 -0600

> are part of a transaction, or "dialogue" involving multiple flows.

I agree.  And now I feel we might be getting somewhere, at least in
discussing some things that hadn't occurred to me before.

As you say perhaps more than two flows share a common attribute.  For
instance, a sequence of 20 packets (about half in each direction) that
were the result of running traceroute(1) could be grouped together by a
very intelligent exporter.

Back to "bidirectionality".  That two flows were part of the same
"session" is but one _common_attribute_ that a given set of flows might
share, and even there are even multiple kinds (or confidence levels) of
bidirectionality:

  1) "simple" 5-tuple match
  2) state network/transport-level match
  3) application-level "sane transaction" match

Using simple 5-tuple rules, two unidirectional UDP flows might be
mistakenly matched to each other because they happened to be DoS floods
between two hosts using inverse port numbers.  (e.g.
foo_host:3000 -> bar_host:53, bar_host:53 -> foo_host:3000).  However,
a more intelligent exporter (that understood DNS question & answer
payloads), might realize that these two flows were not a true match at
the application level, perhaps because the packet payload consisted of
all zeroes (i.e. was not a valid DNS transaction.)

That bidirectionality might just be consider one of many possible
common attributes amongst sets of unidirectional flows lends support to
the argument for the "standard IP flow" being defined as
unidirectional.  Still, we don't lose any reporting capabilities for
this, since IPFIX exporters MAY be able to export additional
information to IPFIX collectors that are prepared to handle such
information.  That additional information that will convey that a set
of two or more flows may share a common attribute such as
"bidirectionality", a single multicast source, etc.

Dave

---

From: Benoit Claise <[email-masked]>
Date: Fri, 11 Jan 2002 14:37:26 +0100

All,

> bi-directional if the exporter supports flow matching.

I'm in favor of not mentioning anything about bidirectional flows and to have a
flexible export mechanism (as Dave proposed).
This flexible export format must be extensible so that, if Carter has got in the
exporter an Identifier to link several flows, this Identifier could be sent part
of the export.

From http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt:
   The data model MUST be extensible for future attributes to be added.
   Even if a set of attributes is fixed in the flow record, the data
   model MUST provide a way of extending the record by configuration or
   for certain implementations.

But actually, I'm not sure there is a big difference between having nothing
specified about bidirectional and having a MAY...

Regards, Benoit

---

From: [email-masked]
Date: Fri, 11 Jan 2002 11:53:41 -0500

I think one of Carter's points though was efficiency.
So, to use your structure, instead of reporting this...

You would be more efficient by reporting somehthing like this.

+--------------------------------------------------------------------+|
|FLOW: 10.42.69.10:1024 <-> 10.10.10.69:22   TCP                      |
+--------------------------------------------------------------------+|

In either case the collector needs to know how to deal
with the information. In the first case, if the collector 
wants bi-directional it can combine the 2 records. If it 
wants uni-directional ignore the FIR part.

In the seconds case, if it wants bi-directional, just forward
on. If it wants uni-directional, create 2 records and pass them
along.

You made this comment...

> The advantage of this [the FIR] would be that the embedded flow 
> records could be understood by either an unidirectional or
> bidirectionally aware collecter.  The encapsulating "FIR" (that 
> binds the two together) could essentially turn into a "no-op" for
> collectors that don't need to understand any application-level
> relationship between those flows, for the given application.

While it may make things slightly simpler in the collector the
bandwidth cost is significant when you think of millions of
flows per day. In the second case above. the cost of turning 
one record into 2 at the collector, would be less than the
bandwidth cost of the frist case, IMHO.

Paul

---

From: [email-masked]
Date: Fri, 11 Jan 2002 12:52:32 -0500

> bi-directional if the exporter supports flow matching.

	I think it is a MUST on uni-directional. I think
	bi-directional is a data efficiency question.

	If I as the exporter "know" these 2 flows
	are bi-directional, then I want to do 2 things
	1) save space by reporting information once and
	2) indicate the relationship between these
	uni-directional flows. 

	There may be lots of relationships we want be able
	to represent. Such as, these flows are part of the
	same multi-cast. I don't see why we need to call
	out bi-directional as a special case in the 
	requirements.

	As for the data model, there are lots of ways to
	save space and we should look at that as a topic
	of its own. 

	As for the relationship issue, again, we need to look 
	at that on its own. Some relationships we will want 
	in the IPFIX data and some we will want to calculate 
	down stream.

	Paul

---

From: Jc Martin <[email-masked]>
Date: Fri, 11 Jan 2002 11:52:00 -0800

>         in the IPFIX data and some we will want to calculate

I agree.

What is mandatory is the support of uni-directional.
Then, we should mention that the exporter MAY group
unidirectional flows to represent higher semantic,
such as bi-directional flows, or transactions.
The way this grouping is done is going to be specified
in the data model. Ideally, it would be hierarchical
to accomodate multiple levels of grouping, for example :
transaction -> bi-directional -> unidirectional

This grouping can be done as simply as adding attributes
that are processed by the collectors to reconstruct 
higher level flows.

JC.

---

From: Robert Lowe <[email-masked]>
Date: Fri, 11 Jan 2002 14:52:33 -0600

> So, to use your structure, instead of reporting this...

A couple of simple-minded questions as a lurker here...

If you do report a bi-directional flow, do you turn reported elements, 
e.g. bytes or packets, into tuples within the flow record, one for 
from-src and the other for from-dest?  Or do you always assume an 
aggregate?  Assuming an aggregate is simpler, but not ideal.

> bandwidth cost of the frist case, IMHO.

Given that the reporting method will have a bandwidth impact, does an
exporter export anything about the traffic it generates?  Or does it
store aggregate statistics that can be polled by the collector?

A flexible approach allows for differing designs where processing
can be distributed between the exporter and the collector to varying
extents, but since bandwidth consumed and processing power are linked,
I'm not sure I understand where bi-directional reporting fits.  When
the routing engine is under stress, the exporter will not have some
magic reserve of processing power to do "flow matching", but if it resorts
to uni-directional flow reporting, it exacerbates the situation by 
consuming more bandwidth, leaving only a fall-back to packet sampling.  
And, if that happens, what kind of impact does it have on bi-directional 
flow reporting?

-Robert

---

From: [email-masked]
Date: Fri, 11 Jan 2002 17:10:56 -0500

> aggregate?  Assuming an aggregate is simpler, but not ideal.

	If you want to be able to create uni-directional flows
	I think you need to report tuples.

> store aggregate statistics that can be polled by the collector?

	Some implementations don't keep track of flows
	to and from the exporter itself. But in that case
	I think it should maintain some internal statistics
	that can be retrieved out-of-band.

	For those that report flows to and from the exporter
	the info is already available.

> I'm not sure I understand where bi-directional reporting fits.  

	A few things. 

	1) if the bottle neck is CPU cycles because of routing you
	have lots of trouble. bi-directional or uni-directional 
	probably is not much help. But if it is the "match" that is
	eating up all the CPU that's a different story.

	2) If you're short on link capacity then bi-directional
	   flows may help. But you only get a max of 50%. There
	   are other aggregation schemes that may be of more
	   use to reduce the about of data sent.

	3) The other important thing bi-directional flows
	   gives is a semantic relationship between 2
	   uni-directional flows. It may be difficult or
	   impossible to calculate that relationship down
	   stream. For example, someone mentioned looking
	   at DNS packet contents. You wont have access to
	   that down stream.

> When

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 11 Jan 2002 17:18:35 -0500

Gentle people,
   I completely agree with Paul.  Bi-directionality
is just one relationship we'll want to report in
our flow data model.  The whole point is to not
find the simplest model, but rather a working model
that optimizes a few key points.

   I believe that transport efficiency is one
of the more important ones.

   I don't have any problem with uni-directional
flow descriptors, they happen to also work very well
for bi-directional flow metric reporting.  But
IPFIX MUST be able to efficiently report the additional
attributes of the flow, such as return status and
metrics.  Duplicating an entire IPFIX flow record,
and a binding record would not be the most efficient
way of doing it.

Carter

Carter Bullard
QoSient, LLC

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

> Sent: Friday, January 11, 2002 12:53 PM
> To: Sebastian Zander
> Cc: req
> > Do we need to add a requirement on the flow model to the 
> requirements 
> > draft?
> > 
> > Help        
> mailto:[email-masked] and say "help" in message body

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 11 Jan 2002 17:41:11 -0500

Hey Robert,
   Rather than thinking that flow matching is an option for
a flow monitor that can be turned on and off, why not
consider the existing flow monitors that do bi-directional
flow matching as there only function.  The problem becomes
"the monitor has bi-directional flow data, and it needs to
transport it using IPFIX."  

   Should this monitor be burdened with having to generate
two IPFIX records, when one could easily do the trick?  Why
throw away the processing that the bi-directional monitor
spent realizing the relationship?

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 Robert Lowe
> Sent: Friday, January 11, 2002 3:53 PM
> To: [email-masked]