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

Hi, Simon, all,

Agreed.

The question of what should the protocol assume about the capabilities of _all_ Metering Processes attached to compliant Exporting Processes is, I think, separate from what we want to be able to represent using the protocol. We already have the idle and active timeout IEs, which can at least be used by fast aging implementations to report an _incomplete_ picture of their configuration. (Indeed, a fast aging implementation _could_ export a per-flow flowEndReason "idle" and flowIdleTimeout "4 sec" to report which flows were fast aged if it wanted to. Each flow could even have its own active and idle timeouts. But the efficiency of this approach is questionable.)

The question of what we want to be able to report about _specific_ metering processes is an interesting one which we have left to metering process vendors, to date. We actually had a side discussion on this a while ago, I think in Maastricht: knowing specific information about the metering and exporting processes and their configuration helps in interpreting the data they produce. Each exporter would have an exporter profile, which could be sent inline with options, and kept with the data at the collector side.

As to how to actually do this, you'd have to get very specific about the capabilities and configurations represented. However, an exercise using something like the configuration data model as a basis, and allowing for vendor-specific extensions, might be worth the effort.

Cheers,

Brian

On Apr 10, 2012, at 10:42 PM, Simon Leinen wrote:

> 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