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