These synchronization effects largely owe to TCP's inefficient timers. A relevant study which may be of some interest is: "Why TCP timers (still) don't work well", <span class="Apple-style-span" style="font-family: helvetica, arial, sans-serif; font-size: 12px; "> Computer Networks (COMNET), Elsevier Science, Volume 51, Issue 8, pages 2033 - 2048, June 2007. Paper can be found under: </span><a href="http://personal.ee.surrey.ac.uk/Personal/I.Psaras/">http://www.ee.surrey.ac.uk/Personal/I.Psaras/</a><br>
<br><div>(We still didn't manage to do any real world experiments though.)</div><div><br></div><div>Cheers,</div><div>Ioannis.</div><div><br><div class="gmail_quote">On Sat, Oct 24, 2009 at 6:28 PM, Stefan Hirschmann <span dir="ltr"><<a href="mailto:krasnoj@gmx.at">krasnoj@gmx.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><a href="mailto:aydin@mail.eecis.udel.edu">aydin@mail.eecis.udel.edu</a> wrote:<br>
</div>> Hello,<br>
<div class="im">><br>
><br>
>>> hypothesis: When N long-lived TCP flows (with the same RTT and MSS<br>
>>> values)<br>
>>> share a bottleneck link in a dumbbell topology (all the edge links have<br>
>>> the same delay and bandwidth), I expect each TCP flow to have the same<br>
>>> sending rate -- Assume no other cross traffic in the network and<br>
>>> drop-tail<br>
>>> queues.<br>
</div><div class="im">>> There are so called phase effects. Because of them, this assumption is<br>
>> wrong.<br>
><br>
</div>> Do you mean that my hypothesis will not hold due to the phase effects?<br>
> Could you explain what you mean by the phase effects?<br>
<br>
OK:<br>
<br>
To explain what phase effects are, I want to show a scenario where the<br>
TCP behavior is not good.<br>
* Initial setup:<br>
1. Dumbbell topology (two senders A and B, two receivers, one bottleneck).<br>
2. Queue has space for exactly one element.<br>
* Packet of sender A arrives at the bottleneck router.<br>
* The packet is stored in the queue which is now full.<br>
* Packet of sender B reaches the bottleneck router.<br>
* B's packet gets dropped because of the full queue.<br>
* \label{list-send} A packet is removed from the queue and gets sent.<br>
* Now there is space for one packet in the queue.<br>
* Packet of sender A arrives the bottleneck router.<br>
* The packet is stored in the queue which is now full.<br>
* Packet of sender B reaches the bottleneck router.<br>
* B's packet gets dropped because of the full queue.<br>
* Continue with step \ref{list-send}.<br>
<br>
Soon there are only packets from sender A in the queue so that the whole<br>
bandwidth is used only by sender A, and B gets a timeout. This is a<br>
typical behavior of simulators because in simulation there is no<br>
randomness like CPU calculation time, link layer behavior (e.g.<br>
CSMA/CD). Another problem is that ns-2 has an order of the flows and so<br>
the flow A is always calculated before flow B.<br>
<br>
In simulators without any randomness, this effect is a big problem. But<br>
this behavior is not only just a simulation artifact. It happens also in<br>
real world. A simple proof is the already mentioned download of two<br>
large files from the same site using an ADSL connection.<br>
<br>
<br>
><br>
>> [snip]<br>
><br>
> Are you running those two downloads at the same time?<br>
<br>
Yes. The downloads needed about 30 minutes and were started with a small<br>
time gap (the time you need to click in two different browser windows on<br>
the button save).<br>
<br>
<br>
BTW: Active queuing mechanism like RED was only introduced because of<br>
this problem. So maybe "random early detection" and "phase effects" are<br>
a good search pattern for you.<br>
<font color="#888888"><br>
Stefan<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Tmrg-interest mailing list<br>
<a href="mailto:Tmrg-interest@ICSI.Berkeley.EDU">Tmrg-interest@ICSI.Berkeley.EDU</a><br>
<a href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest" target="_blank">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest</a><br>
</div></div></blockquote></div><br></div>