Subject: [ipfix] Nevil's IPFIX current issues

From: Nevil Brownlee <[email-masked]>
Date: Wed, 13 Aug 2003 14:25:15 +1200

Hi all:

Back in early July - when I'd just finished reading all the IPFIX drafts -
I sent out a list of issues which I thought needed some discussion.
There was some discussion on some of the issues, but not a lot.  Now that
we've had a chance to recover from IETF, it's time to get back to work
on the drafts, we need to rev them at least once or twice between now and
mid-October.  

The following is my current issues list, I've added one on 'default transport
protocol.'  Please think about these, and send some comment/opinion to the
list.

Ng1: Timestamps
Drafts: Protocol, Info Model

>      a) How many bytes do we really need?  If seconds is precise enough,
>         4 bytes is fine.  If we need more, or should we could go to 8?
>      b) If we feel that we can afford 8-byte precision, what time base
>         should we use, sysUpTime or time of day.  Time of day would mean
>         that collectors didn't have to convert from sysUpTime.  Can we
>         assume that Metering Processes will have a reliable time-of-day
>         clock?
>      c) Format of 8-byte times.  The most common Unix one is (sec, usec).
>         (sec, nsec) is also widely available.  My favourite is
>         (sec, binary fraction of sec) [NTP 64-bit timestamp, Section
>         3.1 of RFC 1305], because you
>         can compute time differences with a single 64-bit subtraction.

There wasn't much reaction, but the few who did respond said yes,
we need better resolution than seconds.  That implies that the answer 
to (a) is "8-byte timestamps."

Now we need to decide on (b) and (c).  For (b), I'd like to see
Unix-epoch times (i.e. relative to 1 Jan 1970) in UTC timezone.
Anyone care to offer a different position on that?
[Note that where an IPFIX metering process doesn't have access to
an ntp-synchronised (or GPS-synchronised, CDMA-synchronised, etc.)
clock, IPFIX collectors - which I presume will at least have an
ntp-synchronised clock - can verify that the reported timestamps
aren't too far away from actual time.]

As for the timestamp data type, I'd still like to see IPFIX use the
NTP 64-bit format.  It's easy to get seconds from that (the high-order
32 bits), and the metering process can fill in as many of the low-order
bits as its clock will allow.  That makes it a clean, universal 
timestamp data type.
Failing that, another possibility would be a Unix timeval, (seconds 
in the high-order 32 bits, and microseconds in the low-order 32).
What do others, particularly implementors of IPFIX meters and
collectors, prefer?
[We need to decide this, it needs to go into the drafts now!]

Ng-2: Encoding for variable-length data types
Drafts: Protocol

There's been a little discussion of byte ordering, let's agree on
network byte order.

>                                                               For the
>      variable length fields, there seemed to be some discussion around
>      the use of 1,2 or 4 byte length indicators.   There also remains
>      the question of whether or not padding is used for any sort of
>      word alignment.

This one hasn't been discussed further.  Let's hear your opinion now!
Which flow attributes will be variable-length?
The Info Model draft only has one variable-length type, 'string,'
i.e. a UTF8 string.  Can someone please tell us how that should be 
carried on the wire - e.g. first byte carries the length, followed
by the data bytes.  Or what?

Ng4: Flow Sampling.  
Drafts: Architecture, ?

>      This is mentioned in both the Requirements I-D
>      and the AS I-D.  We need to decide how it should be covered in the
>      IPFIX drafts.

No discussion on this one so far.  But it could be a useful tool
to reduce the amount of flow data one needs to export/collect.
Comments?  Suggestions??

Ng5: IPFIX Default Transport Protocol
Drafts: Protocol

I went to the NETCONF WG session at the Vienna IETF; they have a list
of three transport protocols which would be suitable for NETCONF.  They
discussed the question of whether one of them should be the NETCONF
default, i.e. a 'MUST implement,' and if so, which one.  We need to
consider this question for IPFIX.

When I asked our Area Directors about this, they both said that IPFIX
ought to have a default transport protocol, so that users know they
can plug in an IPFIX device and have it work with other IPFIX devices.

The question now is, which protocol?  The candidates available now
are SCTP and TCP.  Now's the time to send your opinions (with reasoned
technical arguments) to the list so that we can form a WG consensus!

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: "Tal Givoly" <[email-masked]>
Date: Wed, 13 Aug 2003 09:47:23 -0700

Hi,

Ng-1: Timetamps:
- I'd prefer 8-byte time, may allow some detection of ordering of packets
within the second at minimal expense.
- Base should be current time rather than sysUpTime as has more benefit and
avoid conversion and logic at collector. Using sysUpTime requires also
another interface to the device to detect offset of sysUpTime.
- Format - both 8-byte options have pros/cons and either would work.

Ng-2: Encoding:
- Byte order: I too support the forming consensus regarding network byte
order.
- Length for fields of known length should be spared. This is especially
true for "small" fields. Anything known to be 1, 2, 4, 8 or 16 bytes in
length should be implicit from its identifier. It would be best if the
identifier value implicitly indicates to the collector whether the field is
of fixed or variable length. For instance, a range of identifiers could be
used for known-length values while another range could be used for
variable-length values.

Ng-5: Default Transport:
- For cost-effective interoperability we should have a default that is known
to be supported = mandatory.
- Obviously, TCP is still more appropriate than SCTP to allow a wide variety
of collectors to adopt IPFIX quickly.

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Nevil Brownlee
Sent: Tuesday, August 12, 2003 7:25 PM
To: [email-masked]
Subject: [ipfix] Nevil's IPFIX current issues

Hi all:

The following is my current issues list, I've added one on 'default
transport
protocol.'  Please think about these, and send some comment/opinion to the
list.

Ng1: Timestamps

Ng4: Flow Sampling.
Drafts: Architecture, ?

Cheers, Nevil

--
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/