[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: a paper on packet sampling
> > 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 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.
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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.