[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sample report format, was Re: Packet Selectors and Packet Information
The issue of sample report format is made complex by implementation concerns.
I agree with Albert and Sonia that it is most flexible just to send the
first n bytes of a packet (where n is something small ish like 128) plus
some select information that would not be contained in the packet, such as
the input interface. The collector could then aggregate/filter that sample
as much as it likes.
However, simply sending the first n bytes can potentially double the output
of a particular line card which will cause many line cards to choke. An
aggregated report format can reduce that output rate, potentially making
it easier to implement.
However, if we can come up with the right way to compensate for dropped report
packets, then perhaps it's ok to have the potential of much higher output
rates of the first n bytes of each sampled packet in raw format.
However, determining whether report packets have been dropped itself requires
some state (at least a counter) on the sampler.
We may also want to consider the load on the collector. The collector is
likely to be a general-purpose computer attached via Ethernet to the sampler.
It's quite possible that the collector cannot keep up depending on the report
format. Is collector load something we should be concerned with?
And so on.
My gut feel is that we should just send the first n bytes of the sampled
packet, plus some extra info (that we need to determine) such as the input
interface. It seems, however, that we should perhaps keep the topic open
for now until other issues, such as congestion control for report packets,
are worked out.
Albert Greenberg wrote:
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
Hi Andy, The reverse. On selection you may want to exclude some fields
(e.g., ttl) and include others, or want ACL type filtering to drill down
on certain packet streams. Reporting on the first N bytes is simple,
fairly future proof (e.g., you may want to look at ttl's at some data
after the data is generated), and (the original point I was making)
allows for simple decoupling of the document on selection from the
document on which data to make avail to reporting.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.