[ntar-workers] Simple packet block

[Gianluca Varenni]

----- Original Message ----- 
From: "Stephen Donnelly" <stephen at endace.com>
To: <ntar-workers at winpcap.org>
Sent: Thursday, June 30, 2005 2:49 PM
Subject: Re: [ntar-workers] Simple packet block


> Loris Degioanni wrote:
>> Robin Sommer wrote:
>>> On Wed, Jun 29, 2005 at 17:40 -0700, Christian Kreibich wrote:
>>>> - I don't like the distinction in Packet Block and Simple Packet Block.
>>>
>>> I second that. In particular, I am not sure if the SPB will be
>>> helpful at all as it is not going to include any timestamps. The
>>> specification says:
>>>
>>> --------- cut -------------------------------------------------------
>>> The Simple Packet Block does not contain the timestamp because this
>>> is often one of the most costly operations on PCs. Additionally,
>>> there are applications that do not require it; e.g. an Intrusion
>>> Detection System is interested in packets, not in their timestamp.
>>> --------- cut -------------------------------------------------------
>>>
>>> Unfortunately, this is wrong wrt to intrusion detection: without
>>> timing information, an IDS is not able to perform any reasonable
>>> analysis. More generally, I believe that packet timestamps are one
>>> of the most valuable information contained in a packet trace.
>>> Essentially, almost all applications do need them.
>>
>> So almost all applications will use normal packet blocks.
>> However, as Stephen wrote a couple of days ago, there are some 
>> applications for which compactness and performance (any additional field 
>> can have a remarkable weight if you capture at millions pps) are of basic 
>> importance. They will use the simple packet block.
>
> I think having a SPB may be useful in some environments. When capturing at 
> high packet rates having unused option fields present is expensive in 
> bandwidth and space. Having the SPB not support the addition of optional 
> fields also simplifies parsing and should save time when reading the file.
>
> I'm not sure if it's reasonable for the SPB to not have a timestamp. I can 
> imagine there may be cases where one is not necessary, but in many cases 
> they are, even when size is at a premium. In these cases the SPB could not 
> be used, so we are forced back to the normal PB.
>
> For DAG cards the timestamp is generated in hardware so that operation is 
> is not expensive. Not writing the provided timestamp to disk would save 
> disk bandwidth/space, but may lower the utility of the collected trace too 
> much. I suspect most of our users would end up not using the SPB if it did 
> not have a timestamp.
>
> Are we left with three PB types, 'normal', 'simple', and 'simple+ts'? Some 
> of these surely would seldom be used, and the cost in parsing/application 
> support may be too high (accessor functions?).

I agree 100%: it's acceptable to have 2 packet blocks, but 3 is too much. 
For a very simple reason, in my opinion: it's confusing (= you end up having 
3 packet blocks because basically noone was able to decide which ones were 
better...)

Regarding the problem od supporting 2 or 3 packet blocks, I don't see a big 
overhead in that.

GV


>
> Thoughts?
>
> Regards,
> Stephen.
> -- 
> -----------------------------------------------------------------------
>     Stephen Donnelly BCMS PhD           email: sfd at endace.com
>     Endace Technology Ltd           phone: +64 7 839 0540
>     Hamilton, New Zealand               cell:  +64 21 1104378
> -----------------------------------------------------------------------
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers