[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packet Selectors and Packet Information
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.
Andy,
thanks for kicking this off.
I think there's some confusion on terminology here. In the draft
framework, charter, list discussion, and WG presentations, "packet
selection" includes
those mechanisms used to do what you are calling "packet sampling".
Indeed,
the charter says:
"The focus of the WG will be to (i) specify a set of selection
operations by which packets are sampled"
Or see e.g. http://www.ietf.org/proceedings/02mar/slides/psamp-6.pdf
The word "selection" was used to be inclusive of a number of different
methods under discussion for extracting subsets of packets for reporting
on. Methods that have been discussed so far are filtering, 1 in N
sampling
(including periodic and statistical) and hash-based sampling. The word
"selection" was used in addition to "sampling", because it was found
that
for some people the latter means specifically 1 in N sampling.
If the terminology isn't clear here, do we need to come up with
something
better? With the words currently at my disposal, my usage is:
1. sampling = 1 in N (periodic or statistical) or hash-based
2. filtering = filtering
3. (primitive) selectors = either 1 or 2, and further methods TBD
4. (composite) selectors = composites of methods from 3
So the work of item 1:
"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."
is precisely to lay out what these selectors are.
For the discussion on pre-filtering, the phrase "and the ways in which
they can be combined" is key. In the framework, filtering is one of
several packet selection mechanisms, which may be combined to form
composite packet selectors. For example, a composite selector whose
fist component is a filter and whose second is 1 in N sampling.
One question we need to address is whether filtering would always be
the first component of a composite selector. If not (e.g. suppose you
want to do 1 in N sampling followed by filtering) then I don't think
it makes sense to give "pre-filtering" any special status over what one
could call "post-filtering" (i.e. filtering after some other packet
selection operation).
What do people think?
Note also that there is demand for applications to have packet selectors
which involve no filtering. Thus it would be too restrictive to
*require*
filtering.
Nick
--
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/>