[Tmrg] sending rate of a TCP flow
krasnoj at gmx.at (Stefan Hirschmann) Sat, 24 October 2009 17:28 UTC
From: "krasnoj at gmx.at"
Date: Sat, 24 Oct 2009 19:28:51 +0200
Subject: [Tmrg] sending rate of a TCP flow
In-Reply-To: <3516.71.164.126.227.1256403744.squirrel@webmail.eecis.udel.edu>
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>
Message-ID: <4AE33953.8070702@gmx.at>
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] 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