Subject: [IPFIX] when flow{Start,End}SysUpTime overflow

From: Hitoshi Irino <[email-masked]>
Date: Wed, 04 Oct 2006 16:09:17 +0900

Dear all,

I have a question about flow{Start,End}SysUpTime IEs.

flow{Start,End}SysUpTime can represent 49 days, 17 hour, 2 minutes, and
 47 seconds since (re-)initialization of IPFIX device, because abstract
data type of flow{Start,End}SysUpTime is unsigned32.
When exporter (ex. router) runs over 50 days, how can these IE represent
time stamp?

If these counter reset to 0 when these counter overflow, there is a
possibility that the collector confuses information of the 1st day and
information of 50th day.

If exporter can update systemInitTimeMilliseconds arbitrarily, it can
avoid this problem. But, systemInitTimeMilliseconds represent "The
absolute timestamp of the last (re-)initialization of the IFPIX Device",
therefore it seems that it is bad thing to update
systemInitTimeMilliseconds arbitrarily.

How should exporter export for a long time (over 50 days) that uses
flow{Start,End}SysUpTime?

-- 
NTT Network Service Systems Laboratories
 Broadband Network Systems Project
  Service Edge Group

   Hitoshi Irino

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Wed, 4 Oct 2006 09:50:56 -0400

> systemInitTimeMilliseconds arbitrarily.

Agreed.

> flow{Start,End}SysUpTime?

It seems the solution to this one is the same we've had on other  
"overflowable" counter IEs - simply define it in the Information  
Model to be an unsigned64, then use reduced length encoding in the  
case of shorter than 50 day uptimes.

Alternately, the flow{Start,End}DeltaMicroseconds timestamps can be  
used to express flow times as negative offsets from the message  
export time, and have the dual advantages of 1. being 32 bit counters  
and 2. having greater precision; however, the overhead to calculate  
them (as the message export time may not be known until _after_ the  
MP generates the records) may be measurably higher than that for  
SysUpTime, so this may not solve your problem.

In any case, I'd recommend to the WG that the SysUpTime IEs be  
redefined as 64 bits.

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Wed, 4 Oct 2006 09:50:56 -0400

Agreed.

Regards,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Wed, 04 Oct 2006 15:45:09 +0100

Brian,

> however, the overhead to calculate  them (as the message export time
> may not be known until _after_ the  MP generates the records) may be
> measurably higher

The export time is defined as

     Time in seconds since 0000 UTC Jan 1st 1970, at which the
     IPFIX Message Header leaves the Exporter.

So presumably the EP would have to calculate a pseudo export time, 
recalculate any delta times relative to the pseudo export time, and then 
either check whether the pseudo export time was still the current time 
(ie, clock has not ticked to the next second) or wait for the pseudo 
export time to occur (if it was deliberately in advance).

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 04 Oct 2006 15:45:09 +0100

Brian,

---

From: Hitoshi Irino <[email-masked]>
Date: Thu, 05 Oct 2006 12:51:07 +0900

Dear Brian,

Brian Trammell wrote:
> "overflowable" counter IEs - simply define it in the Information Model 
> to be an unsigned64, then use reduced length encoding in the case of 
> shorter than 50 day uptimes.
> 
> Alternately, the flow{Start,End}DeltaMicroseconds timestamps can be used 
> to express flow times as negative offsets from the message export time, 
> and have the dual advantages of 1. being 32 bit counters and 2. having 
> greater precision; however, the overhead to calculate them (as the 
> message export time may not be known until _after_ the MP generates the 
> records) may be measurably higher than that for SysUpTime, so this may 
> not solve your problem.
> 
> In any case, I'd recommend to the WG that the SysUpTime IEs be redefined 
> as 64 bits.

Thank you for your suggestion,
I also agree to extend data type of SysUpTime IEs to unsigned64.

    Hitoshi Irino
     Email: [email-masked]
     Tel: +81-422-59-4403  Fax: +81-422-59-4549

---

From: Hitoshi Irino <[email-masked]>
Date: Thu, 05 Oct 2006 12:51:07 +0900

Dear Brian,

    Hitoshi Irino

---

From: Paul Aitken <[email-masked]>
Date: Thu, 05 Oct 2006 13:41:12 +0100

Brian, Hotishi-san,

> I also agree to extend data type of SysUpTime IEs to unsigned64.

I disagree.

The main advantage of sending sysuptime in netflow v9 is to save space, 
since each flow contains two 32 bit quantities (start and end time) that 
are referenced to another two 32-bit quantities (sysUpTime and UNIX 
Secs) in the header.

IPFIX doesn't have sysuptime in the header (only Export time), so you 
have to send a seperate systemInitTimeMilliseconds. Sending that per 
flow would be wasteful. Perhaps it could be sent as an option.

Sending 64 bit sysuptimes completely negates that advantage. At that 
point you'd be far better sending the absolute flowStart* and flowEnd* 
IEs which are also 64 bits, but which saves you from performing any 
calculations to convert the relative sysuptimes to absolute values.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 05 Oct 2006 13:41:12 +0100

Brian, Hotishi-san,

I disagree.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Oct 2006 10:28:57 -0400

Paul, Hitoshi-san,

I presume in all of this that systemInitTimeMilliseconds gets sent  
once per session as an option and is stored by the Collecting Process  
for the duration; also, I'm presuming that in the common case the flow 
{Start,End}SysUpTime IE would be encoded using 32 bits via reduced  
length encoding (much like commonPropertiesID, the definition would  
be unsigned64, but you really wouldn't expect to see it on the wire  
that way most of the time).

The issue with simply moving the systemInitTimeMilliseconds counter  
forward (i.e., simulating a restart) is that the information element  
defintion (INFO-13 section 5.9.11) clearly states that this is the  
actual reinitialization time; it doesn't allow for simulation.  
Collecting Processes that presume this is a true restart time  
(perhaps, that might warn the user on unscheduled MP/EP restart)  
could behave inappropriately under simulated restart conditions.  
Certainly, a CP could be confused by a MP/EP restart not accompanied  
by a session restart.

Now, I could see the use of three other information elements that  
could be used to implement initTime/upTime flow timestamps without  
this semantic difficulty: let's call them flowBaseTimeMilliseconds,  
flowStartOffsetMilliseconds, and flowEndOffsetMilliseconds. I'm not  
_actually_ proposing this, but it does give us a way to define the  
offsets as unsigned32 without breaking the meaning of InitTime.

- Brian

On Oct 5, 2006, at 8:41 AM, Paul Aitken wrote:

> The main advantage of sending sysuptime in netflow v9 is to save  
> space, since each flow contains two 32 bit quantities (start and  
> end time) that are referenced to another two 32-bit quantities  
> (sysUpTime and UNIX Secs) in the header.
>
> IPFIX doesn't have sysuptime in the header (only Export time), so  
> you have to send a seperate systemInitTimeMilliseconds. Sending  
> that per flow would be wasteful. Perhaps it could be sent as an  
> option.
>
> Sending 64 bit sysuptimes completely negates that advantage. At  
> that point you'd be far better sending the absolute flowStart* and  
> flowEnd* IEs which are also 64 bits, but which saves you from  
> performing any calculations to convert the relative sysuptimes to  
> absolute values.
>
> -- 
> Paul Aitken

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Oct 2006 10:28:57 -0400

Paul, Hitoshi-san,

- Brian

---

From: Hitoshi Irino <[email-masked]>
Date: Thu, 05 Oct 2006 23:43:28 +0900

Dear paul,

> flow would be wasteful. Perhaps it could be sent as an option.

I know that systemInitTimeMilliseconds can be sent in option.
Do you suggest that exporter update systemInitTimeMilliseconds whenever 
SysUpTime IEs overflow? (Otherwise, SysUpTime IEs represent only 49 days.)
But I think "SysUpTime IEs' overflow" and "semantics of (re-)initialize" 
are different.
(systemInitTimeMilliseconds is defined as "The absolute timestamp of the 
last (re-)initialization of the IFPIX Device")

> calculations to convert the relative sysuptimes to absolute values.

But "Reduced Size Encoding" is applicable to flow{Start|End}SysUpTime 
whose data type are unsgined64.
Therefore, I think 64 bit sysuptimes do not negates that advantage.

If SysUpTime keeps 32 bit, I suggest new IE to count SysUpTime overflow, 
and the new IE should be sent with systemInitTimeMilliseconds in option.

regards,
Hitoshi Irino

---

From: Hitoshi Irino <[email-masked]>
Date: Thu, 05 Oct 2006 23:43:28 +0900

Dear paul,

regards,
Hitoshi Irino

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 15 Oct 2006 09:18:13 +0200

Paul,

What do you think we would loose if we allow sending 64 bit sysuptimes?
We would still be backwards compatible with NetFlowv9 (that uses 32 bit
sysuptimes) but at the same time allow for longer values if required,
for example, at devices without an absolute clock being set.

Thanks,

    Juergen

--On 05.10.2006 23:43 Uhr +0900 Hitoshi Irino wrote:

> Do you suggest that exporter update systemInitTimeMilliseconds whenever SysUpTime IEs overflow? (Otherwise, SysUpTime IEs represent only 49 days.)
> But I think "SysUpTime IEs' overflow" and "semantics of (re-)initialize" are different.
> (systemInitTimeMilliseconds is defined as "The absolute timestamp of the last (re-)initialization of the IFPIX Device")
>
> But "Reduced Size Encoding" is applicable to flow{Start|End}SysUpTime whose data type are unsgined64.
> If SysUpTime keeps 32 bit, I suggest new IE to count SysUpTime overflow, and the new IE should be sent with systemInitTimeMilliseconds in option.
>
> regards,
> Hitoshi Irino
>

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 15 Oct 2006 09:18:13 +0200

Paul,

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Sun, 15 Oct 2006 15:58:25 +0100

Juergen,

> What do you think we would loose if we allow sending 64 bit sysuptimes?

I already explained my objection quite clearly, and I didn't hear a good 
counter argument yet.

To reiterate:

The advantage of sending sysuptimes is they're only 32 bits long.

In netflow v9 they reference the sysuptime in the message header. But 
this has been removed from the IPFIX header, so when using IPFIX you 
must also send systemInitTimeMilliseconds (an additional 64 bits).

Sending flowStartSysUpTime, flowEndSysUpTime and 
systemInitTimeMilliseconds per flow = 32 + 32 + 64 = 128 bits, which is 
no saving over sending flowStartMilliseconds and flowEndMilliseconds (64 
+ 64 = 128 bits) (or even sending the equivalent Micro or Nano IEs, 
which are also 64 bits each).

In fact, it's more of an overhead due to the convertion of the relative 
sysuptimes to absolute times.

The only saving to be made is if systemInitTimeMilliseconds can be sent 
seperately, eg in an option. Then the requirement is 32 + 32 = 64 bits 
per flow, though still with the conversion overhead.

What is now proposed (64 bit sysuptimes) would require 64 + 64 + 64 = 
192 bits per flow *plus* the additional overhead of conversion, which is 
clearly a lot less efficient than sending flowStartMilliseconds and 
flowEndMilliseconds (64 + 64 = 128 bits, with no conversion required).

Or if the systemInitTimeMilliseconds is sent seperately, it'd be 64 + 64 
= 128 bits per flow (so equivalent to flowStartMilliseconds and 
flowEndMilliseconds) but still with the conversion overhead.

So it quite simply doesn't make any sense to extend sysuptimes to 64 
bits; there's no advantage to be gained at all.

Rather, implimentations should move to the use of absolute 
flowStartMilliseconds and flowEndMilliseconds, and only retain 32 bit 
flowStartSysUpTime and flowEndSysUpTime for backwards compatability.

> for example, at devices without an absolute clock being set.

A device without an absolute clock is problematic for a different 
reason. Observed traffic could be retained in the device's cache for 
some time before being exported (eg, if the exporter runs once per 
minute), or stuck in an IPC queue, or stuck in the export stack, or 
delayed in the network between the exporter and collector.

So it could be difficult (I hesitate to say "impossible") for the 
collecting device to convert the relative sysuptimes to absolute times 
with any sort of accuracy without knowing the systemInitTimeMilliseconds.

Whereas the use of sysuptime IEs in netflow v9 was always relative to a 
sysuptime and absolute time in the message header, so it was always 
possible to convert the sysuptimes with accuracy.

Since the header sysuptime doesn't exist in IPFIX, and since sending of 
relative times alone seems insufficient (except for the most trivial of 
monitoring), I think we should discourage the sending of the 
flowStartSysUpTime and flowEndSysUpTime IEs without also sending 
systemInitTimeMilliseconds.

Do you know of any such implimentation today?

---

From: Paul Aitken <[email-masked]>
Date: Sun, 15 Oct 2006 15:58:25 +0100

Juergen,

To reiterate:

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 15 Oct 2006 19:55:35 +0200

Hi Paul,

--On 15.10.2006 15:58 Uhr +0100 Paul Aitken wrote:

> I already explained my objection quite clearly, and I didn't hear a good counter argument yet.

Sorry for the misunderstanding.  I was just not asking for a re-iteration
but what we would loose when supporting it.  Even if we give it a
data type of 64 bit, no one would have to use it.

Of course we should not spend effort on supporting a feature that
no one uses. But this is exactly what I want to explore.

If I get you right, you do not see a case where 64 bit sysuptimes
make sense, but if we still define them we don't loose anything
because we can still use reduced 32 bit encoding.

Now, is anyone seeing scenarios where a 64 bit sysuptime would be
desirable?

On the list Brian brought up the issue of simulation.
Irino-san was looking at how to report flows lasting longer than 50 days.
Can't these scenario not be solved by using other IEs?

Thanks,

    Juergen

> In netflow v9 they reference the sysuptime in the message header. But this has been removed from the IPFIX header, so when using IPFIX you must also send systemInitTimeMilliseconds (an additional 64 bits).
>
> Sending flowStartSysUpTime, flowEndSysUpTime and systemInitTimeMilliseconds per flow = 32 + 32 + 64 = 128 bits, which is no saving over sending flowStartMilliseconds and flowEndMilliseconds (64 + 64 = 128 bits) (or even sending the equivalent Micro or
> Nano IEs, which are also 64 bits each).
>
> In fact, it's more of an overhead due to the convertion of the relative sysuptimes to absolute times.
>
> The only saving to be made is if systemInitTimeMilliseconds can be sent seperately, eg in an option. Then the requirement is 32 + 32 = 64 bits per flow, though still with the conversion overhead.
>
> What is now proposed (64 bit sysuptimes) would require 64 + 64 + 64 = 192 bits per flow *plus* the additional overhead of conversion, which is clearly a lot less efficient than sending flowStartMilliseconds and flowEndMilliseconds (64 + 64 = 128 bits,
> with no conversion required).
>
> Or if the systemInitTimeMilliseconds is sent seperately, it'd be 64 + 64 = 128 bits per flow (so equivalent to flowStartMilliseconds and flowEndMilliseconds) but still with the conversion overhead.
>
> So it quite simply doesn't make any sense to extend sysuptimes to 64 bits; there's no advantage to be gained at all.
>
> Rather, implimentations should move to the use of absolute flowStartMilliseconds and flowEndMilliseconds, and only retain 32 bit flowStartSysUpTime and flowEndSysUpTime for backwards compatability.
>
> A device without an absolute clock is problematic for a different reason. Observed traffic could be retained in the device's cache for some time before being exported (eg, if the exporter runs once per minute), or stuck in an IPC queue, or stuck in the
> export stack, or delayed in the network between the exporter and collector.
>
> So it could be difficult (I hesitate to say "impossible") for the collecting device to convert the relative sysuptimes to absolute times with any sort of accuracy without knowing the systemInitTimeMilliseconds.
>
> Whereas the use of sysuptime IEs in netflow v9 was always relative to a sysuptime and absolute time in the message header, so it was always possible to convert the sysuptimes with accuracy.
>
> Since the header sysuptime doesn't exist in IPFIX, and since sending of relative times alone seems insufficient (except for the most trivial of monitoring), I think we should discourage the sending of the flowStartSysUpTime and flowEndSysUpTime IEs
> without also sending systemInitTimeMilliseconds.
>

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 15 Oct 2006 19:55:35 +0200

Hi Paul,

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Sun, 15 Oct 2006 19:20:03 +0100

Juergen,

> Sorry for the misunderstanding.  I was just not asking for a 
> re-iteration but what we would loose when supporting it.  Even if we 
> give it a data type of 64 bit, no one would have to use it.

If nobody will use it, then we are wasting our time even discussing it.

> Of course we should not spend effort on supporting a feature that no 
> one uses. But this is exactly what I want to explore.

Then who has (or plans) an implimentation that uses sysuptimes which
would not be improved by using flowStartMilliseconds and
flowEndMilliseconds?

> make sense,

Correct. In fact, I showed why they don't ever make sense.

> but if we still define them we don't loose anything because we can 
> still use reduced 32 bit encoding.

Sure. But if you would use the 64-bit encoding, then your implimentation
would be more efficient if you converted it to use flowStartMilliseconds
and flowEndMilliseconds.

> On the list Brian brought up the issue of simulation. Irino-san was 
> looking at how to report flows lasting longer than 50 days. Can't 
> these scenario not be solved by using other IEs?

I understand these scenarios, and recommend use of flowStartMilliseconds
and flowEndMilliseconds for these situations.

But if someone has a good justification for implimentating 64-bit
sysuptimes, then of course I would like to hear it.

---

From: Paul Aitken <[email-masked]>
Date: Sun, 15 Oct 2006 19:20:03 +0100

Juergen,

---

From: Brian Trammell <[email-masked]>
Date: Mon, 16 Oct 2006 09:19:39 -0400

On Oct 15, 2006, at 2:20 PM, Paul Aitken wrote:

>> On the list Brian brought up the issue of simulation. Irino-san  
>> was looking at how to report flows lasting longer than 50 days.  

This makes sense to me. The only reason I could see now is if the  
calculation of flow{Start,End}Milliseconds was significantly more  
costly that the calculation of flow{Start,End}SysUpTime, but these  
are fairly minor points and I can't provide an example of such an  
machine; so I withdraw my point...

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 16 Oct 2006 09:19:39 -0400

Regards,

Brian

---

From: Hitoshi Irino <[email-masked]>
Date: Tue, 17 Oct 2006 10:30:06 +0900

Dear Paul,

Brian Trammell wrote:
> calculation of flow{Start,End}Milliseconds was significantly more costly 
> that the calculation of flow{Start,End}SysUpTime, but these are fairly 
> minor points and I can't provide an example of such an machine; so I 
> withdraw my point...

I understand use of flowStartMilliseconds and flowEndMilliseconds is 
suitable for the situation that exporter runs longer than 50 days.
So, I will not argue to extend sysuptime to 64 bit.

But, I still have a question. Don't flowStartSysUpTime and 
flowEnsSysUpTime support to represent longer than 50 days since device 
booted?
If they can represent only shorter than 50 days since device booted, 
they are not realistic, because routers which are typical IPFIX 
exporters have to run longer than 50 days.
If systemInitTimeMilliseconds is updated to new absolute timestamp to 
represent longer than 50 days whenever counters of sysUpTime overflow. 
Is it correct? If it is correct, I think that systemInitTimeMilliseconds 
is not initialize timestamp, it is just absolute base time for 
flowStartMilliseconds and flowEndMilliseconds. This behavior is 
different from description of systemInitTimeMilliseconds. I think it is 
better to change the name or description of systemInitTimeMilliseconds, 
or create a new Information Element to represent base time for 
sysuptime, for example sysUpBaseTimeMilliseconds (It is similar to 
Brian's suggestion at 5th Oct).

Regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549

---

From: Hitoshi Irino <[email-masked]>
Date: Tue, 17 Oct 2006 10:30:06 +0900

Dear Paul,

Regards,
Hitoshi Irino

---

From: Paul Aitken <[email-masked]>
Date: Tue, 17 Oct 2006 12:33:21 +0100

Hitoshi-san,

> flowEnsSysUpTime support to represent longer than 50 days since device 

Well, they wrap around at 50 days.

I looked at the SNMP definition for sysUpTime. It has SYNTAX TimeTicks, 
which is 0..4294967295 ie it's a 32 bit number. So the IPFIX definition 
is in keeping with this.

> exporters have to run longer than 50 days.

Agreed. That's one reason that I don't recommend their use in IPFIX.

> Is it correct?

No. Not unless the system reboots.

> If it is correct, I think that systemInitTimeMilliseconds 

So I see several things we could do:

1. Increase sysuptimes to 64 bits.

    - I don't favour this solution: it's not efficient,
      and it's contrary to SNMP

2. Change systemInitTimeMilliseconds to sysUpBaseTimeMilliseconds.

    - I could be OK with this.

3. Do something else.

    - Any suggestions?

4. Do nothing.

    - No change; just recommend using absolute timestamps.

---

From: Paul Aitken <[email-masked]>
Date: Tue, 17 Oct 2006 12:33:21 +0100

Hitoshi-san,

3. Do something else.

    - Any suggestions?

4. Do nothing.

---

From: Hitoshi Irino <[email-masked]>
Date: Tue, 17 Oct 2006 21:12:56 +0900

Dear Paul,

Paul Aitken wrote:
>> If it is correct, I think that systemInitTimeMilliseconds is not 
>> initialize timestamp, it is just absolute base time for 
>> different from description of systemInitTimeMilliseconds. I think it 
>> is better to change the name or description of 
>> systemInitTimeMilliseconds, or create a new Information Element to 
>> represent base time for sysuptime, for example 
>> sysUpBaseTimeMilliseconds (It is similar to Brian's suggestion at 5th 
>> Oct).
> 

   Keep systemInitTimeMilliseconds and create sysUpBaseTimeMilliseconds
      - meaning of base time for sysUpTime Information Elements is
        different from meaning of initial time,
        so I prefer creating a new IE, if there is no problems to create
        a new IE.

regards,
Hitoshi Irino

---

From: Hitoshi Irino <[email-masked]>
Date: Tue, 17 Oct 2006 21:12:56 +0900

Dear Paul,

regards,
Hitoshi Irino

---

From: Brian Trammell <[email-masked]>
Date: Tue, 17 Oct 2006 10:33:48 -0400

>>    - I could be OK with this.

I agree with Hitoshi-san (as below) -- if the argument for having  
systemInitTimeMilliseconds and flow{Start,End}SysUpTime is for  
parallelism with SNMP (an argument I agree with... now), we probably  
don't want to change the meaning, because a sysUpBaseTimeMilliseconds  
IE would be subtly different than the present SMTP-derived  
definition. If we want adjustable base time not tied to restart, it  
should be a new IE (of course, now we need conflict resolution rules  
should both systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  
be present and valid...)

>>    - No change; just recommend using absolute timestamps.

We should do this _anyway_ ... the proliferation of timestamp IEs and  
formats (32-bit sec from epoch, 64-bit msec from epoch, NTP-style, 32- 
bit negative usec from export) is, I think, confusing to implementors  
(and is presently the most complex construct in the "universal" IPFIX  
import code in our own Collecting Process). I understand the  
compatibility reasons for supporting multiple timestamp IEs,  
especially as it is important to accommodate the variety of exporting  
process designs out there... but perhaps we should make  
recommendations as to which to use for export in the absence of other  
considerations.

(Personally, I'd recommend absolute timestamps all the way, further  
pointing out that only flow{Start,End}Milliseconds are immune from  
the Y2038 problem, if anyone cares to build exporting processes with  
a thirty-year service lifetime)

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Tue, 17 Oct 2006 10:33:48 -0400

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Tue, 17 Oct 2006 16:55:27 +0100

Brian,

> IE would be subtly different than the present SMTP-derived  definition. 

I think the original reason for the systemInitTimeMilliseconds IE was as 
the base time for the sysuptime IEs, since this wasn't provided in the 
IPFIX header.

If it's only ever going to be used for that reason, then I'd not be 
unhappy about renaming it to sysUpBaseTimeMilliseconds.

However, if we perceive that the systemInitTime might be useful in its 
own right, then we should keep it and create a new IE.

> (of course, now we need conflict resolution rules  should both 
> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present and 
> valid...)

Since your sysuptimes might be referenced to an updated 
sysUpBaseTimeMilliseconds, that's what you must use and not 
systemInitTimeMilliseconds.

> the proliferation of timestamp IEs and  
> compatibility reasons for supporting multiple timestamp IEs,  especially 
> as it is important to accommodate the variety of exporting  process 
> designs out there... but perhaps we should make  recommendations as to 
> which to use for export in the absence of other  considerations.

Implimentation guidelines?

> pointing out that only flow{Start,End}Milliseconds are immune from  the 
> Y2038 problem, if anyone cares to build exporting processes with  a 
> thirty-year service lifetime)

IG again :-)

---

From: Paul Aitken <[email-masked]>
Date: Tue, 17 Oct 2006 16:55:27 +0100

Brian,

IG again :-)

---

From: Brian Trammell <[email-masked]>
Date: Tue, 17 Oct 2006 12:00:23 -0400

On Oct 17, 2006, at 11:55 AM, Paul Aitken wrote:

>> parallelism with SNMP (an argument I agree with... now), we  
>> probably  don't want to change the meaning, because a  
>> sysUpBaseTimeMilliseconds  IE would be subtly different than the  
>> present SMTP-derived  definition.
>
> I think the original reason for the systemInitTimeMilliseconds IE  
> was as the base time for the sysuptime IEs, since this wasn't  
> provided in the IPFIX header.
>
> However, if we perceive that the systemInitTime might be useful in  
> its own right, then we should keep it and create a new IE.

I can see it being useful, as a sideband method for measuring the  
health of the measurement infrastructure itself ("hey, why'd the  
router reboot yesterday?")... Of course, this is a system management  
problem and on its own is out of scope for IPFIX, I think, but it  
could explain e.g. outages in the data (no data for a while followed  
by an updated init time => router outage as opposed to network outage).

>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be  
>> present and valid...)
>

indeed; just pointing out that we'll need to note this in the  
Description of both IEs.

>
>> the proliferation of timestamp IEs and  formats (32-bit sec from  
>> epoch, 64-bit msec from epoch, NTP-style, 32- bit negative usec  
>> from export) is, I think, confusing to implementors  (and is  
>> presently the most complex construct in the "universal" IPFIX   
>> especially as it is important to accommodate the variety of  
>> exporting  process designs out there... but perhaps we should  
>> make  recommendations as to which to use for export in the absence  
>> of other  considerations.
>
>> (Personally, I'd recommend absolute timestamps all the way,  
>> further  pointing out that only flow{Start,End}Milliseconds are  
>> immune from  the Y2038 problem, if anyone cares to build exporting  
>> processes with  a thirty-year service lifetime)
>
> IG again :-)

Indeed on both points. I'll throw together some language...

---

From: Brian Trammell <[email-masked]>
Date: Tue, 17 Oct 2006 12:00:23 -0400

---

From: Hitoshi Irino <[email-masked]>
Date: Mon, 30 Oct 2006 20:26:37 +0900

There are two array type IEs: paddingOctets, which needs no size, and
mplsVpnRouteDistinguisher, which is discussed in your mail.

I would be happy for mplsVpnRouteDistinguisher either to be changed to
unsigned64, or to remain as an array but include this text in its
description:

     According to section 4.2 in rfc4364, a VPN-IPv4 address
     consists of an 8-byte Route Distinguisher followed by a
     4-byte IPv4 address.

BTW, it doesn't discuss IPv6...

> (Similarly, I think definition of IE should provide information 
> whether the IE may be apply reduced size encoding for integer and 
> float type IEs.)

I disagree: this information should not be provided per IE, but only as
a general guideline - which you will already find in section 6.2 of
IPFIX-PROTO.

---

From: Hitoshi Irino <[email-masked]>
Date: Mon, 30 Oct 2006 20:26:37 +0900

Dear Juregen, Paul

Brian Trammell wrote:
> I can see it being useful, as a sideband method for measuring the health 
> of the measurement infrastructure itself ("hey, why'd the router reboot 
> yesterday?")... Of course, this is a system management problem and on 
> its own is out of scope for IPFIX, I think, but it could explain e.g. 
> outages in the data (no data for a while followed by an updated init 
> time => router outage as opposed to network outage).
> 
>>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present 
>>> and valid...)
>>

Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
---
   sysUpBaseTimeMilliseconds

    Description:
       The absolute timestamp of the base time for flowStartSysUpTime 
and flowEndSysUpTime. The initial value is equal to 
systemInitTimeMilliseconds, and the value is updated every 49 days to 
prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

    Abstract Data Type: dateTimeMilliseconds
    ElementId:
    Status: current
    Units: milliseconds
---
I am not good at English, please correct above description, if it has 
problem.

regards,
Hitoshi Irino

@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ipfix>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Dear Juregen, Paul

Brian Trammell wrote:
> I can see it being useful, as a sideband method for measuring the health 
> of the measurement infrastructure itself ("hey, why'd the router reboot 
> yesterday?")... Of course, this is a system management problem and on 
> its own is out of scope for IPFIX, I think, but it could explain e.g. 
> outages in the data (no data for a while followed by an updated init 
> time => router outage as opposed to network outage).
> 
>>> systemInitTimeMilliseconds and sysUpBaseTimeMilliseconds  be present 
>>> and valid...)
>>

Could you add sysUpBaseTimeMilliseconds to next Information Model draft?
---
   sysUpBaseTimeMilliseconds

    Description:
       The absolute timestamp of the base time for flowStartSysUpTime 
and flowEndSysUpTime. The initial value is equal to 
systemInitTimeMilliseconds, and the value is updated every 49 days to 
prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

    Abstract Data Type: dateTimeMilliseconds
    ElementId:
    Status: current
    Units: milliseconds
---
I am not good at English, please correct above description, if it has 
problem.

regards,
Hitoshi Irino

---

From: Hitoshi Irino <[email-masked]>
Date: Mon, 30 Oct 2006 20:26:37 +0900

Dear Juregen, Paul

    Description:

regards,
Hitoshi Irino

---

From: Paul Aitken <[email-masked]>
Date: Mon, 30 Oct 2006 11:49:48 +0000

Hitoshi-san,

>       The absolute timestamp of the base time for flowStartSysUpTime and 
> flowEndSysUpTime. The initial value is equal to 

I'd entirely remove the second sentence, since that is up to the 
implimentation. eg, it could start with a different value (eg, in the 
past, to export historical data). Or it could be updated every week, 
day, hour or minute.

We should say that where it's present it's to be used in preference to 
the systemInitTimeMilliseconds, where "present" means there's a value 
for this IE in the flow, or in an option that's in scope.

But you want to export the sysUpBaseTimeMilliseconds value in an option 
because you certainly you don't want to have to export the value in 
every flow, right?

That raises an interesting question concerning the change of value. If 
you're exporting some flows based on a certain value of 
sysUpBaseTimeMilliseconds, and you export an option containing an 
updated value, you must ensure that all the old flows have reached and 
been processed by the collector before the updated 
sysUpBaseTimeMilliseconds, and that the updated 
sysUpBaseTimeMilliseconds reaches the collector and is processed before 
any of the new flows. Else you risk interpreting some of the flows with 
the wrong value of sysUpBaseTimeMilliseconds.

Unless we can show how that can be done, it'd be necessary to export 
systemInitTimeMilliseconds in every flow which, as previously discussed 
at some length, is incredibly inefficient and should not be done.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 30 Oct 2006 11:49:48 +0000

Hitoshi-san,

---

From: Hitoshi Irino <[email-masked]>
Date: Tue, 31 Oct 2006 17:43:14 +0900

Dear paul,

Thank you for reply,

> past, to export historical data). Or it could be updated every week, 

I do not have a sufficient reason to restrict "initial value" and "every
49 days" for update.
I want to keep description about initial value not for restricted, but 
just information.

Regarding update,
I want to keep the part of sentence "to prevent overflow of
flowStartSysUpTime and flowEndSysUpTime".
So, I want to change
"The value is updated every certain interval. The certain interval is
less than 49 days, 17 hour, 2 minutes, and 47 seconds to prevent
overflow of flowStartSysUpTime and flowEndSysUpTime."

> because you certainly you don't want to have to export the value in 

I want to export in option.

> at some length, is incredibly inefficient and should not be done.

I have not considered about this problem.
I think that if the option template which includes
sysUpBaseTimeMilliseconds can notify the sequence number of header of
corresponding data record which contains flowStartSysUpTime and
flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to
collector (but suitable IE does not exist in nowadays IPFIX-INFO), this
problem can be solved.

---

From: Hitoshi Irino <[email-masked]>
Date: Tue, 31 Oct 2006 17:43:14 +0900

Dear paul,

Thank you for reply,

Regarding update,