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

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Apr 2012 13:07:51 +0200

Dear all,

Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft 
defines two new terms: Active Timeout and Inactive Timeout.
I was thinking: surely, we have defined those terms already in some 
IPFIX RFCs.
Actually, I was unable to find any references.... Have I overlooked 
something?

The only pointers I could find are in RFC5102

        5.11.1. flowActiveTimeout

    Description:
       The number of seconds after which an active Flow is timed out
       anyway, even if there is still a continuous flow of packets.
    Abstract Data Type: unsigned16
    ElementId: 36
    Status: current
    Units: seconds

        5.11.2. flowIdleTimeout

    Description:
       A Flow is considered to be timed out if no packets belonging to
       the Flow have been observed for the number of seconds specified by
       this field.
    Abstract Data Type: unsigned16
    ElementId: 37
    Status: current
    Units: seconds

        5.11.3. flowEndReason

Description:
       The reason for Flow termination.  The range of values includes the
       following:

       0x01: idle timeout
             The Flow was terminated because it was considered to be
             idle.

       0x02: active timeout
             The Flow was terminated for reporting purposes while it was
             still active, for example, after the maximum lifetime of
             unreported Flows was reached.

       ...

Here is one issue.
Some documents refer to inactive timeout
     RFC5472,
     ipfixMeteringProcessCacheInactiveTimeout in 
http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
     inactiveTimeout in 
http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10
While some others refer to idle timeout
     RFC 5102,
     draft-ietf-bmwg-ipflow-meth-09

Any proposal to fix this problem?

Regards, Benoit (OPS A.D.)

---

From: "Jan Novak (janovak)" <[email-masked]>
Date: Tue, 10 Apr 2012 13:17:45 +0200

Hi,
I have checked the IPFIX documents at the time and couldn't
find any definitions while there was a need for them for
the BMWG document - so that's why it is there.
The definitions are quite cumbersome to develop (as you
as well might remember :-)) and still are to some
extent controversial (or every reviewer so far
picked at them).

Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

From: Benoit Claise (bclaise) 
Sent: 10 April 2012 12:08
To: [email-masked]
Cc: Jan Novak (janovak); Ron Bonica; Al Morton
Subject: No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review)

Dear all,

Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft defines two new terms: Active Timeout and Inactive Timeout.
I was thinking: surely, we have defined those terms already in some IPFIX RFCs.
Actually, I was unable to find any references.... Have I overlooked something?

   Description:

5.11.2.  flowIdleTimeout

   Description:

5.11.3.  flowEndReason
Description:

      0x01: idle timeout

      0x02: active timeout

      ...

Here is one issue.
Some documents refer to inactive timeout
    RFC5472, 
    ipfixMeteringProcessCacheInactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
    inactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10
While some others refer to idle timeout
    RFC 5102, 
    draft-ietf-bmwg-ipflow-meth-09

---

From: Brian Trammell <[email-masked]>
Date: Tue, 10 Apr 2012 13:19:38 +0200

Hi, Benoit, all,

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

"Active" seems to be "active" everywhere. The choice of picking idle or inactive would seem then to be arbitrary. Given that 5102 predates all other (directly-IPFIX-related) references, and there's an IE in the IANA registry called flowIdleTimeout, I'd tend to go with "idle" for this one.

As to _where_ and _how_ to define these, I don't know, and as little as possible.

Cheers,

Brian

On Apr 10, 2012, at 1:07 PM, Benoit Claise wrote:

> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 10 Apr 2012 18:34:15 +0200

Hi Benoit,

The parameter was always called inactive timeout in IPFIX MIB. 
ipfix-config changed from idleTimeout to inactiveTimeout in 
draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB.

We could change the name in the MIB and in ipfix-config if consistency 
is important.

Gerhard

---

From: Simon Leinen <[email-masked]>
Date: Tue, 10 Apr 2012 22:42:00 +0200

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.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 11 Apr 2012 17:25:31 +0200

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

---

From: "Jan Novak (janovak)" <[email-masked]>
Date: Sat, 14 Apr 2012 22:58:03 +0200

>draft-ietf-bmwg-ipflow-meth-09

I have checked (word searched) and there is no single
occurrence of word "idle" in draft-ietf-bmwg-ipflow-meth-09.
The terminology active/inactive seemed to be at least
historically most justified or we simply never used anything
else ...

Jan

---

From: Benoit Claise <[email-masked]>
Date: Wed, 18 Apr 2012 12:51:10 +0200

Dear all,

I believe that consistency is important amongst all the IPFIX documents.
What Brian expressed "Given that 5102 predates all other 
(directly-IPFIX-related) references, and there's an IE in the IANA 
registry called flowIdleTimeout, I'd tend to go with "idle" for this 
one." is I believe the right way forward.
And Gerhard mentioned " We could change the name in the MIB and in 
ipfix-config if consistency is important."

So let me propose the following:
- http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, in 
the RFC-editor queue:
     we could still change inactive to idle
- http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the 
RFC-editor queue
     we could still change inactive to idle
- Editorial errata on RFC5472:
     "inactive" -> "idle"
     Potentially, an extra sentence such as: "note that the idle timeout 
is sometimes called the inactive timeout in the industry"
- http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt
     replace inactive by idle.

Any objections?

Regards, Benoit.
>> Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this 
>> draft defines two new terms: Active Timeout and Inactive Timeout.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 18 Apr 2012 17:02:18 +0100

Benoit,

Good plan; no objection.

P.

On 18/04/12 11:51, Benoit Claise wrote:
> - http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, 
> in the RFC-editor queue:
>     Potentially, an extra sentence such as: "note that the idle 
> timeout is sometimes called the inactive timeout in the industry"
>> We could change the name in the MIB and in ipfix-config if 
>> consistency is important.
>>
>> Gerhard
>>
>>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 18 Apr 2012 18:11:27 +0200

Hi, Benoit,

Sounds good to me.

Cheers,

Brian

On Apr 18, 2012, at 12:51 PM, Benoit Claise wrote:

> What Brian expressed "Given that 5102 predates all other (directly-IPFIX-related) references, and there's an IE in the IANA registry called flowIdleTimeout, I'd tend to go with "idle" for this one." is I believe the right way forward.
> And Gerhard mentioned " We could change the name in the MIB and in ipfix-config if consistency is important."
> 
> - http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, in the RFC-editor queue:
> - http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the RFC-editor queue
>     Potentially, an extra sentence such as: "note that the idle timeout is sometimes called the inactive timeout in the industry"
>> The parameter was always called inactive timeout in IPFIX MIB. ipfix-config changed from idleTimeout to inactiveTimeout in draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB.
>> 
>> We could change the name in the MIB and in ipfix-config if consistency is important.
>> 
>> Gerhard
>> 
>>

---

From: Andrew Feren <[email-masked]>
Date: Thu, 19 Apr 2012 09:14:41 -0400

Hi Benoit, all,

No objection, however, given how common the term "inactive timeout" is 
in the industry that including a note like you suggested is probably 
worth doing.

-Andrew