[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: psamp filtering
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? If so, the text in the framework
document Section 5.5 needs to include this as an example of a composite
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 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/>