Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt

From: "Carter Bullard" <[email-masked]>
Date: Fri, 15 Nov 2002 01:36:02 -0500

Hey Peter,
   This is of course the problem with discussions of reliability.
Your goal of full reliability (is that 100% reliability ?) is
difficult to achieve, and your described strategy for achieving
it doesn't necessarily get you closer to your goal.  At 20-50K
records per second, source initiated failover to a secondary
receiver isn't going to get you full reliability.  The only
way an IPFIX device can support operational reliability at
the performance levels discussed (> 20-50K records per second)
is for it to have enough storage to ride through at the least
a 120 second outage, assuming TCP is the transport protocol
of choice.  That would be about 250MB-1GB of high performance
storage, depending on your flow model and deployment.  This
generally means a disk.

The idea of a transport protocol requiring a local disk on
a router is not a strategy that will be successful in the IETF.
Lets not go there, so to speak.

A successful IPFIX strategy will result in a transport protocol
that can support vendors building reliable architectures.  Minimally
that means to me receiver loss detection and stream integrity
checking. With those simple mechanisms, I can build as
reliable an IPFIX architecture that can be built.  The cheapest
one would use source multicasting.  With source multicasting,
there is no need for transport fault detection at the source or
any type of failover.

The most expensive architecture would involve fully redundant
probes, with multiple tap points and lots of local storage,
fully redundant data streams feeding fully redundant collectors
that populate fully redundant IPFIX record data stores.  The IPFIX
devices would be designed to allow multiple concurrent connections
initiated by the collectors, so that the redundant collection
architecture can completely control the flow of IPFIX records.
All that is additionally needed here is for the IPFIX data model
to support duplicate record rejection.

Carter

> -----Original Message-----
> From: Peter Ludemann [mailto:[email-masked]] 
> Sent: Thursday, November 14, 2002 11:18 PM
> To: Carter Bullard
> Cc: [email-masked]
> Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> 
> 
> Carter:
> 
> Your statement could be true for one definition of 
> reliability, but not for full reliability with fail-over. For 
> that, one needs *exporter" detection of message loss (this 
> could be caused by link failure or by collector failure - 
> that is, failure to acknowledge); the exporter can then 
> fail-over to another collector and retransmit unacknowledged records.
> 
> Probably we need multiple "levels" of reliability (I tried to 
> define some in a note a few days ago); reliability isn't a 
> one-size-fits-all item and we should have a protocol which 
> can support the various kinds of reliability.
> 
> - peter
> 
> > -----Original Message-----
> > From: majordomo listserver [mailto:[email-masked]]On 
> > Behalf Of Carter Bullard
> > Sent: Wednesday, November 13, 2002 8:50 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> >
> >
> > Hey Paul,
> >    I believe that your list of 4 items is missing
> > the critical reliability support mechanism that IPFIX
> > has in its list of requirements.   IMHO, the only
> > reliability mechanism that IPFIX needs.
> >
> >    Receiver detection of IPFIX message loss.
> >
> >    If the protocol supports this basic property, vendors
> > can then build reliable systems; as reliable as any
> > customer can afford.  Supplementing this with data
> > stream integrity mechanisms so that the receiver can
> > realize the nature of any loss, would be a dream
> > solution.
> >
> >    What does this mean for the protocol?  Sequence
> > numbers and periodic stream integrity reports. Anything
> > else can be vendor improvements.   IMHO.
> >
> > Carter
> >
> >
> > > -----Original Message-----
> > > From: majordomo listserver 
> [mailto:[email-masked]] On 
> > > Behalf Of [email-masked]
> > > Sent: Wednesday, November 13, 2002 10:35 AM
> > > Cc: [email-masked]
> > > Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> > >
> > >
> > >
> > > I'm left wondering what level of reliability is in scope?
> > >
> > > It seems we a few people that agree a highly reliable protocol is 
> > > out of scope and several agreeing it is in scope. Since 
> one person 
> > > from the former was wearing an AD hat I'm left still uncertain of 
> > > the outcome.
> > >
> > > Is high reliability in scope or out of scope. If out
> > > of scope, to what level is in scope?
> > >
> > > 	1. Transport level reliability
> > > 	2. Redundancy reliability (e.g. sending all data
> > > 	   to multiple collectors or multicasting)
> > > 	3. Failover (i.e. detecting a collector is
> > > 	   down and switching to another)
> > > 	4. Congestion awareness only (i.e. send and forget)
> > >
> > > What level of reliability is in scope?
> > >
> > > Paul
> > >
> > > --
> > > 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: "Peter Ludemann" <[email-masked]>
Date: Thu, 14 Nov 2002 23:37:33 -0800

Carter:

I think we're in violent agreement ... there are a number of kinds of
"reliability". In the scenario you give, clearly 100% reliability would be
expensive and perhaps not desired. At lower data rates (e.g., with more
aggregation on the device), the highest level of reliability might be the
best choice. The important thing is that there be a choice.

I've tried to describe how a high-reliability protocol can also function in
lower reliability modes (I didn't describe the multicast design that you
favour; but it would be a variant of simple broadcast). There's nothing
preventing CRANE, for example, being "downgraded" to the broadcast style you
describe. The inverse - taking an unreliable protocol and trying to make it
reliable - is more, ahem, "challenging".

The situation is similar to when I buy disk: I make a choice of performance
and reliability by choosing amongst options such as RAID level and
journaling. As far as my programs are concerned, it's all just disk.
Similarly, with the IPFIX protocol, I would want the exporter and receiver
to always be the same, with the protocol being put into an appropriate
reliability mode. (It happens that most of *my* users want high reliability
and are prepared to pay for it; *your* users might be different. I think
that CRANE - put into appropriate reliability mode - can satisfy both kinds
of users.)

- peter

> From: Carter Bullard [mailto:[email-masked]]
> Sent: Thursday, November 14, 2002 10:36 PM
> To: 'Peter Ludemann'

---

From: [email-masked]
Date: Fri, 15 Nov 2002 07:17:25 -0500

> best choice. The important thing is that there be a choice.

	In fact, when aggregation is in place, reliability is even
	more important since the data represents much larger chunks
	of data.

	Paul