I'm a bit wary to step in this discussion, but anyway. Here's a little
input from an operator who has been using various variants of Netflow
over the years. Netflow is rather like IPFIX over UDP as far as
congestion (non-)handling is concerned.
Lars Eggert writes:
> On 2007-9-6, at 14:51, ext Paul Aitken wrote:
>> But for now, since we estimate that NetFlow v9 export consumes a
>> mere 2-5% of the bandwidth of a monitored channel, I consider that
>> it does fall into the "Low Data-Volume" category.
> First, do you have any data that supports that 2-5% assumption?
That looks like a "typical" rate for unsampled IPFIX. If you use
sampling, you can limit the export rate to some arbitrary fraction of
the monitored data rate.
For unsampled IPFIX in a typical configuration (with ~5-tuple flows
like (non-aggregated "inflexible") Netflow), you can always construct
traffic where each 28-byte packet generates a flow record. On Netflow
v5 these records are 48 bytes each, for IPFIX I assume it's somehow
similar.
On the other hand, the Netflow implementations I know (on routers)
have a hard limit on how fast they can create and/or export flows,
which is much lower than typical link rates. For example, our current
routers export a quarter of their (hardware) flow table every second,
and the table is limited to 256 Kflows. So they never send more than
32 Kflows per second, corresponding to roughly 12.6 Mb/s with Netflow
v5. Not a problem as long as the export traffic stays in our Gigabit
backbone. (But boy, is this traffic bursty! Which is why I'd still
prefer TCP in this case.)
> Second, 2-5% of the rate of a high-speed path may still be quite a
> bit of traffic. More importantly, the path to the IPFIX destination
> may have very different characteristics from the path on which IPFIX
> is monitoring the traffic, and the IPFIX traffic can hence
> significantly interfere with other traffic sharing that path.
> Especially because IPFIX over UDP won't reduce its send rate in
> response to congestion.
Good point.
> Note that we're not singling out IPFIX here. The forthcoming revisions
> to the syslog documents, for example, will have the following
> statement ("TLS" is "TLS over TCP"):
> Because syslog can generate unlimited amounts of data,
> transferring this data over UDP is generally problematic, because
> UDP lacks congestion control mechanisms. Congestion control
> mechanisms that respond to congestion by reducing traffic rates
> and establish a degree of fairness between flows that share the
> same path are vital to the stable operation of the Internet
> [RFC2914]. This is why the syslog TLS transport is REQUIRED to
> implement and RECOMMENDED for general use.
> The only environments where the syslog UDP transport MAY be used
> as an alternative to the TLS transport are managed networks,
> where the network path has been explicitly provisioned for UDP
> syslog traffic through traffic engineering mechanisms, such as
> rate limiting or capacity reservations. In all other
> environments, the TLS transport SHOULD be used.
> I believe a similar statement for IPFIX would be appropriate.
I wouldn't object!
--
Simon.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf