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

RE: psamp filtering


See question inline below,


> -----Original Message-----
> From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
> 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
> >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
> >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)
> >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
> 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,
> >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
> part of your text to leave the door open to implementation of
> filters in "one step".
> My proposal:
> AND operations are possible by concatenating filters through the use
> the STREAM ID (see sec. 7.1 and 8). In this case, the ordering in
> the filtering happens is implicitly defined (outer filters come after
> inner filters). However, as long as the concatenation is on filters
> the result of the cascaded filter is independent from the order, but
> order MAY be important for implementation purposes, as the first
> will have to work at a higher rate. In any case, an implementation is
> constrained to respect the filter ordering, as long as the result is
> same, and it MAY even  implement the composite filtering in filtering
> one single step.
> Maurizio

Do you view the concatenation as a composite selector, with each
component filter a primitive selector? If so, the text in the framework
document Section 5.5 needs to include this as an example of a composite

> >Finally, it was suggested to me at IETF 61 that the current text in
> >framework draft (it speaks of match/mask operations) should be
> >with the text from the sampling draft. I can do this once the latter
> >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/>

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