RE: a paper on packet sampling

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

Many thanks for the comments! See below please.

> > > 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.
>
> Sampling is also needed in enterprise/intranet settings. If provides an
> economical way to monitor traffic across the thousands of switch ports on a
> large campus network. Traffic levels on enterprise networks can also be very
> high (during database backups for example). The main difference between
> monitoring an enterprise network and monitoring a core Internet router is
> that the statistical populations are very different. The enterprise network
> is a much smaller statistical population and tends to be much more
> homogeneous in applications/user behavior.

I definitely see the need of measurement there. It is always good to have
a more economical way of monitoring. Do you have any reference/literature
on the need of 'sampling' even on campus/enterprise network (for example,
resource usage ratio for monitoring purpose)? It will help
to promote consensus on sampling, since some people just don't like the
idea of sampling, when full measurement is possible.

Statistical behavior of enterprise network would be interesting to see,
because both homogeneity in application/user behavior and high level of
traffic mix would decrease the variability of the packets.

>
> I have one final comment about the practical limits of dynamically varying
> sampling rates. Depending on the sampling algorithm and router/switch
> architecture, there may be limits in how frequently and precisely one is
> able to change sampling rates. For example, suppose sampling is done by
> loading a register with a number of packets to skip. The register is
> decremented with each packet and when it hits zero a sample is taken and the
> register is reset with a new skip count. In this case a change in sampling
> rate may not take effect until the the register is reloaded with a new skip
> count (some indeterminate period of time after the sampling rate was
> changed). Further, it's possible that the skip counts could be stored in a
> fifo resulting in an even longer period before a change in sampling rate
> would take effect. This can be further complicated if the sampling functions
> are distributed in multiple locations throughout the router/switch. Most
> high capacity switches use distributed architectures and precisely
> coordinated global state changes can be difficult to achieve.

We have shown theoretical limitation of sampling can achieve for the type
of estimating traffic load. If one can not variate the sampling rate as
often as the estimation period, one variation of the usage could be
setting sampling rate a little bit higher than the one for the orginal
accuracy.
Then the linear relationship among required number of samples,
desired accuracy and variability of packet sizes can be used to report
achieved statistical accuracy.
In any case, with the 'fluctuations of traffic', to avoid extreme
unnecessary oversampling or significant loss in accuracy,
sampling rate has to be modified possibly in varying intervals.
For further analysis based on the estimation such as change point
detection, we have also illustrated that due to the impact of error on
the performance, it is important to bound/control the error.

>
> I am not sure how frequently you anticipate changing sampling rates. If
> intervals are of the order of minutes then these timing effects are unlikely
> to be significant. If you want to make changes at intervals of seconds or
> tens of seconds then it could be a problem.

The frequency of changing sampling rates depends on its application. For
the applications we had in mind, the interval is in the order of minutes.

Just for the information to others, to decide a sampling rate at the
beginning of the estimation interval(*not per packet*), the prediction of
the two traffic parameters involves only 16(9 multiplication+6addition
+1division)*2 algebraic computations to generate the level of accuracy
presented in the paper.

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


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