TCP flow bandwidth distribution over multi-hop WiFi Network

[dgomez]

Hi all,

I'm currently implementing an X-scenario (attached figure) with crossed long-lived TCP flows (S1-D1 / S2-D2) over a WiFi AdHoc IEEE 802.11 Network (I think it is senseless to attach the source code because I've followed the examples to tailor an automatic scenario creator from a configuration file, hence it'd be too long to show here). The links among the nodes are defined as you can see in the figure, but with a exception that worths highlighting: the lines represent which nodes are able to correctly receive the packet from others (the signal received are greater than the YansWifiPhy's "EnergyDetectionThreshold"); on the other hand, all the nodes can detect a transmission from any one, that is to say, although they cannot receive the content of the packet, the received signal strength is higher than the "CcaMode1Threshold", so the nodes will detect the state as "busy".

After this introduction, I'll go to the point: 

• If I configure the scenario under a saturated situation (the sum of the application - OnOffApplication- data rates is higher than the overall channel's capacity), the distribution between the two flows is actually "unfair", since the first one to access to the channel get almost all the bandwidth, while the second one could one make residual transmissions; obviously, whenever the transmission of the first flow ends, the second one has all the resources for itself (I have attached the TCP ACK number as a function of the elapsed time - see the figure ).
• On the other hand, with a non-saturated channel, the distribution between the flows follows a more logical pattern. Anyway, although both applications start simultaneously (t = 45''), there is a non-negligible delay with one of the connection (~2''). Please see the figure. 
• Finally, with UDP traffic and saturation conditions, the allocation of the flows is approximately "fair" (obviously, I have no figure to show).

For your knowledge, I'm using ns-3.13 with the RttEstimator patch applied (Bug 1351). The configuration of the nodes and the stack is the same as the vast majority of WiFi examples. I must fix it because I need that the flows merges in order to apply network coding techniques, thus I'll be stuck until I have figured out a solution. I supposed that anybody has lived a similar experience, so I hope you can help me.

My PhD director has an initial theory: he thinks it could be the 802.11 MAC DCF scheme, where a flow gets a total control of the channel, sending the frames in bursts (without contending for the channel).

Thank you very much in advance,

David

[dgomez]

Sorry, those are not the correct figures:

1. This one corresponds to the non-saturated channel (every source node has an OnOffApplication @1 Mbps). Anew, we can see that the TCP connection is delayed a whole second (they were both configured to start at t = 45 seconds).
2. Regarding the saturated channel, we have 11Mbps at each source node (S1 and S2) with the following results.

Sorry again for the inconvenience,

David 

P.D. Here's my personal info (although I introduced myself several month ago, I should have become a more active user):

-------------------
David Gómez Fernández
PhD Student

Communications Engineering Department
Grupo de Ingeniería Telemática (GIT)
Universidad de Cantabria, Avda. de Los Castros S/N
39005, Santander, Cantabria (España)

email: xx...@xxx.xxxx.xxxx   --> I think a public group is not the most appropriate way to share my mail address
web: http://www.tlmat.unican.es

Phone Number: +34 942 20 09 19 ext. 504
-------------------

[Nicola Baldo]

Hi David,

I don't have a straight answer to your problem, but just some comments that I hope will help you shed some light on this, see below.

On Monday, November 26, 2012 1:11:55 PM UTC+1, dgomez wrote:

The links among the nodes are defined as you can see in the figure,

but with a exception that worths highlighting: the lines represent which nodes are able to correctly receive the packet from others (the signal received are greater than the YansWifiPhy's "EnergyDetectionThreshold");

well, the ED threshold alone does not guarantee correct reception, just correct synchronization to a signal being RX. I suggest to check the SINR of each link and compare with the WifiMode being used.

• If I configure the scenario under a saturated situation (the sum of the application - OnOffApplication- data rates is higher than the overall channel's capacity), the distribution between the two flows is actually "unfair", since the first one to access to the channel get almost all the bandwidth, while the second one could one make residual transmissions; obviously, whenever the transmission of the first flow ends, the second one has all the resources for itself (I have attached the TCP ACK number as a function of the elapsed time - see the figure ).

I actually see that the second flow starts in the middle of the transmission of the first flow. I am not surprised that the TCP slow start phase of the second flow is very slow, as the link is congested by the first flow. The point is: why does the second flow start so late? It could be some issue such as a lost ARP request or TCP SYN that needs retransmission (which is done after a few seconds).
 

• On the other hand, with a non-saturated channel, the distribution between the flows follows a more logical pattern. Anyway, although both applications start simultaneously (t = 45''), there is a non-negligible delay with one of the connection (~2''). Please see the figure. 

try not to start applications at the exact same time. This is a simulation artifact that is known to cause problems (e.g., lost ARP requests).  

My PhD director has an initial theory: he thinks it could be the 802.11 MAC DCF scheme, where a flow gets a total control of the channel, sending the frames in bursts (without contending for the channel).

I don't think this is the case.


Regards,

Nicola

[dgomez]

Hi Nicola,

First of all, I'd like to thank you for your reply. I think we can discard many questions we have posed before your answer:

 have a straight answer to your problem, but just some comments that I hope will help you shed some light on this, see below.

On Monday, November 26, 2012 1:11:55 PM UTC+1, dgomez wrote:

The links among the nodes are defined as you can see in the figure,

but with a exception that worths highlighting: the lines represent which nodes are able to correctly receive the packet from others (the signal received are greater than the YansWifiPhy's "EnergyDetectionThreshold");

well, the ED threshold alone does not guarantee correct reception, just correct synchronization to a signal being RX. I suggest to check the SINR of each link and compare with the WifiMode being used.

In this case, I'm sure the frames are correctly received and pass through the upper layer, because I wanted to assure this to occur, then I chose the RangePropagationLossModel in order to leverage this behavior.

 

• If I configure the scenario under a saturated situation (the sum of the application - OnOffApplication- data rates is higher than the overall channel's capacity), the distribution between the two flows is actually "unfair", since the first one to access to the channel get almost all the bandwidth, while the second one could one make residual transmissions; obviously, whenever the transmission of the first flow ends, the second one has all the resources for itself (I have attached the TCP ACK number as a function of the elapsed time - see the figure ).

I actually see that the second flow starts in the middle of the transmission of the first flow. I am not surprised that the TCP slow start phase of the second flow is very slow, as the link is congested by the first flow. The point is: why does the second flow start so late? It could be some issue such as a lost ARP request or TCP SYN that needs retransmission (which is done after a few seconds).
 

• On the other hand, with a non-saturated channel, the distribution between the flows follows a more logical pattern. Anyway, although both applications start simultaneously (t = 45''), there is a non-negligible delay with one of the connection (~2''). Please see the figure. 

try not to start applications at the exact same time. This is a simulation artifact that is known to cause problems (e.g., lost ARP requests).  

This is the point, thank you very much; we almost drove ourselves mad with this question, looking up through the source code, thus without finding a suitable answer. Regarding your answer, if the two flows start at the same time (i.e. t = 0 sec) the second SYN is received at i.e. t = 1 sec, that is to say, exactly one second later. However, we were searched the bug in both TCP's (because an UDP transmission didn't show this performance) and Wifi's stuff, finding no answer. Anyway, in the ArpCache API documentation, I've found the attribute named "WaitReplyTimeout", which is set by default at "1 sec", value that perfectly fits with the delay exhibited by the 2-TCP-flows scenario.

On the other hand, making the connections started with a certain delay, the performance becomes "normal" (please, see this figure, with 4 TCP-flows with 0.1 seconds between each SYN connection primitive delivery, at transmitter TCP layer).

 

My PhD director has an initial theory: he thinks it could be the 802.11 MAC DCF scheme, where a flow gets a total control of the channel, sending the frames in bursts (without contending for the channel).

I don't think this is the case.

This question seems to be solved in the discussion above.

Many thanks again,

David