[Planetlab-users] probing for bandwidth measurements

Fri May 6 08:13:19 EDT 2005

Gaurav,

some quick comments and a couple of pointers:

> But if we are measuring gigabit networks then the order of error will
> be almost similar to our sending rate which is a big problem, which i
> guess can be handled by using some filter mechanism or some averaging
> etc..
>
> So, according to me bandwidth estimation techniques should work fine
> for measurement in upto 100Mbps networks..
>

Bandwidth measurements in networks where the bottleneck is faster
than 100Mbps are definitely harder, but still doable. First, we
need to worry about interrupt coalescence, detect it automatically,
and find a way to filter the measurements so that we stil get the
right result. This is what we did with both Pathrate and Pathload at:
http://www.pam2004.org/papers/265.pdf

Second, you need to consider that "dispersion" errors due to queueing
are not of a fixed magnitude, but they depend on the capacity of the
bottleneck. Suppose that a cross traffic 1500byte packet interferes
between your packet pair causing a dispersion error. The magnitude
of the error is 1.2ms at a 10Mbps link, 120usec at a FE link, and 12usec
at a GigE link.

People have done bandwidth measurements in Gigabit paths. I suggest
you look at the following paper:
http://www.pam2005.org/PDF/34310310.pdf
It is based on measurements from both a gigabit testbed and from some
Internet2 paths.
An important point that this paper showed is that there can be major
differences between tools that all appear as "similar", from the outside.
This is why I think we should be careful with general statements about
what works and what doesn't.

> test beds and simulators always give you the desired results because
> they are 100 % deterministic, but for quantities such as network
> parameters which are dependent on complex queuing and hell lot of
> different factors a solution which works well for a test bed might not
> work in a real scenario.
>

This is not true. Testbeds (or emulated networks such as EmuLab) use
real hosts and routers, and so they would involve all the queueing
or end-host effects you would have in the real world. The
traffic generation process can be realistic if it is trace-driven (even
though "realistic" is not synonymous with "real" here).

Simulations, on the other hand, are absolutely necessary as well
in my opinion. The reason is that they can be used to do repeatable
and controllable experiments, helping the designer to examine the effect
of different factors and load conditions. Simulations cannot replace
the value of real-world measurements, but the latter cannot replace
the former either..

Constantine

>
> On Thu, 5 May 2005, Constantine Dovrolis wrote:
>
> >
> > Neil,
> >
> > there are several things here:
> >
> >>
> >> I'm looking forward to Manish's report -- I'd like to know what train
> >> he can get on plain linux but not on planetlab.  It's tough to send
> >> packets uniformly at 5ms spacing with any other process running even on
> >> a plain linux machine.
> >>
> >
> > Manish can elaborate on how we do this at pathload. Long interarrivals
> > are controlled with timers while short interarrivals are controlled
> > with busy waiting. This has not be a problem in the experiments that
> > we did (using linux, freebsd, and solaris boxes) in our testbed, or
> > in machines that are not as heavily loaded as planetlab. Pathload
> > uses techniques to detect whether the send or receive hosts experienced
> > significant context switching while the streams were sent/received.
> > In that case, the tool typically aborts the measurements or
> > raises warnings.
> >
> >> To be clear, my position, without much evidence, is that PlanetLab is
> >> at least as good as a shared linux machine, (ignoring the rate-limits)
> >> and that defensive programming is required everywhere to ensure that
> >> what you think you send is really what you sent.  I believe that
> >> Pathrate is the hardest possible tool to get right on Planetlab because
> >> of its need for precise timing over relatively long durations (unlike,
> >> say, packet chirps which need less time).
> >
> > I disagree with this in two ways:
> >
> > 1. Planetlab is a much harder environment for available bandwidth
> > measurements (not to be confused with capacity or bottleneck bandwidth
> > measurements), because the latter require  precise rate probing and
> > sensitive timing measurements, and both of these requirements are harder
> > to achieve as the load of the sending or receiving host increases.
> > The presence of rate limiters at Planetlab makes things even harder
> > because most available bandwidth tools need to be able to control
> > the rate of the outgoing streams.
> >
> > 2. Pathrate does capacity measurements. Pathload does available
> > bandwidth measurements. It is the latter type of measurements
> > that are the most problematic in Planetlab, as the following talk
> > also showed.
> >
> >> Would someone who attended last week's meeting summarize:
> >>
> >> http://www.planet-lab.org/Talks/2005-05-01/planetLab_meeting_050105.ppt
> >>
> >> It seems some folks have very recent experience with pathrate on
> >> planetlab.
> >
> >
> > I was not at that Planetlab meeting but this presentation was also
> > given at PAM 2005, which I attended. That work focused on capacity
> > measurements, not available bandwidth. The authors decided
> > to use Pathrate because that was the most accurate and stable tool
> > for that type of measurements. The authors, as far as I know,
> > wanted to also do available bandwidth measurements but they faced
> > problems with all the existing tools. As I explained earlier that
> > should not be a surprise; Planetlab nodes are too heavily loaded
> > for available bandwidth measurements. Whenever we want to do
> > such measurements, we prefer to use RON hosts or other machines
> > around the world where we have an account. For more controllable
> > experiments, we prefer to use our lab testbed, using trace-driven
> > cross traffic generation.
> >
> >
> >
> > Constantine
> >
> > _______________________________________________
> > Users mailing list: Users at lists.planet-lab.org
> > https://lists.planet-lab.org/mailman/listinfo/users
> >
>