[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