[Tmrg] sending rate of a TCP flow
ipsaras at gmail.com (Yiannis Psaras) Sun, 25 October 2009 11:20 UTC
From: "ipsaras at gmail.com"
Date: Sun, 25 Oct 2009 12:20:21 +0100
Subject: [Tmrg] sending rate of a TCP flow
In-Reply-To: <4AE33953.8070702@gmx.at>
References: <3274.71.164.126.227.1256397308.squirrel@webmail.eecis.udel.edu> <4AE3285D.40703@gmx.at> <3516.71.164.126.227.1256403744.squirrel@webmail.eecis.udel.edu> <4AE33953.8070702@gmx.at>
Message-ID: <74b2c9800910250420o65c53d6aw78e01aa94bd72845@mail.gmail.com>
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", Computer Networks (COMNET), Elsevier Science, Volume 51, Issue 8, pages 2033 - 2048, June 2007. Paper can be found under: http://www.ee.surrey.ac.uk/Personal/I.Psaras/<http://personal.ee.surrey.ac.uk/Personal/I.Psaras/> (We still didn't manage to do any real world experiments though.) Cheers, Ioannis. On Sat, Oct 24, 2009 at 6:28 PM, Stefan Hirschmann <krasnoj at gmx.at> wrote: > aydin at mail.eecis.udel.edu wrote: > > Hello, > > > > > >>> hypothesis: When N long-lived TCP flows (with the same RTT and MSS > >>> values) > >>> share a bottleneck link in a dumbbell topology (all the edge links > have > >>> the same delay and bandwidth), I expect each TCP flow to have the same > >>> sending rate -- Assume no other cross traffic in the network and > >>> drop-tail > >>> queues. > >> There are so called phase effects. Because of them, this assumption is > >> wrong. > > > > Do you mean that my hypothesis will not hold due to the phase effects? > > Could you explain what you mean by the phase effects? > > OK: > > To explain what phase effects are, I want to show a scenario where the > TCP behavior is not good. > * Initial setup: > 1. Dumbbell topology (two senders A and B, two receivers, one > bottleneck). > 2. Queue has space for exactly one element. > * Packet of sender A arrives at the bottleneck router. > * The packet is stored in the queue which is now full. > * Packet of sender B reaches the bottleneck router. > * B's packet gets dropped because of the full queue. > * \label{list-send} A packet is removed from the queue and gets sent. > * Now there is space for one packet in the queue. > * Packet of sender A arrives the bottleneck router. > * The packet is stored in the queue which is now full. > * Packet of sender B reaches the bottleneck router. > * B's packet gets dropped because of the full queue. > * Continue with step \ref{list-send}. > > Soon there are only packets from sender A in the queue so that the whole > bandwidth is used only by sender A, and B gets a timeout. This is a > typical behavior of simulators because in simulation there is no > randomness like CPU calculation time, link layer behavior (e.g. > CSMA/CD). Another problem is that ns-2 has an order of the flows and so > the flow A is always calculated before flow B. > > In simulators without any randomness, this effect is a big problem. But > this behavior is not only just a simulation artifact. It happens also in > real world. A simple proof is the already mentioned download of two > large files from the same site using an ADSL connection. > > > > > >> [snip] > > > > Are you running those two downloads at the same time? > > Yes. The downloads needed about 30 minutes and were started with a small > time gap (the time you need to click in two different browser windows on > the button save). > > > BTW: Active queuing mechanism like RED was only introduced because of > this problem. So maybe "random early detection" and "phase effects" are > a good search pattern for you. > > Stefan > _______________________________________________ > Tmrg-interest mailing list > Tmrg-interest at ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20091025/16939527/attachment.html
- [Tmrg] sending rate of a TCP flow aydin at mail.eecis.udel.edu
- [Tmrg] sending rate of a TCP flow Stefan Hirschmann
- [Tmrg] sending rate of a TCP flow Stefan Hirschmann
- [Tmrg] sending rate of a TCP flow Yiannis Psaras
- [Tmrg] sending rate of a TCP flow Mark Allman
- [Tmrg] sending rate of a TCP flow Pentikousis Kostas
- [Tmrg] sending rate of a TCP flow Pentikousis Kostas
- [Tmrg] sending rate of a TCP flow aydin at mail.eecis.udel.edu