[pcap-ng-format] Issue #24: Need to specify the IDB if_tzone option format

[Stephen Donnelly]

On Wed, Aug 26, 2015 at 11:41 AM, Guy Harris <guy at alum.mit.edu> wrote:

>
> On Aug 25, 2015, at 3:50 PM, Stephen Donnelly <
> stephen.donnelly at avagotech.com> wrote:
>
> The current spec says
>
>         The timestamp is a single 64-bit unsigned integer representing the
> number of units since 1/1/1970 00:00:00 UTC.
>
> It doesn't say "units *except for those evil leap
> seconds!!!!!111ONE!!!!!!*", so I'd say "it counts up once per unit, every
> unit" - i.e., *not* POSIX/Windows-style - is a valid interpretation.
>

You know the pcap code base better than I, how many of the input layers
currently 'convert' the system/POSIX time into a monotonic counter? I
thought they just shoved the packet 'system' time stamp in there as-is.
This means the defacto implementation is already POSIX style.

> A monotonic count of seconds since an epoch is in practice what both TAI
> and GPS provide (there is a fixed offset between them due to different
> epochs). TAI is the default time base for PTP and IRIG-B clocks, so is
> often available where people really care about time stamp quality.
>
> There's "time stamps" in the sense of "real-number coordinates on an axis
> with a given origin", and there's "time stamps" in the sense of "stuff a
> normal human would recognize as a date and time".
>
> Most if not all capture files, including pcap and pcapng, provide time
> stamps that are approximations of the first of those senses; it's the
> capture file readers that turn them into values of the second type.
>
> If both TAI and UTC were represented as seconds that have elapsed since
> their individual epochs, the difference between those representations would
> be a constant (the difference between their epochs, if any), unaffected by
> leap seconds, and either one would work as a monotonic count of seconds;
> it's attempting to tie a monotonic counter to the rotation of the earth
> that causes the problem.
>
> > I was not suggesting changing the 'default' time stamp definition of
> pcapng, but rather adding an option for the interpretation to be e.g. 'TAI'
> rather than 'POSIX/Windows UTC' encoding for clarity.
>
> Unfortunately, given the hardware and software on which most captures are
> done, it's probably not an interpretation that would allow a valid
> interpretation of the time stamp values.
>

Not sure what this means? I suggested allowing the capture system to
indicate what interpretation to use, e.g. POSIX, Windows, 'monotonic UTC',
TAI, GPS etc. Only the display tool needs to be able to interpret into a
human readable UTC or local timezone for display. Wireshark must already
use on leap-second tables/timezone files for this if pcap/pcapng time
stamps are monotonic as you suggest and not POSIX.

So, if we're to allow packet captures on UN*X and Windows systems, with
> OS-supplied time stamps, we'd have to find *some* way to describe
> POSIX-style time stamps.
>
> If a "unit" is 1 second, then we could go with POSIX.
>
> However, if it's less than 1 second, what happens during a leap second?
> Does the counter keep ticking milliseconds or microseconds or nanoseconds
> or whatever, and then reset back to the beginning of the previous second?


That's precisely the problem I am trying to address by allowing the
specification of a TAI time base instead of POSIX/System, so we could have
a monotonic standard. The POSIX behavior is under-specified during leap
seconds, implementations dependent (1). Some systems jump the clock back
after the leap second, causing duplicates, while some 'pause' the clock
during the leap second, messing up latency/bandwidth calculations. Some
systems (Google) reportedly adjust their clock rate slightly over the next
several hours/day, also messing up statistics and leading to loss of global
synchronization.

(1) http://www.madore.org/~david/computers/unix-leap-seconds.html

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150826/3ab198c5/attachment.html>