[Tmrg] Mix of RTTs

Sally Floyd sallyfloyd at mac.com
Thu Feb 21 16:42:10 PST 2008


Lachlan -

On Feb 18, 2008, at 8:17 PM, Lachlan Andrew wrote:
> 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.)

Actually, the *real world* contains users whose behavior is a function
of congestion and download times experienced so far.  And in the real
world (with current TCP), users over connections with longer RTTs
have much slower download times that users over connections with
shorter RTTs.  And therefore will download less.

But since our simulations and experiments don't yet have user
behavior sensitive to past congestion and to past download times,
this doesn't happen in our simulations and experiments...


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

Yep, if the average load is less than 100%.  If the average load is
greater than 100%, then the unfilled demand increases and
increases, the longer we run the simulation, with a lot
of the unfilled demand from the longer-RTT flows.

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

For me, the reason to take measurements over the second half
of the experiment is to avoid the odd and atypical period in the
beginning of the simulation when all flows are slow-starting at
the same time.  But personally, I am perfectly happy to run
simulations for finite, specified time periods when the average
load is greater than 100%, and there is no equilibrium.
(In fact, I think it is probably quite necessary, if one wants scenarios
with higher levels of congestion over the lifetime of the simulation.)

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

Ah dear, I had forgotten about that email.  Yep, I am happy with the
current text.


Take care,
- Sally
http://www.icir.org/floyd/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20080221/3491d8c2/attachment.html 


More information about the Tmrg-interest mailing list