Maurizio,
See question inline below,
Nick
-----Original Message-----
From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
Behalf
Of Maurizio Molina
Sent: Tuesday, November 30, 2004 5:34 AM
To: Duffield,Nicholas G (Nick)
Cc: psamp@ops.ietf.org
Subject: Re: psamp filtering
duffield@research.att.com wrote:
In the sampling techniques draft:
6.1 Field Match Filtering
We here define a basic Filtering schemes based on the IPIFIX
flow definition. With this method a packet is selected if a
specific field in the packet equals a predefined value. Possible
filter fields are all IPFIX flow attributes specified in [IPFIX-
INFO]. Further fields can be defined by vendor specific
extensions.
A packet is selected if Field=Value. Masks and ranges are only
supported to the extend to which [IPFIX-INFO] allows them e.g.
by providing explicit fields like the netmasks for source and
destination addresses. AND operations are possible by
concatenating filters. OR operations are not supported with this
basic model. More sophisticated filters (e.g. supporting
bitmasks, ranges or OR operations etc.) can be realized as
vendor specific schemes.
As it stands now, this text might give the impression that AND
operations are accomplished by composing a number of PSAMP selectors,
each being primitive and corresponding to filtering on a single
field. I
don't think this is what is intended. (In any case, PSAMP can
currently
only combine one filter with one sampling operation at present).
My understanding is that through the STREAM ID you can have multiple
concatenation, and even a filter + filter concatenation (and in this
case the order is intrinsically specified).
However, I admit that from the TOC only it looks like that the only
possible composition is Cascaded Filtering->Sampling or
Sampling->Filtering (se. 8.1). But if you read the text before, it
states that it is just an example.
Also, "concatenation" implies that an order amongst the basic filters
is
to be specified.
Correct, but the result will then be independent of the order.
As Matt Grossglauser has pointed out, this might be
useful if one wants to put a "quick" filter (e.g. on port number)
first,
to reduce the packet rate down for a "slow" filter (e.g. on routing
state) following. So do we want to require ordering of filters within
the combination?
See above: I think that if you specify a cascaded filter via the
STREAM
ID, ordering is implicitly defined, but the result will then be
independent of the order.
Or would some implementors want to implement some or
all combinations as a single composite mask/match across fields,
without
ordering....?
If order is not specified, we might want to replace
"AND operations are possible by concatenating filters"
with
"AND operations are possible by specifying multiple basic field match
Filters, the packet being selected if would be selected by all the
specified filters. The resulting combination is viewed as a primitive
PSAMP Selector."
I think that if we go for your proposal, we have to ensure that
IPFIX-INFO supports it.
I'd rather stick to the old text for SPECIFYING a filter. Then I'd
add
part of your text to leave the door open to implementation of
composite
filters in "one step".
My proposal:
AND operations are possible by concatenating filters through the use
of
the STREAM ID (see sec. 7.1 and 8). In this case, the ordering in
which
the filtering happens is implicitly defined (outer filters come after
inner filters). However, as long as the concatenation is on filters
only,
the result of the cascaded filter is independent from the order, but
the
order MAY be important for implementation purposes, as the first
filter
will have to work at a higher rate. In any case, an implementation is
not
constrained to respect the filter ordering, as long as the result is
the
same, and it MAY even implement the composite filtering in filtering
in
one single step.
Maurizio
Do you view the concatenation as a composite selector, with each
component filter a primitive selector?