[ntar-workers] PCAP-NG / Interface ID size / Drops Counter size ?

[Gianluca Varenni]

----- Original Message ----- 
From: "Hannes Gredler" <hannes at juniper.net>
To: <ntar-workers at winpcap.org>
Cc: <risso at polito.it>
Sent: Sunday, March 05, 2006 10:41 PM
Subject: Re: [ntar-workers] PCAP-NG / Interface ID size / Drops Counter size 
?


>
>
> Gianluca Varenni wrote:
>> First of all, sorry for the long delay, I was really busy last weeks at 
>> work.
>> Since captures do not span years (I think they span hours, days), an 
>> approach that came to my mind, *if* we want to use 64bit instead of 128 
>> bits for timestamps, is:
>>
>> 1. use timestamp(low)/(high) as the *actual* 32bit low/high parts of a 64 
>> bit counter
>> 2. maintain the spec of the precision of this timestamp as it is now in 
>> the IDB
>> 3. add an option in the IDB that specifies an (optional) offset for the 
>> timestamps of packets related to that interface
>>
>> In this way you can for example store a capture with picosecond 
>> precision, with a maximum length of about 5000 hours (if my computations 
>> are not wrong).
>>
>> Any opinions on this?
>
> gianluca,
>
> i do think this is a nice tradeoff b/w overhead and extensibility and 
> looks
> good to me.

Since noone else objected to my proposal (well, noone else replied...), I'll 
add a new option within the IDB to account for this timestamp offset.

It should be something like (it does not take into account the 
representation of timestamps in blocks different from packet blocks):

Option name:  if_tsoffset
Code:         14
Length:       8 (bytes)
Description:  a 64bit integer that specifies an offset (in seconds) that 
must be added to the
              timestamp of each packet to obtain the absolute timestamp of a 
packet. If the
              option is missing, the timestamps stored in the packet must be 
considered absolute
              timestamps.

The question that still remains open is "what is the correct way to 
interpret the timestamps in the current packet block? Seconds/sub-seconds or 
high/low part of sub-seconds??" I'd prefer the latter.

> - another question: did you have a look at the 16-bit vs 32-bit 
> counter/index
> issues that i was talking about earlier - any bright ideas would be 
> welcome.

I still think the best idea is to define a new IDB (Enhanced IDB??) with the 
layout I proposed in my other mail two weeks ago:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Interface ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Timestamp (High)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Timestamp (Low)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Captured Len                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Packet Len                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                          Packet Data                          /
   /          /* variable length, aligned to 32 bits */            /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                      Options (variable)                       /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The drop count will be saved as a 64 bit value in an option.

I'd prefer to have the dropped packet count as an option in order to reduce
the block headers overhead in case the user does not want to save this
information.

Does it sound reasonable to you?

If noone objects on such approach, I'll amend the specification with this 
new block. (BTW, I think I should find a way to track reviews the "spec" so 
that anyone can see the changes...).

Have a nice day
GV

>
> tx,
>
> /hannes
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers
>