Re: [IPFIX] Export of long lived flow information

[Paul Aitken <[e-mail]>]

Gerhard,

I agree with your definitions. Thanks for clarifying.

So what's the next step?

     * Update the IANA definitions?
     * Add clarifications to the WG documents?


Do we need a short presentation at the upcoming WG meeting?

P.


On 30/10/12 11:51, Gerhard Muenz wrote:
> Paul,
>
> On 26.10.2012 20:20, Paul Aitken wrote:
>> Andrew, Gerhard,
>>
>>>> My understanding is that both, deltaCounts and totalCounts contain 
>>>> the number of packets or octets observed in the indicated time 
>>>> interval. So, for identical flowStart* and flowEnd* timestamps, the 
>>>> values are the same.
>>> This is my understanding as well.
>>
>> There has to be a difference between delta and total counts, else we
>> wouldn't have both of them!
>>
>> Suppose we have a permanent cache, so the cache entries never expire.
>>
>> For a new flow starting at t0 with a first export at t1, the
>> timestamps, delta, and total counts are the same.
>>
>> However with the second export at t2, the total and delta counts are
>> different although their timestamps match (they'll both say, "t0 to
>> t2").
>
> No, this would contradict the new definition of flowStart* we are just 
> discussing.
> If delta counts are exported for the interval (t1,t2), then flowStart* 
> is t1.
> If delta counts are exported for the interval (t0,t2), then flowStart* 
> is t0.
> If total counts are exported, flowStart is always t0.
> These statements hold regardless of which type of cache is used by the 
> Metering Process. In general, the information model does not care 
> about how the cache is implemented. The exported information just must 
> follow the IE definition.
>
>>
>> With the traditional (non-permanent) cache, the entry would probably
>> have been removed at t1 and re-created on a subsequent packet, so at
>> t2 the delta and total counts would both be equal. However it'd be
>> incorrect to report the total count, because that's defined as the
>> total number of packets or bytes ..."since the Metering Process
>> (re-)initialization for this Observation Point".
>
> You must not export total counters in this case because you reset 
> counters before re-initialization of the Metering Process.
>
> Thanks,
> Gerhard
>
>>
>>
>>>> However, the description of totalCounts says that you report the 
>>>> number of packets or octets observed for this Flow since 
>>>> re-initialization. So, you must never reset the counter for this 
>>>> Flow, even after observing a FIN or RST.
>>>> If you reset flow counters, or if you remove Flows from your Cache, 
>>>> you cannot use totalCounts any more unless you re-initialize the 
>>>> Metering Process (e.g. after flushing the entire permanent Cache).
>>>
>>> I can try some tests later, but from what I have seen (and been 
>>> told) many totals being exported are in fact just a delta sent once 
>>> at the end of the flow.  If a later flow had the same IPs, protocol, 
>>> and ports as an earlier flow I'm pretty sure a new start time will 
>>> be sent rather than the the first time that flow was seen since 
>>> reinitializing the metering process.
>>
>> So the MP uses a traditional (non-permanent) cache. In RFC 6728
>> terms, a TimeoutCache or NaturalCache rather than a PermanentCache.
>>
>>
>>> Or to put it an other way I think deltas are being sent, but called 
>>> totals by the implementation because it seemed like the right thing 
>>> to do for a value being sent once at the end of the flow.
>>
>> The collector could be aggregating deltas to keep running totals.
>>
>>
>>> I suspect that totals reporting on the export process (eg 
>>> exportedOctetTotalCount, exportedMessageTotalCount) are, however, 
>>> reported with a start time that is only reset on reinitialization.
>>
>> Definitely, because these are defined as "The total number of X that
>> the Exporting Process has sent since the Exporting Process
>> (re-)initialization ...".
>>
>> P.