Subject: RE: [ipfix-eval] Simon's and Ram's evaluations

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 28 Oct 2002 11:30:13 -0800

well, this paper is kind of outdated...It has been more than a year after
this paper. A critical year on P2P application I might say.

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Monday, October 28, 2002 7:40 AM
> To: [email-masked]
> Cc: Juergen Quittek; [email-masked]
> Subject: Re: [ipfix-eval] Simon's and Ram's evaluations
> 
> 
> Paul,
> 
> >Juergen Quittek wrote:
> >  
> >
> >
> >[snip]
> >
> >  
> >
> >>Juergen's Conclusion
> >>
> >>My view is a bit bit biased, because it is the view of one having to
> >>implement the protocol on devices. Therefore, I give more 
> weight than
> >>others might do to the cost of the implementation, the 
> consumption of
> >>processing power and the memory consumption.
> >>
> >>    
> >>
> >
> >	Netflow V9 will need to me modified to allow split reporting.
> >	Many devices do not have the ability to store 
> attributes per flow
> >	until expiration.
> >
> >	This is a key diffentiator for LFAP as it allows both 
> split reporting
> >	and one shot reporting.
> >
> Do I understand correctly that with split reporting, you report a FUN 
> and (at least) one FAR messages.
> So basically, in order to gain some memory on the devices for 
> long lived 
> flows, you export 2 smaller messages (whose sum can only be 
> bigger for 
> short flows) to the collector for all flows, included the short ones?
> We've seen on our devices that the action of exporting 
> packets will eat 
> some extra non-negligible CPU. And I think this is a concern!
> 
> Now regarding the long-lived flows.
> I know that the P2P problem is growing but I would refer to 
> this paper 
> http://www.research.att.com/~duffield/pubs/DLT02-flows.pdf
> You will see in there that the highest flows in terms of 
> average packet 
> number are napster and real-audio with respectively 455 and 
> 467 packets.
> What is the chance that they will produce long-lived flows? 
> knowing that 
> this timer is 30 minutes in the netflow metering process 
> (btw, this is 
> configurable)
> Not much I should say!
> 
> Regards, Benoit.
> 
> >
> >  
> >
> >>Therefore, I estimate simple approaches. And NetFlow is the 
> most simple
> >>one. Also I learned that simplicity increases reliability (or safety
> >>of design and implementation).
> >>
> >>I am not sure whether or not I could build a compatible 
> implementation of
> >>CRANE or LFAP that just ignores all configuration messages 
> received from
> >>a collector.
> >>    
> >>
> >
> >	Can you clarify what configuration messages you are refering to?
> >
> >  
> >
> >>If we go for a more complex prototcol, there is the choice between
> >>problem-specific protocols on one side (IPDR, LFAP, CRANE) and the
> >>more general Diameter on the other side. Diameter would be in favor
> >>if it was used widely already and anyway be implemented on 
> most boxes.
> >>Since this is not the case I would go for problem-psecific 
> protocols.
> >>
> >>Concerning the produced flows, I clearly prefer the 
> efficient NetFlow,
> >>IPDR, and CRANE to LFAP and Diameter.
> >>    
> >>
> >
> >	I disagree. LFAP's multi-record format allows the
> >	type information to be given once for many flows. Furthermore,
> >	if bandwidth is truly an issue the incremental savings of
> >	sending type info once per session versus once per message
> >	will not solve it. A higher level of aggregation will be
> >	the solution.
> >
> >  
> >
> >>The item level comparison did not show a clear winner.
> >>
> >>Considering all this I would recommend to go for NetFlow v9. If this
> >>is not accepted because NetFlow is considered as too simple 
> or lacking
> >>functionality, I would recommend using IDPR.
> >>
> >>    Juergen
> >>
> >>--
> >>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: "Ken Sarno" <[email-masked]>
Date: Mon, 28 Oct 2002 15:03:20 -0600

As a former engineer at NARUS Inc., and current Technical
Director of IPDR Organization, I'd like to comment on the importance of
variable sampling (and the general ability to dynamically modify
accounting output).  There are a variety of load conditions and customer
preferences that cause this need to arise.

	I'd also point out the NDM-U 3.1 is one of the few solutions
that gracefully accomodates this requirement today.  Because NDM-U
documents are self-describing, the producer may alternate between
sampling intervals or even change sampling strategies entirely
midstream.  The result is guaranteed to be fully comprehensible to the
consumer.

	Note that the self-describing nature of NDM-U also ensures that
BLOBs are rarely-used; most accounting record designers expose the
record details for arbitrary consumers to decode.  The danger of BLOBs
comes from other protocols that do not offer a robust extension
mechanism - designers are then forced to use opaque BLOBs.

Ken Sarno 

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