Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review)

Simon Leinen <[email protected]>
Newsgroups gmane.ietf.ipfix
Message-ID <[email protected]>
Brian Trammell writes:
> Active and idle timeout are essentially Metering Process
> implementation-specific parameters. I suspect most MPs dealing with
> flows will have _something_ that looks like an active timeout, and
> something that looks like an idle or inactive timeout, regardless of
> what they call them.

Yes, probably, but some Metering Process implementations have more
involved heuristics than these two timeouts.

For example, the ones we use have something called "fast aging", where
flows that have accumulated less than (or equal, depending on the
hardware version :-) a configurable threshold of packets can be timed
out more aggressively, i.e. after a shorter idle period than the default
(which is used for longer flows).

This is a popular platform with an installed base worth multiple 10s of
billions of dollars.  I don't claim that they are all exporting flows.

This feature is quite useful for us, because we have many very short
flows in our network, such as those from DNS and NTP "conversations",
we collect flows without sampling, and the routers have fixed-size
hardware flow tables.  Fast aging allows us to get rid of the tinyflows
quickly.

> Exactly how active and idle timeouts are implemented, and the effect
> they have on the duration and export order of exported flows, probably
> isn't a protocol matter. So I'm not sure how specifically defined they
> need to be.

I agree.  Implementors of Metering Processes should be allowed to
differentiate themselves using more effective heuristics.

It is problematic when we start to encode assumptions about these
heuristics in standards.  If we assume that there's just an active
timeout and an idle (or inactive, I don't care) timeout, then we already
cannot capture (Netflow) implementations that are quite widely used.
-- 
Simon.
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.