Subject: [ipfix] Re: unit of flow creation and end time /RFC3954

From: Juergen Quittek <[email-masked]>
Date: Fri, 18 Mar 2005 14:54:21 +0100

Emile,

--On 18.03.2005 12:18 +0100 STEPHAN Emile RD-CORE-LAN wrote:

> Hi,
>
> I agree with the need of delta time. It seems that a point might be clarified before:
> 	Section 8 of RFC3954 defines the unit of the fields ID 21 and 22 as msec;
> 	info model 06 and pre-07 defines the unit of the fields ID 21 (flowEndTime) and 22 (flowCreationTime)
 as dateTimeSeconds;

Thank you for pointing this out.

Indeed this is a mistake.
Information Elements 21 and 22 are intended to be compatible
with NetFlow v9 which uses milliseconds for these numbers.

Consequently we need to change the element numbering in the info model

from OLD

   |    22 | flowStartSeconds        |
   |    21 | flowEndSeconds          |
   |   150 | flowStartMilliSeconds   |
   |   151 | flowEndMilliMSeconds    |

to NEW

   |   150 | flowStartSeconds        |
   |   151 | flowEndSeconds          |
   |    22 | flowStartMilliSeconds   |
   |    21 | flowEndMilliMSeconds    |

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

> Which one is the right one?
>
> Regards
> Emile
>
> -----Message d'origine-----
> De : majordomo listserver [mailto:[email-masked]] De la part de Juergen Quittek
> Envoyé : jeudi 17 mars 2005 22:23
> À : Nevil Brownlee; Benoit Claise
> Cc : [email-masked]
> Objet : Re: [ipfix] 'Export Time' and deltaTime elements
>
> Dear all,
>
> --On 18.03.2005 9:04 +1300 Nevil Brownlee wrote:
>
>> Hi Benoit:
>>
>>> 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 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.
>
> 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
>
>
>> 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/
>
>
>
> --
> 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/

--
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: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Fri, 18 Mar 2005 12:18:21 +0100

Hi,

I agree with the need of delta time. It seems that a point might be clarified before:
	Section 8 of RFC3954 defines the unit of the fields ID 21 and 22 as msec;
	info model 06 and pre-07 defines the unit of the fields ID 21 (flowEndTime) and 22 (flowCreationTime) as dateTimeSeconds;

Regards
Emile

-----Message d'origine-----

Dear all,

OLD:
   Export Time

to NEW:
   Export Time

    Juergen

---

From: Carter Bullard <[email-masked]>
Date: Fri, 18 Mar 2005 09:57:26 -0500

I just want to re-iterate for the nth time, that I have flow
generators and applications that need flow timestamps in
nanosecond granularity.  Sure would be nice if you could
support that kind of timestamp.  Its just 16 more bits.

Carter

Carter Bullard
QoSient, LLC
50 E. 57th Street Suite 12D
New York, New York  10022-2795
+1 212 588-9133  Phone
+1 212 588-9134  Fax

From: Juergen Quittek <[email-masked]>
Date: Fri, 18 Mar 2005 14:54:21 +0100
To: STEPHAN Emile RD-CORE-LAN <[email-masked]>, Benoit
Claise <[email-masked]>, Nevil Brownlee <[email-masked]>
Cc: <[email-masked]>
Subject: [ipfix] Re: unit of flow creation and end time /RFC3954

Emile,

 as dateTimeSeconds;

from OLD

to NEW

Thanks,

    Juergen

--
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: Fri, 18 Mar 2005 16:04:24 +0100

Carter,

This is available

       5.6.13   flowStartNanoSeconds . . . . . . . . . . . . . . . .  40
       5.6.14   flowEndNanoSeconds . . . . . . . . . . . . . . . . .  40

ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-07-pre.txt

Regards, Benoit.

> ------------------------------------------------------------------------
> *From: *Juergen Quittek <[email-masked]>
> *Date: *Fri, 18 Mar 2005 14:54:21 +0100
> *To: *STEPHAN Emile RD-CORE-LAN <[email-masked]>, 
> Benoit Claise <[email-masked]>, Nevil Brownlee <[email-masked]>
> *Cc: *<[email-masked]>
> *Subject: *[ipfix] Re: unit of flow creation and end time /RFC3954
>
> Emile,
>
>> De : majordomo listserver [mailto:[email-masked]] 
> <mailto:[email-masked]%5D> De la part de Juergen Quittek