4.3.2.7.2.20020816215608.00baa770@fedex.cisco.com">
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.
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 pres
ent. 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.)
Correct me if I'm wrong, AT&T folks, but the trajectory-based sampling
(hashing on selected fields within the header and then sampling based on
matching select bits within the hash) that they are proposing allows for
the selection of a flow. The sample stream, however, will potentially contain
packets from other flows that happen to hash to the same values. 4.3.2.7.2.20020816215608.00baa770@fedex.cisco.com">
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/psa
mp/>
--
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/>