Re: [IPFIX] Export of long lived flow information

Hi all,

I scanned through the IANA registry and briefly checked occurrences of 
"this Flow". I do not think that we need change them in general, except 
for those IEs which define a measurement interval.

So, we have:
- flowStart* (including flowStartDeltaMicroseconds)
- flowEnd* (including flowEndDeltaMicroseconds)
- flowDuration*

My first shot was the following change for absolute flowStart*/flowEnd* 
timestamps:

OLD:
The absolute timestamp of the first|last packet of this Flow.
NEW:
The absolute timestamp of the first|last packet accounted in this Flow 
Record.

We could add a sentence clarifying that the Flow properties reported in 
this Flow Record refer to the given measurement interval.
At the moment, I only find a good "negative" way to describe this:
"If this Information Element is present in a Flow Record, Flow 
properties in this Flow Record do not refer to packets 
preceding|succeeding this timestamp."

Do you have better suggestions?
Or do you think that this clarification is not necessary?

Regards,
Gerhard


On 30.10.2012 13:38, Brian Trammell wrote:
> Hi, Paul, all,
>
> If someone throws together a quick summary of the position for me I'd
> be happy make a couple of slides and do the presentation in person in
> Atlanta.
>
> From where I sit, it looks like we just go ask IANA to make the
> registry change. Wearing my IE-Doctors-author hat (I can't wear an IE
> Doctor hat, there aren't any yet. :) ), I'd say this revision would 
> be
> covered (and permissible) under point 2 in section 5.2 of ie-doctors.
>
> Best regards,
>
> Brian
>
>
> On 30 Oct 2012, at 13:21 , Paul Aitken wrote:
>
>> 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.
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix

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