RE: a paper on packet sampling

[Baek Young Choi <choiby@cs.umn.edu>]

THANK YOU VERY MUCH for your time reading the paper and giving valuable
comments! Responses are embedded below.
--Baek-Young

> The paper presents an interesting technique for varying sampling rate in
> order to achieve a fixed error bound for load measurements made over time.
>
> I can see the application of this technique to detecting a change in traffic
> on a particular route, in a particular application class, from particular
> sources etc.
>
> In these cases it is likely that more than one measurement is being computed
> at a time. You are not likely to be interested in only monitoring one route
> at a time, but all routes. One could run the adaptive sampling algorithm on
> each category independently. Taking the minimum of the resulting sampling
> rates would ensure that all bins achieved the desired accuracy. The use of
> packet sampling in these situations is compelling since there aren't simple
> alternatives, particularly if the number of categories is large or changes
> dynamically.

Right! We've been working on estimating flow statistics
using the technique. Here the flow can be generic such as session
level(src ip, dst ip, src port, dst port, protocol) or their aggregation
by protocol, src subnet, etc.

For that purpose, there are other issues involved like
dynamic arrival/duration of flows and flows with small number of packets.
However, the prevailing elephant/mice behavior gives us big advantage.
In short, the packet sampling for flow estimation reduces the overhead of
maintaining large flow cache, in addition to reducing per packet
processing overhead.

>
> In this case the target sampling rate is something that needs to be
> determined by the application, and used to control the sampling engine. A
> different application tracking different categories would have a different
> target sampling rate.
>
> Provided that PSAMP allows sampling rates to be set by applications (through
> a MIB for example) and exports the actual sampling rate used along with the
> sampled data then an application would be free to adaptively control the
> sampling rate according to this algorithm.
>
> The paper could be clearer in idenfiying the problem being addressed. At
> first I interpreted it as a technique for measuring the total load on a
> link. A more direct way of identifying a change in load on a link is to poll
> the ifInOctets/ifOutOctets counters maintained by virtually all network
> devices. A discussion of the multivariate nature of load measurement would
> make the application of the technique clearer.

Thanks a lot for the comment.

>
> I also wonder whether the technique would work as well in an intranet
> environment. Were the traces primarily from busy Internet routers? Core
> traffic tends to reflect a much larger population of users and have more
> predictable statistical properties.

The average arrival rates of the traces vary from 49KBps to 25MBps.
The long traces from which the main statistics are generated are low rate.
(We don't find any public packet traces whose duration is long enough as
well as high speed.)

> In my experience, intranet traffic can
> be heavily dominated by the characteristics of particular applications and
> hosts. An extreme example would be monitoring an individual desktop
> computer. It will show "on/off" types of traffic loads.  The link is mostly
> idle, punctuated by heavy loads as files are opened, mail is sent etc. In
> this case there is little predicive value in knowing the load in the
> previous interval.

I agree. The technique is aimed for high speed (high mulplexing) link,
where sampling is more in need.

>
> Peter
> ----------------------
> Peter Phaal
> InMon Corp.
>
> Peter_Phaal@inmon.com
>


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