[pcap-ng-format] pcap-ng-format Digest, Vol 16, Issue 1 (UNCLASSIFIED)

[Renard, Kenneth D CIV USARMY ARL (US)]

Classification: UNCLASSIFIED
Caveats: NONE

Thanks for the feedback!  I look forward to contributing where I can to
pcap-ng.

Comments and thoughts below.

-Ken Renard



>>    Name:         shb_host
>>    Code:         5?
>>    Length:       Variable
>>    Description:  An UTF-8 string containing the name of the host
>>                  used to create this section.
>>    Example:      "foo.bar.com", "Sensor XYZ", "Router X, Span port 4"
>
>"Router X, Span port 4" sounds more like a comment for an Interface
>Description Block than a description of the host on which the data was
>collected.

Good point.  Agreed, that example is much better in the IDB.



>> so there is a need
>> to put a timestamp on each position record, and we should tie this to 
>> a specific interface mostly so that we can use its timestamp precision.
>> This would also allow you to have multiple interfaces at different 
>> locations.
>
>Sounds good.  Presumably if there's no LIB for a particular interface, the
>location of that interface would be unknown.
>
>Presumably if you have a mobile machine with multiple interfaces (two
Wi-Fi,
>or Wi-Fi + mobile phone modem, for example), multiple LIBs will be produced
>when the machine moves sufficiently to deserve that.

I think this is worthy of discussion.  It would be a waste to require (or
infer
that it is required) to generate a position block for each interface at each
chosen interval.  If I had N interfaces and chose to report positions every
second, that could get wasteful.  What do you think of a position report
that
references interface -1 (0xffffffff) which specifies "all interfaces" but
would
still need some timestamp resolution reference (default to microseconds?).
Our specific use case does not need interface-specific locations.  What do
others in the community think?  I prefer to keep it simple, but want to
catch
as many use cases as practical.



>If somebody's capturing while in motion, and we're not interested in
position
>or orientation information when packets aren't arriving, we could have
those
>options available for both LIBs and packet blocks, and say that the
position/
>orientation information for a packet is unchanged from whatever the last
>values were for that interface if the options aren't present.  That might
>allow less stuff to be written if we're only interested in the position and
>orientation at the time packets are captured.

Agreed.  Frequency of location information is defined by the
application/user.
Example use cases might be:

  1.  Set location description each time I wake up my laptop
  2.  Synchronous stream from GPS:  Once per second, per interface.
  3.  Every N seconds or change in position more than M meters.

Location information per-packet seems extreme, but certainly valid.



>Is there a standard origin (say, the North Pole) from which those are
>measured, is the origin provided out of band to the program interpreting
the
>capture, or should there be a block that supplies the origin?
>
>This also may not work well for space travel outside Earth orbit - it's
about
>54 billion meters from Earth to Mars:

My thoughts are that the origin would be externally-defined.  For example,
in
a network simulation, only XYZ coordinates might be used without an origin
reference.  I am certainly open to a origin reference description
(preferably
once per SHB or IDB, versus per location block).



>This also may not work well for space travel outside Earth orbit - it's
>about 54 billion meters from Earth to Mars:
>
>	http://www.space.com/14729-spacekids-distance-earth-mars.html
>
> If that becomes an issue, we could add a new option with 64-bit offsets.

Maybe an option for Astronomical Units instead of meters :-)  Good point,
see
below.



> I presume less-than-meter resolution isn't required; if that becomes an
> issue, the 64-bit-offset could be in less-than-meter units.

I defer to the community on the need for less-than-meter or more-than-meter
resolution.  Maybe a 64-bit version of the XYZ option where the resolution
is defined as well?  Such as:

  Option:       High-Precision-XYZ (28 bytes)
  Resolution:   32-bit signed int representing meter resolution
                (example:  value -6 is micrometer resolution, value 3 for
km)
  X location:   64-bit signed int
  Y location:   64-bit signed int
  Z location:   64-bit signed int



>>    Option 5:  Description (Variable)
>>               UTF-8 string containing some textual description of
>>               location.  (e.g. "DMZ", "Server Room", or "Starbucks")
>
>Presumably we could, for example, have most LIBs, and those packet blocks
>that need to update location information if we go that way, not provide
that
>option, and only provide that option if the textual description needs to be
>updated, so you don't, for example, repeatedly say "Starbucks" while you're
>walking around the coffee shop.

Agreed.  If location is specified every N seconds/packets/whatever, it would
be up the application to determine exact positions per-packet (if required).
An application could use most recently reported position or try to
interpolate
positions for each packet in between location blocks.


Classification: UNCLASSIFIED
Caveats: NONE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5573 bytes
Desc: not available
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150330/2a547231/attachment.bin>