[Tmrg] Mix of RTTs

Sally Floyd sallyfloyd at mac.com
Mon Feb 18 19:35:55 PST 2008


Lachlan -

(Getting to old email...)

> I have a question about the connection between the traffic model and
> RTTs to use in TCP analysis.
>
> When the "better models" paper compares the simulated and measured RTT
> distributions, it mentions that most packets come from the short-RTT
> flows.  That will clearly be the case if all flows are long-lived, or
> if the traffic model is "closed loop" in the sense that it consists
> only of alternating "think times" and fixed-time files.
>
> If the traffic consists instead of Poisson arrivals of "sessions",
> each carrying a fixed amount of traffic (possibly in several
> think/send bursts), then the amount of data sent at each RTT is
> determined by the traffic model, independent of the actual RTTs.

I don't understand this.  Assume Poisson arrivals of sessions, each
carrying a fixed amount of traffic.   The amount of data sent in
each RTT is determined by the end-to-end congestion control.  For
TCP, where in congestion avoidance a flow increases its sending
rate by one packet per RTT, short-RTT flows send at a much higher
sending rate *in packets per second* than do long-RTT flows, given
the same packet drop rates for the two flows.

I agree that we want a traffic model of Poisson arrivals of sessions,
each carrying a fixed amount of traffic (from a heavy-tailed
distribution).

> At the round table, we agreed to have a traffic model of the second
> kind.  Will that change the RTTs that we should use in the test suite?

Figure 5 from the Internet Research Needs Better Models paper
has most of the traffic on the second kind above (from the traffic
generator in ns-2, with Poisson arrivals of sessions, and
heavy-tailed distributions of file sizes, along with other parameters),
though there are a few long-lived flows in Figure 5 of that paper.

The simulation was run for 100 seconds of simulation time, with
packet drop rates over the second half of the simulation of roughly
3%.  I would assume that at the end of the 100 seconds, the long-RTT
flows had more unfilled demand that the short-RTT flows.

>  As I recall, you wanted to revise that section before the final
> submission anyway.

The Internet Research Needs Better Models paper used RTTs that
were uniformly distributed between 20 and 460 ms, in the
absence of queueing delay.  Table 1 of the PFLDnet paper
now gives RTTs in the range of 4 to 200 ms, in the absence
of queueing delay.

It has varied over time - for revision 1.13, Table 1 had a
range of RTTs from 0 to 100 ms.  In revision 1.14, Table 1 was
changed to have a range of RTTs from 0 to 200 ms.
In revision 1.15, this was changed (perhaps by me) to have
a range of RTTs from 4 to 400 ms.  In revision 1.18, this was
changed back to a range of RTTs from 4 to 200 ms.

The range of RTTs up to 400 ms seems the most realistic to me,
for the default scenario, but I could live with a range up to 200 ms,
for the first pass at the scenarios.  Perhaps it was changed back
because 200 ms is easier for testbeds than 400 ms?  I don't
remember, and it is impossible to tell from the logs who made
which change.

- Sally
http://www.icir.org/floyd/



More information about the Tmrg-interest mailing list