[pcap-ng-format] Proposed new Alternative Packet Block

[Serge Aleynikov]

What is the process of getting new proposals merged with the
https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.xml
draft?

Is that that the proposal is discussed on this list and then a PR is
submitted to the https://github.com/pcapng/pcapng repository?

On Sun, Aug 14, 2016 at 12:25 AM, Guy Harris <guy at alum.mit.edu> wrote:

> On Aug 13, 2016, at 8:57 PM, Serge Aleynikov <serge at aleynikov.org> wrote:
>
> > ​So, with this revision, let's ​modify the layout of this option type,
> and also for the purpose of preserving alignment, let's keep the code/value
> 2 octets each:
> >
> > ​ 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
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |0 0 1|      Option Code        |         Option Value          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Hence, revised option codes become (with added apb_iface_id option):
> >
> > Options:
> >    Name          Code    Length  Multiple?  Description
> >    apb_opt_size  0x2001  -       no         Total byte size of options
> >    apb_orig_len  0x2002  -       no         Packet's Original Length
>
> That means that the APB can't be used if the original length was > 65535.
>
> Preserving alignment for short options might not be *that* important if
> supporting packets > 65535 bytes in length *is* important.
>
> >>>    4-11     Compression type
> >>>                 0  = uncompressed
> >>>                 1  = lzw
> >>>                 2  = gzip
> >>>                 3  = bzip2
> >>>                 4  = zip
> >>>                 5  = 7z
> >>>                 6  = lzo
> >>>                 7  = ucl
> >>>                 8  = snappy
> >>>                 ...
> >>
> >> So that indicates the form of compression used on the packet data?
> >
> > ​Right, to conserve space, pcap-ng writing app​lication could choose to
> compress packets. One thought here is that perhaps that should be a
> file-level setting in the Interface Description Block rather than on the
> per-packet basis as proposed here?
>
> If there's no need to compress different packets with different
> compression mechanisms (or to compress some but not all packets), putting
> it in the IDB would make sense.
>
> However, that wouldn't apply to other block types - a file has to be
> readable by programs that don't understand that option, so the other block
> types can't support compression.
>
> >> There's no ​​FCS length field; do these packets have an FCS iff the
> "FCS length" field for interface 0's IDB is non-zero (so that all packets
> for that interface, whether they were transmitted by this host or received
> by this host, either have an FCS or don't have an FCS)?
> >
> > ​Wouldn't that frame check sequence be part of the packet data?
>
> Yes, but there needs to be a way to indicate whether it's present, as it's
> not *always* part of the packet data.  For the EPB, there's both the IDB
> indication and a per-frame indication, in case either
>
>         1) the FCS length changes over time (e.g., if the presence or size
> are changed by negotiation in the middle of a PPP connection)
>
> or
>
>         2) not all frames have an FCS (e.g., if received frames have one
> but transmitted frames don't).
>
> For the SPB, the FCS must be present, or absent, in all frames, and, if
> it's present, it must have the same length in all frames, as there's no
> per-frame indication.
>
> For the APB, if there's no per-frame FCS indication, it must be present,
> or absent, in all frames, and, if it's present, it must have the same
> length in all frames.
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20160815/16284207/attachment.html>