Subject: [ipfix] Re: default transport ! and other issues

From: Nevil Brownlee <[email-masked]>
Date: Wed, 22 Oct 2003 13:07:47 +1300

Hi Mark:

> I'm not advocating avoiding the decision, just letting this rest
> for a little while and moving the ID ahead with TCP and SCTP
> defined.

As you said, sooner or later we (IPFIX WG) have to make a choice on
this.  But the draft deadline for Minneapolis is now very close, let's
get the next rev of the drafts done, and (hopefully) some of the other
issues resolved.

We'll get back to the 'selecting a default transport' issue in the
week or two before the meeting!

Speaking of other issues:

IM-1: Counters vs Integers
   Consensus seems to be  MUST for integers, MAY for counters
      (counters can be useful, but they require collectors to keep
       lots of state, and to know the counter size so as to detect 
       counter wrap)

General-2: Variable-size objects
   No clear consensus.  From items on the list, I haven't seen anything
   better than 'Info Model defines size of all objects, integer size
   in IPFIX datagrams is specified in the template for any particular
   (set of) flows.'  That seems workable.
   However, does anyone have opinions on what objects actually need  
   variable-length objects?  And how should they be be encoded / appear
   in templates?

General-3: Timestamps
   Consensus seems to be timestamps UTC-based (rather than 
   uptime-based).  Microseconds precision.
   No comment on actual format.  I still like NTP-style (32.32 binary 
   seconds) [Nevil's own opinion].  We need some discussion on this!
   
At this stage, lets have some positive contribution to help our draft
editors get their next revs in on time!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, 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: "Carter Bullard" <[email-masked]>
Date: Thu, 23 Oct 2003 10:11:42 -0400

Hey Nevil,
>    variable-length objects?  And how should they be be

I am a fan of variable length objects, say for example packet counts
and byte values.  I would like for the probe to be able to
send an 8-bit, 16-bit or 32-bit value depending on the specific
activity of a given flow, as needed.  I have implemented it by
defining an Argus record as a collection of data objects, where
each object is a TLV.  The record has a total record length, so
a reader can parse the stream without any knowledge of the contents,
and each data object, like the flow descriptor, the transport ids,
the metrics, layer specific identifiers, are in their own TLV.
I use 3, 1-byte type specifies, so I can provide enough information
for the reader to figure it out, and a 1-byte length field to
indicate how many long words are in the data object.

This gives me enough flexibility to be able to specify a
METRIC/BI-DIRECTIONAL PKT COUNT/8-BIT INT, object.  The
next record could have a METRIC/UNI-DIRECTIONAL PKT COUNT/32-BIT INT,
or a METRIC/BI-DIRECTIONAL PKT-BYTE COUNT/ 16-BIT INT.
I don't support templates, as I haven't found a need for them yet,
but if I did I would declare that the probe may include a METRIC
object in the record.  Understood that it will have a TLV structure,
since they all do, no other description is necessary, but some
may want to see the largest size allowable, which would be very
easy to accommodate.

>    seconds) [Nevil's own opinion].  We need some discussion on this!

I'm not fond of 32-bits of fractional seconds in a timestamp.
I would prefer that it be absolute uSeconds.  The precision is
simple to derive from the data, and implementation on the probe
side is pretty trivial, as there is no need for floating-point
operations to transport a record.  Don't want to have to do floating-point
in the kernel if you don't have to.  And, most OS's provide absolute
timestamps ('struct timeval') for system time, possibly for that
reason.  I have found that both are nice to have, but I use absolute
uSeconds more than fractional seconds.  As a result I would always
need to convert.

Floating point may seem convenient, but its not a good performing
data type, even in modern computers.

Carter