Subject: [ipfix] 'Export Time' and deltaTime elements

From: Nevil Brownlee <[email-masked]>
Date: Fri, 11 Mar 2005 17:47:27 +1300

Hi all:

<WG chair hat off>

Thinking about this after today's meeting, my opinion is that

 - we should keep Export Time in the IPFIX Message Header to mean
   the time (in Unix epoch seconds) when the message was sent, and

 - deltaTime elements should be unsigned32 values, representing
   the *negative* offset of the times.  For example, flowStartDeltaSeconds
   is the number of seconds *before* the Export Time that the IPFIX
   Metering Process saw the first packet of a flow.

Of course it means that before an Exporter sends out a message it
has to go through it and compute all the delta values, but surely
it would have to do that no matter what we chose as the Eport Time?

</WG chair hat off>

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Mar 2005 21:09:09 +0100

Hi Nevil,

I agree that allowing unsigned information elements is the best 
solution, as there is no constraint (A lower or higher "Export Time") on 
the protocol due the information elements definition, and the Export 
Time gives some more information.
Furthermore, it allows the IPFIX implementors to really choose what they 
want in terms of time-related information elements.
You propose flowStartDeltaSeconds, while the current draft proposes 
TimeSeconds. I'm thinking we will never have everybody happy...
Continuing the reasoning about the IPFIX implementation flexibility, I'm 
more and more convinced we should not impose rules such as the one below:

   For a Data Set with Flow Records requiring microsecond precision, 
   the IPFIX Message Header "Export Time" field SHOULD be calculated so 
   that each Flow Records flowStartDeltaUsec [IPFIX-INFO] and 
   flowEndDeltaUsec [IPFIX-INFO] would contain a 32 positive bit signed 
   microsecond offset from the "Export Time" base timestamp.

We can always find pros and cons arguments.
- Yes. It saves 8 bytes for each flow records that contains flow start and end time: my bottleneck is my bandwidth utilization
- No. It takes more cpu to compute the IPFIX Message: my bottleneck is the network element CPU
As I said: we will never have everybody happy!

If we don't impose rules, the different IPFIX implementations will either use the proposed IANA time-related information elements, or will specify new ones, according to their needs.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 17 Mar 2005 17:26:47 +0100

After re-reading my email, I realized how bad I expressed myself :(
Please excuse my trench :)

Please disregard my previous email below and let me try to clarify my 
point of view.
I like Nevil's proposal because:
- the "Export Time" is really the time at which the packet was sent
- The Information Element definitions does not impose any constraints on 
the protocol specification

Right now, IPFIX-PROTO says:

    For a Data Set with Flow Records requiring microsecond precision,  
    the IPFIX Message Header "Export Time" field SHOULD be calculated
    so  that each Flow Records flowStartDeltaUsec [IPFIX-INFO] and
    flowEndDeltaUsec [IPFIX-INFO] would contain ...

The question is: is the SHOULD appropriate?
I'm thinking we will never have everybody happy...
We can always find pros and cons arguments for a "SHOULD use 
flowStartDeltaUsec and flowEndDeltaUsec for microsecond precision", as 
opposed to report the absolute start and end time in the flow records
- Yes. It saves 8 bytes for each flow records that contains flow start 
and end time: my bottleneck is my bandwidth utilization
- No. It takes more cpu to compute the IPFIX Message: my bottleneck is 
the network element CPU
If we don't impose any rules, the different IPFIX implementations will 
either use the proposed IANA time-related information elements, or will 
specify new ones, according to their needs. However, the protocol will 
remain flexible. So I'm in favor to remove this SHOULD

Any feedback?
I'm trying to compile a new version of the draft by the end of the week.

Regards, Benoit.

> solution, as there is no constraint (A lower or higher "Export Time") 
> on the protocol due the information elements definition, and the 
> Export Time gives some more information.
> Furthermore, it allows the IPFIX implementors to really choose what 
> they want in terms of time-related information elements.
> Continuing the reasoning about the IPFIX implementation flexibility, 
> I'm more and more convinced we should not impose rules such as the one 
> below:
>
> - Yes. It saves 8 bytes for each flow records that contains flow start 
> and end time: my bottleneck is my bandwidth utilization
> If we don't impose rules, the different IPFIX implementations will 
> either use the proposed IANA time-related information elements, or 
> will specify new ones, according to their needs.
>
> Regards, Benoit.
>
>> Hi all:
>>
>> <WG chair hat off>
>>

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 18 Mar 2005 09:04:43 +1300

> remain flexible. So I'm in favor to remove this SHOULD

I like the notion of having 'Export Time' meaning exactly that, i.e.
the time in Unix-epoch seconds that the message was exported.

Delta times will always need to be calculated just before a message
is exported, once the Export Time has been determined.

As Benoit said, 
 - If you want minimal bytes in the data stream, use delta*.  That
   means you have to compute the deltas, and you have to live with
   their range restriction (not too bad for us, a potential problem
   for ns precisions).
 - If you want timestamp precision and no range restrictions, use one
   of the 'timestamp' Information Elements.  Then you have to live
   with 8-byte timestamps in your IPFIX messages.  (BTW, I still
   prefer NTP-style format for those :-)

I agree with Benoit that we should change the paragraph he quoted above,
so that it doesn't say SHOULD, but instead outlines the points in my
text above.

Cheers, Nevil

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 17 Mar 2005 22:22:50 +0100

Dear all,

> so that it doesn't say SHOULD, but instead outlines the points in my

I prefer to change section 6.1 back from

OLD:
   Export Time
           Time in seconds since 0000 UTC 1970, at which the IPFIX
           Message Header leaves the Exporter.  Alternatively, the
           Export Time can be a computed value: see the section 8
           "IPFIX Message Header "Export Time" and Flow Record Time".

to NEW:
   Export Time
           Time in seconds since 0000 UTC 1970, at which the IPFIX
           Message Header leaves the Exporter.

Then section 8 should just discuss how delta timers can use the Export
Time without affecting the value of this field.
If the range of 32 bit does is not enough, then absolute time
stamps can be used.

    Juergen

---

From: Lutz Mark <[email-masked]>
Date: Fri, 18 Mar 2005 11:26:41 +0100

Dear all,

> If the range of 32 bit does is not enough, then absolute time

Yes this really makes the draft cleaner
(if we want to keep section 8 like discussed).

Before we close that issue ...

The 32bit timestamp in the header of the ipfix message
will only suffice until 2038. The timestamp is a legacy
from netflow and is not needed for the IPFIX protocol.
We simply used it as an information element that is
common to all records of the same ipfix message.

What about making the timestamp optional. Maybe
we can use a method similar to IPv6 headers. Then
we can define 32 and 64 bit export time as common
information elements. We can use 32 bit now and can
simply change to 64 bit in some years.

Any comments?

Best regards,
Lutz

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Mar 2005 16:47:39 +0100

>so that it doesn't say SHOULD, but instead outlines the points in my
What about this proposal?
_IPFIX Message Header __"Export Time" and Flow Record Time _
 
The IPFIX Message Header "Export Time" field is the time in seconds 
since 0000 UTC 1970, at which the IPFIX Message Header leaves the 
Exporter.  The timing related Information Elements specified in 
[IPFIX-INFO] contain either the time since 0000 UTC 1970, or either a 
time offset compared to the IPFIX Message Header "Export Time".

For example, Data Records requiring a microsecond precision can export 
the flow start and end times with the absolute flowStartMicroSeconds and 
flowEndMicroSeconds Information Elements [IPFIX-INFO], containing the 
time since 0000 UTC 1970.  An alternate solution is to export the 
flowStartDeltaUSeconds and flowEndDeltaUSeconds Information Elements 
[IPFIX-INFO] in the Data Record, which respectively report the flow 
start and end time offsets compared to the IPFIX Message Header "Export 
Time".  The latter solution lowers the export bandwidth requirement 
while it increases the load on the Exporter as the Exporting Process 
must calculate the flowStartDeltaUSeconds and flowEndDeltaUSeconds of 
every single Data Records before exporting the IPFIX Message.  
 
It must be noted that using time-related Information Elements with 
offset times compared to the IPFIX Message Header "Export Time" imposes 
some time constraints on the Data Records contained in the IPFIX 
Message.  In the example of flowStartDeltaUSeconds and 
flowEndDeltaUSeconds Information Elements [IPFIX-INFO], the Flow Record 
must be exported maximum 71 minutes after its creation. Otherwise, the 
32 bits counters would not be sufficient to contains the flow start time 
offsets.  

Regards, Benoit

---

From: Nevil Brownlee <[email-masked]>
Date: Sun, 20 Mar 2005 04:06:53 +1200

> simply change to 64 bit in some years.

This sounds reasonable.  I think the timestamp(i.e. Export Time)
is useful (you need it if you're using deltaTime elements), so we 
shouldn't drop it from the IPFIX Message header.  

Allowing for a 64-bit timestamp would most simply be done by changing 
the version number.  For example;
  Versions    1 .. n  have a 32-bit Export Time
  Veersions n+1 .. *  have a 64-bit Export Time

Since new versions will need to be introduced by making a new
standards-track RFC, the IFPIX WG can do that some time closer
to 2038!

Cheers, Nevil

---

From: Nevil Brownlee <[email-masked]>
Date: Sun, 20 Mar 2005 05:07:05 +1200

> 32 bits counters would not be sufficient to contains the flow start time

Yes, that's fine with me.

Cheers (and thanks), Nevil

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 21 Mar 2005 14:05:05 +0100

>> since 0000 UTC 1970, at which the IPFIX Message Header leaves the

I think we also need to specify the day in 1970.

>> time offset compared to the IPFIX Message Header "Export Time".

I don't think the protocol should limit the allowed time base for the info
model by restricting the absolute time base to 0000 GMT Jan 1st 1970.

I suggest more general phrasing for the first paragraph:

   The IPFIX Message Header "Export Time" field is the time in seconds
   since 0000 UTC Jan 1st, 1970, at which the IPFIX Message Header
   leaves the Exporter.  Time stamps in records contained in the IPFIX
   Message may use this time as base time and specify an offset relative
   to the Export Time instead of using a full absolute time stamp.

So far, we have in Section 6.1 (Message Header) only short one-paragraph
descriptions of the header fields without examples.  I prefer keeping
this style and having just a basic paragraph on the Export Time here.
The explanation how relative time stamps can use the Export Time
including the examples would better be located in a separate (sub-)section
titled "Relative Timestamps" or similarly.  We can point to this section
from the description of the Export Time header field by appending to it
a reference like

    The Export Time can be used by relative time stamps as described
    in section XY.

>> time since 0000 UTC 1970.  An alternate solution is to export the

Again, the day needs to be specified.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Mar 2005 15:20:51 +0200

Hi Juergen,

> I think we also need to specify the day in 1970.

Changed to "0000 UTC Jan 1st 1970"
Some more instances of this UTC time changed in the draft.

> model by restricting the absolute time base to 0000 GMT Jan 1st 1970.

You are right. This limitation doesn't make sense.

>   to the Export Time instead of using a full absolute time stamp.

Modifying slightly the text but not the idea, I propose:

  The IPFIX Message Header "Export Time" field is the time in seconds
  since 0000 UTC Jan 1st, 1970, at which the IPFIX Message Header
  leaves the Exporter.  The time related Information Elements specified 
in [IPFIX-INFO]
  MAY use this "Export Time" as base time and specify an offset relative
  to it,  instead of using Information Element with a full absolute time 
stamp.
  For the time related Information Elements using an offset,  its 
description MUST
  clearly specify the reference time.

> Again, the day needs to be specified.

Done.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 30 Mar 2005 23:08:20 +0200

Hi Benoit,

I'm fine with this text except a few minor issues:

>   leaves the Exporter.  The time related Information Elements specified in [IPFIX-INFO]
>   to it,  instead of using Information Element with a full absolute time stamp.

I am not sure the "instead" phrase matches the main sentence.  I suggest

  "instead of using Information Element with a full absolute time stamp."
  -> "instead of using a common base time, such as 0000 UTC Jan 1st, 1970.

>   For the time related Information Elements using an offset,  its description MUST

In the previous sentence, we called it "base time":  "reference" -> "base"
But I would rather prefer the following sentence:

  "All Information Elements that does not have their base time defined by their
   data type, MUST have the base time clearly specified in the their description."

For the native speakers/writers: is it "time related" or time-related"?

Thanks,

    Juergen

---

From: Robert Lowe <[email-masked]>
Date: Wed, 30 Mar 2005 15:21:28 -0600

> For the native speakers/writers: is it "time related" or time-related"?

I suppose it's open to debate, but I prefer "time-related" when used
as an adjective.  BTW, the sentence would flow better as:

Any Information Element using an offset MUST clearly specify the reference
time in its description.

-Robert

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Mar 2005 23:52:06 +0200

Juergen,

Done deal, with "time-related" instead of "time related" (thanks Robert):

  The IPFIX Message Header "Export Time" field is the time in seconds
  since 0000 UTC Jan 1st, 1970, at which the IPFIX Message Header
  leaves the Exporter.  The time-related Information Elements specified 
in [IPFIX-INFO]
  MAY use this "Export Time" as base time and specify an offset relative
  to it,  instead of using a common base time, such as 0000 UTC Jan 1st, 
1970.
  All Information Elements that does not have their base time defined by 
their
  data type, MUST have the base time clearly specified in their description.

Regards, Benoit.

---

From: Robert Lowe <[email-masked]>
Date: Wed, 30 Mar 2005 16:03:39 -0600

Benoit Claise wrote:

Hi Benoit,

>  data type, MUST have the base time clearly specified in their description.

The last sentence has the wrong conjugation -- either 'does' has to be 'do'
or the preceeding plural should an indefinite form/singular which then forces
'their' to change to 'its'.  :-)

-Robert