Re: next step

[Jennifer Rexford <jrex@research.att.com>]

> 1.where exactly the packet filtering have to be applied ? Physical
> interface or the router loop back interface

This could be implementation-specific, but I imagine that the
filter-based selection would take place on the interface card for
high-speed routers.  Directing the data packets through the central
processor (Loopback) wouldn't be feasible at high speed.

> 2.Another application oriented question..Can psamp be helpful in 
> policing the traffic when it travels from the edge to core

My understanding is that psamp is meant to be non-intrusive -- it
observes some subset of the packets as they flow through the network
and generates measurement records for these packets.  An application
built on top of psamp might characterize the traffic and, based on
that analysis, install ACLs that actually discard or police certain
traffic (say, corresponding to a DoS attack).  That control action,
though, would be completely separate from psamp and, in particular,
separate from the filter-based selection of packets for sampling.

> 3.Their may be times when the export rate may approach the router's
> packet forwarding rate. The framework draft says that a (configurable)
> limit of the no of measurment records per unit time will be imposed.
> So,what exactly be the process if it goes above the limit..just drop
> or some sort of recovering the sampled packets.

Drop may be reasonable.  The key points are that (i) a rate limit
could be imposed and (ii) the measurement records should contain
enough information to know that the loss(es) occurred, so that
downstream applications could account for the loss as needed.

> 4.The performance in packet forwarding could outwit the performance
> of measurement eqipments with advances in optical switching. what
> might be the solution at such times? Is it like the packet sampling
> have to be done more closer to the collector.

Keeping the psamp functionality as simple as possible (and tunable,
using filter-based selection and a one-out-of-N sampling) should help
it scale to higher link speeds.  Still, psamp does require looking at
the packet headers, at least for some fraction of the traffic.  This
doesn't seem feasible in an entirely optical switch.  In this case,
psamp would be possible only at the "edge" where you go from
electronics to optics.

-- Jen


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