[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packet Selectors and Packet Information
Hi Andy,
To me 1. .i.e packet selectors refers to the mechanisms of measurements.
Like sampling 1 in 100 etc. This could be time-based, packet property based,
or a combination of these. Now the inputs to this measurement
may be one or a combination of fields described in b). For example the
measurement
mechanism could be filtering in which say {ingress i/f, ipsrc} goes as input
and the operartion done is say mask & match a pattern against these inputs.
More inline ..
Andy Bierman wrote:
> Hi,
>
> I would like to start clarifying the scope of the "Packet Selector and
> Packet Information" document. Note that the framework assumes that
> packet selection refers to the set of packets from which packet sampling
> will apply -- it is not the packet sampling itself, but rather the
> packet pre-filtering. Anyone wishing to write an individual I-D
> to address this deliverable is strongly encouraged to do so,
> as soon as possible.
>
> First, here is some text from the WG charter about these tasks:
>
> 1. Selectors for packet sampling.
> Define the set of primitive packet selection operations for network elements,
> the parameters by which they may be configured, and the ways in which they
> can be combined.
>
> 2. Packet Information.
> Specify extent of packet that is to be made available for reporting. Target
> for inclusion the packet's IP header, some subsequent bytes of the packet,
> and encapsulating headers if present. Full packet capture of arbitrary
> packet streams is explicitly out of scope. Specify variants for IPv4 and
> IPv6, extent of IP packet available under encapsulation methods, and under
> packet encryption.
>
> General Question:
> a) Should these topics be separated into 2 documents, or combined into 1
> (as the charter suggests)?
1 document IMHO.
>
>
> Packet Selector Issues:
> b) What specific stateless packet selectors are needed?
> - ingress or egress interface?
> - any MAC layer fields (SA, DA, protocol)?
> - any VLAN header fields (VLAN ID, vlan priority)?
> - which IP header fields?
> - should tunneled protocol encapsulations be supported?
> - which transport protocols? which fields?
> - application identification supported (beyond 5-tuple)?
>
> c) How should combinations of selectors be configured?
> - bitmask?
> - boolean expression (like C 'if' statement)?
> - regular expression/pattern matching?
If the aim is ubiquity (as described in the charter), then the
default selectors have to be really simple like use a standard sampling
algorithm.
Again the question above is how many different types of operations are
permitted in a measurement and how they can be combined. One can
potentially write a C code to match in one or all of the above ways in
any sequence.
The main problems here are 1. describing the measurement to the
collector. 2. deployment in existing products.
Therefore my suggestion is start with something simple.
>
>
> d) Should any stateful (multi-packet) selectors be supported? If so, how?
Can you explain what is meant by multi-packet selector? Is it based
on a flow?
>
> e) Is there any existing publicly available work (e.g. IPFIX) that
> can be used as-is, or adapted, for PSAMP packet selection?
One major difference that I see with IPFIX is the notion of flow
in IPFIX (selection criteria is for packets in a flow) while PSAMP
is not strictly tied down to packet selection from within a flow.
>
> f) Should the default selector be 'no packets' or 'all packets', or
> should this be configurable, with no default?
Is that not dictated by the measurement criteria? Say we do sampling
followed by filtering it depends on the sampling rate & mechanism.
But if it is filtering followed by sampling, then the first measurement is done
for all packets and the second measurement based on sampling rate &
mechanism.
>
> g) Other criteria for selecting packets
>
> Packet Information Issues:
> h) Which fields should be eligible for inclusion (see 'b' above)?
The fields could be listed as MUST, SHOULD & MAY. There
could be fields which are uniformly available from all psamp devices
(like ingress interface (?), some router state fields) which should be
deemed mandatory.But the protocol fields depend on device capability
and here we need to make a distinction as to which are/are'nt the
mandatory fields for this class of products. Retrieving packet headers/
portions of packets again has dependency on device capability &
level of privacy required for the packets that pass through the device.
Thanks
Ganesh
>
> i) What 'external' packet information should be recorded for
> potential inclusion in a sample report (e.g. arrival timestamp,
> ingress or egress interfaces)?
>
> j) How should privacy be enforced? Is there a way to specify which
> protocol payloads cannot be eligible for inclusion? Should this
> be configurable, globally, or per packet sampler?
> k) Should it be possible to retrieve entire packets, or all fields
> from a particular protocol layer, in some circumstances? (e.g.,
> ICMP, ARP, DHCP, etc.) Should this be configurable? If so, how?
>
> It may be a good idea to break up this discussion into multiple
> threads, to help track each issue. This email is just intended to
> start some discussions.
>
> thanks,
> 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/>
--
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/>