[Tmrg] Round-table PFLDnet submission

[Lachlan Andrew]

Greetings,

On 09/12/2007, Sally Floyd <sallyfloyd at mac.com> wrote:
> > Greetings Romaric,
> >> Quoting Lachlan Andrew <lachlan.andrew at gmail.com>:
> >
> > I've given
> > reasons that I think this test should be different and *not* have the
> > pseudo-random background traffic:
> > 1) It adds statistical errors (different experiments will have
> > different numbers of flows at the instant of interest)
> > 2) It does not really increasing the realism in this case (flows are
> > unlikely to arrive within the RTT or so during which the window is
> > being reduced, so any flows present at the time are essentially
> > "long-lived").
> >
> > If anyone can show how it does significantly add realism or how to
> > avoid the statistical errors, then let's keep the background traffic.
> > Otherwise, I strongly prefer to remove it.
>
> I think it is important to keep some amount of background traffic and
> reverse-path traffic in the scenarios about transients.  Just for a
> start, the background traffic strongly affects the degree of
> synchronization in the loss events (do all flows have a loss at the same
> time, or not), and this can strongly affect any of the metrics that are
> being measured about the response to the transient events.

Synchronization is certainly relevant if there is a significant amount
of background traffic.  Remember that if we have 10% of traffic being
background traffic, then about 80% of the time the only flow in the
system is the long-lived flow of interest.  Consider a step increase
in UDP traffic:

a) If the transient occurs during the normal 80%, then we didn't need
the cross traffic -- the flow of interest is perfectly synchronized
with itself, and will definitely suffer a loss within the first RTT
(and most likely each RTT until it drops its rate enough) when the UDP
starts.

b) If it occurs during the 20%, then we're measuring a statistical
outlier, not the normal behaviour.

That means that synchronization rate is not a strong reason to
introduce cross traffic in this case.  You mentioned that
synchronization was "for a start".  Could you list other reasons?

The transient when the UDP is decrease will last many RTTs, and there
*is* certainly a case for including cross traffic there.  We could
test how long it takes for the entire ensemble of flows to reach 80%
of  full utilization.  However, there is also the risk that we might
end up measuring the time until a new flow (i.e. slow start) arrives
rather than the time until normal congestion avoidance fills the pipe.
 That would become very sensitive to our traffic model.  (Halving the
size of files and doubling the rate of arrivals would make a big
difference.)

Does anyone have any suggestion how to avoid that?

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan