3D61487D.CF0429D4@cisco.com">
Hi Nick,
Nick Duffield wrote:
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"
In the above sentence, "packets are sampled" does not refer to a
sampling mechansim. Looks a little confusing. It is basiscally a set of
measurement mechanisms which can be combined together in some
fashion to select packets. Do we need to change this to something like this:
"define the set of operation the combination of which is used to select
packets"
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) selecto
rs = 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).
Ideally any number of selection mechanism could be applied in any
sequence (not talking about the parallel simultaneous measurements here).
I can't think of a reason why we should restrict the number and sequence
of the selection mechanism. Am I correct?
Yes, there are implementation concerns. Having packets travel down a fixed
pipeline is relatively easy. Having packets bypass one functional unit to
go to the next one, then return to the first functional unit can become painful
and/or costly.