Does Flow Monitor takes TCP retransmission into account?

[Jyotirmoy Banik]

(I have searched the mailing list and found some questions closely related, but not exactly the answer to this question. Hence I am creating a new question)

I have been looking at the Flow Monitor source code and trying to figure our whether it considers the TCP retransmissions while logging delays. I believe the monitoring probe is placed at the IP layer (L3), which makes me wondering if transport layer artifacts like TCP retransmission is indeed captured? However, I also noticed that the flow identifier contains standard five tuples, which includes protocol and ports, which in turn means that it can potentially track the retransmission. 

To quickly get an answer, I ran some simulations with different error rate at the PHY layer and I do see the average delays and throughputs are dropping quite a bit for high BLER. 

I would appreciate if someone could confirm my hypothesis (that FlowMonitor takes TCP retransmissions into account) and point me to the part of the code inside Flow Monitor library where it has been taken care of. 

Thank you everyone and have a great weekend! 

[Tommaso Pecorella]

Hi, the short answer is that it does and it doesn't.

Packet dropped below IP layer (like the ones dropped due to high BLER) are discarded by the NetDevice, so FlowMonitor doesn't even "see" them. Hence, FlowMonitor do react to dropped (and retransmitted) packets.

However, the only thing that FlowMonitor uses from TCP and UDP are the ports, and just to split the data between different flows. So, if a packet would be dropped by TCP due to TCP's level CRC... well, that's not taken into account. The good news is that, due to how the code works, if a packet has errors it's not even passed up to TCP, so this never happens.

Hope this helps in clarifying.

[Jyotirmoy Banik]

Hi Tommaso,

Thank you for your detailed explanation, which largely aligns with my understanding. However, I do have a follow up question.

First of all, I agree with you that packets corrupted in the PHY (due to high BLER) are discarded by the NetDevice and TCP does not see those packets. But in those scenarios, when a TCP segment is eventually received, does the FlowMonitor consider that the segment is a retransmitted one and calculate the delay as (time the segment is received - time when the segment was first transmitted i.e. attempt#1)? 

May be I should explain where I am coming from and perhaps you can point me towards the right direction: I would like to measure the user perceived delay and throughput which depend on the artifacts like retransmission. I am looking for a robust way to demonstrate that if I increase the BLER, that affects the Throughput and Delay. I was wondering whether FlowMon is the right tool to demonstrate that. One alternative which I am heavily considering is, writing my own stat collection code at the application layer, but I would hate to reinvent the wheel and honestly I would be surprised if such a stat collection method is not already available in the ns-3. 

Thank you in advance for your kind response. I truly appreciate it. 

[Tommaso Pecorella]

Good question, and the answer is... I'm not sure. I'm tempted to say that the delay will be the one of the retransmitted packet alone, because the 1st transmission and the "other" one will be different IP packets. However, it depends on how TCP do the caching of the packets to retransmit. Let's say that I'm fairly confident that the delay will not consider the retransmission tho.

About reinventing the wheel, you don't really have to. In the Applications module there are two headers: SeqTsHeader and SeqTsSizeHeader that can be added to the packet you pass to TCP, and they look perfect for your goal ("Ts" stands for TimeStamp).

About collecting all the stats, look at the Stats module, you'll find all the building blocks to collect all the stats (and perhaps even more).