[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packet Selectors and Packet Information
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) 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).
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?
>
>
> 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.
Agreed.
Thanks
Ganesh
>
>
> 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/>
--
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/>