[Tmrg] Mix of RTTs

Lachlan Andrew lachlan.andrew at gmail.com
Mon Feb 18 20:17:38 PST 2008 

Greetings Sally,

On 18/02/2008, Sally Floyd <sallyfloyd at mac.com> wrote:
> > 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.

Yes.  My wording was confusing.  When I said "data sent *at* each
RTT", I meant "data eventually sent by flows having a particular RTT",
not "data in a particular interval of duration one RTT".

Each individual long-RTT flow will transmit slower, but as a result,
there will be more of them in the system.  The total data (eventually)
 sent  by these flows equals the sum of the file sizes which arrive,
regardless of how slowly they are sent.  (Of course, this only applies
exactly if the time scale of the simulation is long compared to one
flow transfer time, but that is the way the real world is.)

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

Agreed.  The rate that an individual long-RTT flow sends will be
lower, but this is balanced by the fact that it keeps sending for
longer.

> > 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
...
> I would assume that at the end of the 100 seconds, the long-RTT
> flows had more unfilled demand that the short-RTT flows.

Yes, the long flows will have more unfilled demand.  However, if the
simulation has been run long enough, the unfilled demand of the
remaining flows will be a small fraction of the total data.

This gets back to our discussion about whether it is meaningful to
study time-average properties of systems which haven't yet reached
equilibrium.  The reason for taking measurements only over the second
half is to avoid non-equilibrium effects, isn't it?  If so, it would
be consistent to wait until the system actually   has   reached
equilibrium.  Otherwise, time averages are misleading quantities.  Do
you agree?

At a random point in the real world, the each long RTT flow will be
about half-finished, just like each short RTT flow will be.  If the
long RTT flows have more unsent data in the real world, it is because
there are more of them.

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

Your email below suggests that it was a little more complicated than
uniform [20,460].  I interpreted it as saying that most of the traffic
was [0,220], but I could have misunderstood.  If you're happy with the
current text, we'll just go with it.

Cheers,
Lachlan


On 11/12/2007, Sally Floyd <sallyfloyd at mac.com> wrote:
> > You're right that the delays don't match those in the paper very well.
> >  Our reference was the link you sent in November.  As I commented on 3
> > December, there seems to be a discrepancy between the paper and the
> > scripts on the web which purport to have produced those graphs.  Since
> > the paper didn't have values and we didn't hear your response to my
> > query, we used the values in the scripts we were pointed to.
> >
> > Are you sure that the scripts on the web are the ones used?
>
> Yep.  But it turns out that the topology in the scripts is more
> complicated that I remembered.
>
> In the scripts, there are two sets of access links.
>
> The access links for the long-lived traffic are as follows:
>      $ns duplex-link $node_(s$i) $node_(r1) 100Mb [expr $delay2]ms
> DropTail
>      $ns duplex-link $node_(k$i) $node_(r2) 100Mb [expr $delay2a]ms
> DropTail
> for
>          set delay2 [expr 2*$opt(secondDelay)*((($i+3)%10)/9.0)]
>          set delay2a [expr 2*$opt(secondDelay)*((($i+3)%10)/9.0)]
> and secondDelay set to 55 ms.
>
> This gives one-way propagation delays for each of the access links
> for the long-lived traffic of [0,110] ms, giving RTTs for the
> long-lived traffic,
>   in the absence of queueing delay and the small delay for the central
> link,
> equally distributed in [0, 440] ms.
>
> The  access delays for the web traffic are as follows:
>    $ns duplex-link $s_($i) $node_(r1) 2000Mb $x DropTail
>    $ns duplex-link $r_($i) $node_(r2) 2000Mb $y DropTail
> for
>                  set x [expr $bdel*((($i+3)%10)/9.0)]ms
>                  set y [expr $bdel*((($i+3)%10)/9.0)]ms
> and bdel set to 55 ms.
>
> This gives one-way propagation delays for each of the access links
> for the web traffic of [0,55] ms, giving RTTs, in the absence of
> queueing
> delay etc., equally distributed in [0, 220] ms.
>
> I don't think that this difference between the RTTs for the long-lived
> traffic and the web traffic was on purpose.
>
> Figure 5 was run with a range of web traffic and long-lived traffic,
> but dominated by web traffic:
>    ./ns sims.tcl -flows 18 -web 400 -rtts 1 -title two > two.data
>
> I just reran the simulations, one with RTTs for the web traffic
> equally distributed in [0, 220] ms., as used for Figure 5 in the paper,
> and the other with RTTs for the web traffic equally distributed
> in [0, 440] ms.  This first one matched the experimental data
> better, so I will change the one-way propagation delays for the
> access links in the paper to give RTTs of  [0, 220] ms.
>
> (I am assuming that everything in this first draft is subject to
> change as we learn more from measurements and from running
> the simulations and experiments....)
>
> > On 03/12/2007, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
> >> Greetings Sally,
> >>
> >> On 26/11/2007, Sally Floyd <sallyfloyd at mac.com> wrote:
> >>> Cesar wrote
> >>>> 1) the RTTs of the access links for the dumbbell scenarios
> >>>>      In this topic, I read the paper by Sally and Kohler about
> >>>> "Internet Research Needs Better Models".
> >>>> "http://www.icir.org/models/hotnetsFinal.pdf"
> >>>
> >>> For the scenario in that paper, the flows are distributed evenly
> >>> over all of the nine links pairs (that is, those pairs that have
> >>> one link on the left, and one link on the right).  The simulation
> >>> scripts are available from "http://www.icir.org/models/sims.html".
> >>
> >> I've tried reading the scripts at
> >> <http://www.icir.org/models/hotnets-sims/sims.tcl>, and really can't
> >> see what RTTs the links used.  (I'm not very fluent at TCL.)
> >>
> >> It seems to me that the number of web nodes created in
> >> add_web_traffic   is    numWeb=10,  and the RTTs seem to be drawn from
> >> a discretized uniform distribution  [generated by
> >> $bdel*((($i+3)%10)/9.0]  with a maximum value of
> >> opt(secondDelay)=55ms.  That doesn't mesh with the maximum RTT of
> >> 460ms in the paper.
> >>
> >> As I recall, at the meeting you offered to find the RTTs which would
> >> match a measured distribution.  As a short-cut for the PFLDnet
> >> abstract, could you please let us know what link delays were used in
> >> the "better models" paper?
> >>
> >> Thanks,
> >> Lachlan
>
> - Sally
> http://www.icir.org/floyd/
>
>



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

More information about the Tmrg-interest mailing list