Re: making psamp export congestion-aware

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

Senthil,

> How netflow floks account for reliability for some applications like
> billing & accounting.

In psamp, we don't need to worry about Netflow does this, but in any
case...  I think there are two possible approaches.  1) Put a
collection box very close to the router with a well-provisioned path
to prevent packet loss.  2) Allow some amount of loss and do
statistical correction for it (and only charge for the statistical
statements you are comfortable making about the data).

> I think reliable export can be used when one sent's aggregated
> data(as the extra work done to make it reliable doesnt make a big
> difference) which is not the case with psamp.

Yes, good point.

> My another important point is:Exporting will itself eat lot of router
> processing and so additional burden of keeping the state will make the
> processing worse.

Yes, this is an important part of the motivation.  I think (?) that we
are likely to mostly agree on unrelieable export.  The main issue is
how to approach the problem of being congestion-aware.

> How do you account for failure of collector(another strongly debated topic)

In the congestion-aware framework mentioned in my previous message, we'll
need some way to handle the case of 100% loss -- when the collector fails,
all export packets are lost, or all reconfiguration-of-export-rate packets
are unable to reach the router.  Otherwise, any of these events could cause
the psamp device to keep sending export packets at the last-configured rate.
We'll need some sort of soft-state for the export rate (with an expectation
of periodic refresh).

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