Detailed Question
Let us say
- Segment 31 errors, while segments 32-63 are delivered as normal
- Segment 31 resent
- The throughput/arrival time of segments 31-63 are all logged at resend time
If TCP segments are received out of order, the application throughput can be spiky. We also see that some throughput data towards the end of the simulation is missing.
Answer
This is the expected behavior since Application throughput is measured at the Application layer of the receiver.
TCP protocol works such that it would send a packet “up” to the application layer if it is received in order (based on the sequence number). However, TCP buffers any out-of-order packets it receives until ordered delivery can occur. Thus, if out-of-order packets are received then a “hole” is formed in the TCP receive buffer. In this case, there would be a “hole” in the TCP receive buffer for packet-31; once packet-31 is received then all the in-order packets are sent “up” by TCP to the application layer.
If you wish to study TCP (transport layer) throughput, then you can enable Wireshark and analyze the packet capture (.pcap) file. This is explained in NetSim user manual section 8.6: Packet Capture & analysis using Wireshark
Further users must note that there will be some missing throughput data at the end of the simulation. Instantaneous application throughput is computed from successfully received data at the application layer. At the end (instant) of the simulation, there could be
- data “in-flight” that haven’t yet been delivered to the destination(s). This data could be in the links or in the intermediate device buffers
- out-of-order data in the TCP buffer.
This can occur because simulation finishes at the (user) specified simulation end-time. Since the simulation terminates, all these bytes are not accounted for in the application throughput calculation.
Attached is additional background information on throughput measurement in NetSim.