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

[Gianluca Varenni]

----- Original Message ----- 
From: "Hannes Gredler" <hannes at juniper.net>
To: <risso at polito.it>
Cc: <tcpdump-workers at lists.tcpdump.org>; <ntar-workers at winpcap.org>
Sent: Sunday, February 12, 2006 12:13 PM
Subject: [ntar-workers] PCAP-NG / Interface ID size / Drops Counter size ?


> hi fulvio, et al,
>
> i was digesting the pcap-ng spec and wondered why
> the size of interface ID (Packet Block, Interface Statistics Block)
> is only 16-Bit ?
>
> while that may seem adequate for hosts, most router
> implementations have internal 32-Bit index size.
> on some of the larger scale implementations for our clients
> we do exceed the 16-Bit Index space today.

I have no idea. I think that when the pcap-ng spec was written, nobody was 
thinking that this was a limit. An even if in some large scale environments 
you may have more than 65535 interfaces, the interface ID is actually an 
ordinal, i.e. a packet on interface ID "i" corresponds to the interface 
described by the i-th Interface Description Block encountered in that 
section. The interface ID cannot be the some physical ID  (like the Index of 
the interface in the router). But I admit that the specification is 
misleading/wrong, it says:

Packet Block, Interface ID: it specifies the interface this packet comes 
from; the correct interface will be the one whose Interface Description 
Block (within the current Section of the file) is identified by same number 
(see Section 3.2 (Interface Description Block (mandatory))) of this field.

There's no such "Interface ID" field in the Interface Description Block.

This basically means that in order to exceed the 16-bit space, you need to 
have a section containing packets from more than 65535 different interfaces.

>
> another comment wrt to the 16-Bits drops field in the Packet Block.
> my feeling is that this is too small-sized as well.
>
> let me give an example for illustration:
>  if you capture lets say on a high-peed interface (oc-768)
>  and you have a short 1ms disruption then you may not even express
>  that 1ms glitch given the max offered load of 100mpps.

You are completely true. Actually I don't know exactly why the drop count 
was put there, just speculating I can think that having 16 bits for the 
interface ID left 16 spare bits, that were used for drop count.

>
>  IMO packet-counters (including drop counters)
>  always should be expressed as 64-bit entities.
>
>
> i wondered if the spec could get amended to support
> broader fields.

My opinion is that we should add a new packet block to the spec, similar to 
the current packet block:

    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.

Why defining a new block vs. modifying the existing packet block? Well, one 
of the objectives of pcap-ng was extensibility, by defining new blocks when 
needed (so that breaking changes could be basically avoided).
Moreover, although the pcap-ng (and NTAR) is still not probably extensively 
used, it has been adopted as the standard trace file format for some 
avionics products 
(http://www.condoreng.com/products/protocols/arinc/cnic.shtml), changing the 
specification of the packet block will cause incompatibilities between the 
various versions of a trace file, that I would like to avoid, if possible.

Another option, if we can live with 16-bit interface IDs, is to simply add

What do you think?

Have a nice day
GV


>
> tx,
>
> /hannes
>
> ---
>
> refs:
>
> http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
>
> -> see paragraph 3.3 Packet Block
>    Interface-ID
>    Drops count
>
> -> see paragraph 3.6 Interface Statistics Block
>    Interface-ID
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers
>