Subject: [ipfix-protocol] PROTO-23: time details

From: Paul Aitken <[email-masked]>
Date: Sun, 24 Oct 2004 13:20:56 +0100

Hi.

Benoit and I have been looking at the PROTO-23 issue:

   PROTO-23: Finalize the time details. The time-related Information
   Elements are not defined in [IPFIX-INFO]

We discovered some problems with section 9.1, and a way to enhance the 
mechanism.

Let's make a distinction between the one pass method (as described in 
the pseudo code of section 9.1) and the two pass approach (also 
described in section 9.1).

1. First of all, the following sentence is incorrect!

   "For a Data Set with Flow Records requiring microsecond precision,
   the Export Packet "Export Time" field MUST be calculated so that
   each Flow Records flowStartUsec [IPFIX-INFO] and flowEndUsec [IPFIX-
   INFO] would contain a 32 bit signed microsecond offset from the
   "Export Time" base timestamp."

Although not explicitly stated in the text, with the one pass approach 
we have a signed offset which could be positive or negative.

Let's imagine this scenario:

- the first flow record is ready to be exported. Its start time is used 
as the base time in the IPFIX Message Header.
- a second flow record is ready to be exported. This flow record started 
before the first one. So the startup delta time is actually negative.

2. Secondly, let's have a look at the next sentence which is not correct 
for the one pass approach!

    "Flow Records MUST be exported in different Export Packet if the 
absolute duration can not fit in those 35 minutes."

Note: a signed 32 bit value gives a range of +/- 35 minutes.

Let's imagine this scenario:

_Scenario 1_:

- the first flow record is ready to be exported. Its start time is used 
as the base time in the IPFIX Message Header.
- a second flow record is ready to be exported. This flow record started 
30 minutes after the first one, and last for 10 minutes. So the startup 
delta time as stored in the flow record will be 30 minutes.

What could be the maximum flow duration if we want to put it in the same 
export packet? Only 5 minutes!

So the text above isn't exact, since this flow's absolute duration does 
fit inside the 35 minutes, but it would need to be exported in a 
different export packet with a new base timestamp in the IPFIX Message 
Header.

Let's imagine another scenario:

_Scenario 2_:

- the first flow record is ready to be exported. Its start time is used 
as the base time in the IPFIX Message Header.
- a second flow record is ready to be exported. This flow record started 
30 minutes before the first one (as we showed in scenario 1). So the 
startup delta time as stored in the flow record will be -30 minutes.

What could the maximum flow duration be if we want to put it in the same 
export packet? 30 minutes + 35 minutes!

- In this case the flow duration was 60 minutes ...

_
Conclusions_:

- This sentence "Flow Records MUST be exported in different Export 
Packet if the absolute duration can not fit in those 35 minutes" is 
wrong. We can't conclude anything about the maximum flow duration as it 
depends only on the relative flow start time between the first flow 
record and the other flow records to be exported.

- Since the flow record end time is always greater than or equal to the 
flow record start time, it's more intuitive for flowEndUsec to be a 
positive offset of 0 to 71 minutes from flowStartUsec, thus allowing 
flows to be up to 71 minutes long regardless of the base timestamp in 
the IPFIX Message Header. The only condition is the flow records start 
time MUST be in the range [-35 minutes,+35 minutes] compared to the 
start time of the first flow record in the export packet, that is the 
IPFIX Message Header base time.

3. THE TWO PASS APPROACH IS BETTER WITH THE MINIMUM TIME INSTEAD OF THE 
AVERAGE.

Thirdly, the two pass approach can be improved.

   "A two pass approach calculation for the optimum (center) "Export
   Time" base timestamp would allow an absolute duration of 71 minutes
   for all Flow Records contained in the Data Set."

Instead of calculating the optimum center, we could simply record the 
lowest start time of all the flow records, which would be the base time 
for IPFIX Message Header.

This mechanism gives the following advantages:
- no need to calculate the optimum center (i.e. less computation).
- would be inline with the proposal in point 2.
- would directly return the flow duration in flowEndUsec, which BTW 
could be renamed to flowDurationUsec.

While these observations are targeted for section 9.1, these are valid 
also for section 9.2 as section 9.2 refers to section 9.1.

Any feedback before we propose some new text?

Regards,
    Benoit and Paul.