Re: Query related to TCP

[Tommaso Pecorella]

Hi,

TCP ACK size is 40 bytes plus your MAC header - 20 bytes is the IP header without options, 20 bytes is the TCP header with no data.

ARP should be 44 bytes (again, 20 + 24) plus MAC header.

About ARP in the first simulation seconds, it's the exact opposite. You'll see only ARP in the very few simulation seconds, also using UdpEcho. ARP is always used before any data packet is sent.

What are your packets then ? No idea, but you can print them. Just enable metadata (see Packet::EnablePrinting) and print them.

ACK at higher layers: no, they're not passed to higher layers in any way. They are if they are also containing data (actually it's the opposite, it's a data packet piggybacking an ACK). Otherwise ACKs are consumed and used by TCP. Perhaps what's confusing you is that the TCP L4 protocol is passing the packets to the sockets, but these are L4 too.

Last but not least, TCP performances. Natale did a tremendous effort to do a complete TCP refactoring, eliminating a lot of lingering bugs in the process. I'd suggest to use ns-3-dev if you have TCP performance issues. Better, I'd suggest to use ns-3-dev for any TCP-related measure.

Hope this helps,

T.

On Saturday, October 31, 2015 at 2:38:48 AM UTC+1, PN wrote:

I've been tweaking ns 3 for the purpose of my research. I'm working on Multiuser MIMO which enables an Access Point to transmit to multiple stations simultaneously instead of just one at a time as in case of single antenna systems. In order to simulate this, I've written my own module and added it to the source folder in ns 3 using the steps described here: https://www.nsnam.org/docs/manual/html/new-modules.html

There are essentially two aspects of this simulation: one for the downlink wherein the Access Point transmits to the Stations and the other is the uplink in which case the stations transmit to the Access Point. The downlink is multi-user MIMO based whereas the uplink is based on contention as in case of wifi. I've tested this module for open loop traffic simulations for both uplink and downlink (individually and together) and the results I have obtained are as expected which confirms that the module works properly. I have also verified my belief regarding the proper working of this module by looking at the ns log and printing out the output of the individual net device and channel classes in my module.

However, one of the problems I've faced are in case of TCP simulations. It seems that TCP window size never increases much. I believe that the TCP window size remains low as the Access Point receives around 2-3 packets in a single burst for transmission from higher layers (here burst refers to packets whose timestamps are pretty close) so I'm guessing that TCP's window size also remains around the same value. Now, for TCP there is a data packet that gets sent to the station (receiver) and to that the station responds with a TCP ACK.

I have the following questions:

1.  What is the size of TCP ACK in ns 3? I can see that my Access Point (net device) receives packet of size 46 bytes on the uplink. My initial guess was that these are Arp packets. So I ran the UdpEchoServer/ Client application for 10 seconds before starting my actual simulation to make sure that the Arp packets were not transmitted during the simulation (also the echo server/client application worked fine so there should be no arp atleast in the first few seconds of the simulation. I have not changed the Arp settings of ns 3 in any way). However, given the frequency with which these packets are being received on the uplink, I'm inclined to believe that they are TCP ACKs rather than the Arp packets. Also, the packet sink on the station (receiver) reports receiving the DATA packet and the packet received on the uplink looks like a response to the DATA packet so should be a TCP ACK.

2. How do I find out if the TCP ACK is being received by the higher layers? I can see that the ACK is being received and passed to higher layers by using the receive callback but I'm facing difficulty tracing where it gets dropped/rejected and why. I understand that enabling logging for all log components for all ns 3 modules would give me the answer, but it would make my analysis too painful. So I was wondering if there was an easier way.

Thank you.

[PN]

Thank you for your reply. It was very helpful. Those were TCP Ack's indeed. I was adding padding at the end of the packet and forgot to remove the padding so it became 46 instead of 40. I found this by printing out the metadata as you had mentioned. So now I can see the AP receiving 40 bytes TCP ACKs. I also tried to print out the congestion widow size and it looks like with every ACK received it is incrementing which is correct.

However, there is another problem (not sure if its a problem though). I was under the assumption that if the TCP's congestion window size is say 5 then it would send 5 packets as a single burst. So lets say if TCP window size changes from 4 to 5, then it should transmit 5 packets in a single burst (located very close in time). However, in my case, I can see that every time TCP's window size increases (upon receiving an ACK), it still sends 1-2 packets no matter what the window size is. Is this expected? Please let me know if my understanding is wrong.

Also, I will try using ns 3 dev. But is there a way of finding exactly what files related to tcp were changed and added to ns 3 dev so that I can only download and replace those files in the src folder of my ns 3 and try them instead of using the whole of ns 3 dev. I'm sure there would be other files in it that are not related to tcp but were modified by other developers.

Thank you once again.

[Tommaso Pecorella]

Let's start from the bottom.

It's not a good idea to try to mix and match versions. imply use the whole ns-3-dev. If you're working on a larger project and your team is modifying files here and there you're out of luck (and if you're not using a versioning system able to let you sync with the latest ns-3 release you're in trouble).

About TCP, yes, it's the intended behaviour. TCP will never have "in flight" more packets than the window size (and it shouldn't send it in bursts anyway).

Let's say that you receive an ACK for 1200 bytes. This moves the window by 1200 and increases it of something (let's say 2400 bytes). In this case TCP can send 3600 bytes, no matter how big the window is.

This, of course, it's a simplification, as the local window could grow larger than the receiver window. In this case you use the minimum of the two.

Hope this helps,

T.

[PN]

That was helpful. Thank you.