RE: Packet Selectors and Packet Information

[Andy Bierman <abierman@cisco.com>]

At 10:53 PM 8/15/2002 -0400, Albert Greenberg wrote:
>> 1. Selectors for packet sampling.
>> Define the set of primitive packet selection operations for network
>elements...
>> 2. Packet Information. 
>> Specify extent of packet that is to be made available for reporting...
>
>> General Question:
>> a) Should these topics be separated into 2 documents, or 
>> combined into 1
>>    (as the charter suggests)?
>
>Hi Andy,
>
>(2) is low complexity compared to (1), and there is appeal in getting
>easy things out of the way.
>
>A low complexity, universal, solution (discussed earlier on the list; by
>me, Sonia Panchen, Derek Chiou) that should stand the test of time is to
>define the info avail for reporting to be the first n bytes, with n
>somewhat configurable.  This info might be compressed or hashed.
>Selector type/id should be associated with the report of this info.
>Other than that, selector specification and packet-info appear uncoupled
>to me, and could be treated in separte docs.
>
>Thoughts?

I think you are combining the packet information and report format
into the same problem. I know they are related, but not quite the
same.  The approach you are describing doesn't seem too optimal,
although it does appear easy to implement (collection and report
generation).  I agree that some information can be passed in the
selector ID, depending on the selection algorithm used.  I doubt
the compression ratio for such a small chunk of binary data
would be interesting -- maybe compression on the report stream
would be interesting.  Hashing the packet information would not
be much more interesting than knowing the selector ID in many cases.

I think it's okay to keep the packet selection simple (first N bytes),
but it might be desirable to allow for configurable data selection
(by field name, not byte offset) in the report generation phase.
I don't feel strongly about this feature though, especially for
HW implementations which won't be capable of fully parsing all the
various protocol fields within the packet.  A compromise might be
an adapted RMON-2 packet filter (select M bytes starting
at the N'th byte after the start of a particular protocol layer
boundary).  This allows for data extraction even in the presence
of variable length headers.


>-- Albert 

Andy


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>