[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packet Selectors and Packet Information
Andy Bierman wrote:
> At 02:31 PM 8/16/2002 -0700, Ganesh Sadasivan wrote:
> >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 ..
>
> Packet selectors are different than sampling algorithms, at least
> that is the operational model being proposed. These are pre-sample
> filters that potentially reduce the set of eligible packets for
> sampling from the set of all packets on an interface. The sampling
> algorithm runs on this potentially reduced set of packets.
The above means a a packet is subject to a set of pre-sampled selectors
followed by a sampling algorithm. Isn't that too restrictive. The charter says:
"The focus of the WG will be to (i) specify a set of selection operations by
which packets are sampled "
The way I interpreted it is to specify a list of selection operations eg.
filters, hash functions or sampling (as it is used today) to pick the packets.
.i.e the packet is subject to one or more of the list of selection
operations.
Thanks
Ganesh
>
>
> >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.
>
> starting simple seems to be a popular choice. I know of HW that
> can perform a simple OR expression (or AND expression) for
> a small set of static fields in a packet (hint: the kind of
> fields that would be interesting to a switch/bridge/router
> for forwarding/learning decisions).
>
> >>
> >
> >>
> >> 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?
>
> yes. There are some state applications that require multiple packets
> in the flow to correctly determine the application protocol. We
> can leave this out, since it's not simple. (Note that just because
> I asked a list of questions doesn't mean I think we support all these
> things. I just wanted to find out where the WG stands on these issues.)
>
> >>
> >> 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.
>
> this is the pre-sampling filter, not the sampling algorithm.
> The default case could be start will all packets, and there
> is no pre-sampling filter.
>
> >>
> >> 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.
>
> good point. All of the configurable aspects of PSAMP will likely
> be constrained by implementation capabilities.
>
> >Thanks
> >Ganesh
>
> Andy
>
> >>
> >> 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/>
--
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/>