[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