[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 



Finally, it was suggested to me at IETF 61 that the current text in the
framework draft (it speaks of match/mask operations) should be replaced
with the text from the sampling draft. I can do this once the latter is
finalized.

Comments?

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/>