Subject: psamp filtering

From: <[email-masked]>
Date: Mon, 29 Nov 2004 14:23:11 -0500

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). 

Also, "concatenation" implies that an order amongst the basic filters is
to be specified. 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? 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."

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: Maurizio Molina <[email-masked]>
Date: Tue, 30 Nov 2004 10:34:12 +0000

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

>to be specified.
Correct, but the result will then be independent of the  order.

> As Matt Grossglauser has pointed out, this might be
>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
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