Derek Chiou wrote:
Hi,A report format should also be flexible enough to give the exact informationThe 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.I think so. Charter says that "congestion awareness" is required. This could implyHowever, 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?
Peram
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.
Derek
Albert Greenberg wrote:
61309E3CCC01CB4D86EC4F3F0E328DB901354F@njfpsrv03.research.att.com">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.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. -- Albert -- 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/>