Subject: [ipfix-protocol] Timing - section 9

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Nov 2004 17:05:20 +0000

I am wondering if the text of section 9 (Export Packet
"Export Time" Computation and Flow Record Time) should
be in the protocol draft at all. This is really the detailed
definition of a number of information elements, and
as such should be in the information element draft.

The timing component has always been controversial due
to the conflict between the need to have a timing
"dynamic range", and the need to compress the exported
data. Moving the text to the IE draft would allow
timing information to be better tailored to the
application, by allowing the user to select a timing
element that best matched their needs.

It may be necessary to include some text in a new
protocol draft section 9 that describes some brief
implementation notes, such as the need to ensure that
there are no timing conflicts between the records
contained within an IPFIX Message.

I think that this approach would allow us maximum
flexibility in the design and implementation of the
protocol, because it does not define any default
timing behaviour.

- Stewart

--
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: Juergen Quittek <[email-masked]>
Date: Mon, 29 Nov 2004 16:33:10 +0100

Hi Stewart,

I agree that the definition of timer semantics should be
moved to the info model document.

There we should distinguish timer elements by

  - their precision
      - seconds
      - milliseconds
      - microseconds
      - nanaseconds

Currently, we have just two precisions supported:
dateTimeSeconds and dateTimeMicroSeconds.  And currently
both use GMT/UTC as time base.

Reading section 9 of the protocol spec, we need also data
types for time offset values.

This would end up to eight data types:

GMT/UTC-based time values in four precisions:
  dateTimeSeconds
  dateTimeMilliSeconds
  dateTimeMicroSeconds
  dateTimeNanoSeconds

Time offset values in four precisions:
  timeIntervalSeconds
  timeIntervalMilliSeconds
  timeIntervalMicroSeconds
  timeIntervalNanoSeconds

For the offset values we need to specify if they are
always signed or unsigned.

All in all we would extend the two data types for times we have
already to a set of eight.  Are all eight required?

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: Juergen Quittek <[email-masked]>
Date: Mon, 29 Nov 2004 16:42:39 +0100

Stewart,

> contained within an IPFIX Message.

I am not sure these implementation notes belong into
a protocol specification document.  I would see them rather
as part of a (future) implementation guideline document.

Rather than giving code on how a time base for time offset
values is computed, the protocol draft should specify
how time bases are set (header of the IPFIX message)
and what is their scope (offset time values in the
records).

Thanks,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Nov 2004 11:27:03 +0100

> already to a set of eight.  Are all eight required?

I'm not sure. The section 9 doesn't require:
- timeIntervalSeconds,
- timeIntervalNanoSeconds (because dateTimeNanoSeconds would use anyway 
a 64 bits counter. So we don't gain anything)

Regards, Benoit.