Hello guys, i'm pretty new to capture analysis and i'm asking you some help with this capture. I'm testing a 4g modem that should reach ~40mbps, actually it makes 1. So i tried a few test i noted that: -tcp connection have 1mbps -upd connection makes a lot more so i've started to think to a tcp problem... but i can not understand wich one is the root cause :( I'm attacching 2 capture file tcp/upd thx in advance, andre asked 10 Apr '17, 06:49  ancestrale012 retagged 10 Apr '17, 18:05  Philst |
One Answer:
Your reduced throughput rate is due to TCP's "Congestion Avoidance" mechanism. The sender will halve its Transmit Window in response to observed packet losses. In your TCP capture (I couldn't find your UDP file), the sender's "Slow Start" ramps up to 74 packets "in flight" after about 700 ms. But then there is a packet loss (packet #109 goes missing after we've seen it in the trace), SACK (#212) and retransmission (#214). Packets #157, #241 and #245 repeat that pattern. On seeing that losses happened, the sender halves its Transmit Window to 34 segments per round trip and ramps up this rate linearly (35 next RT, 36 next RT, etc.) This has the effect of halving the overall throughput and increasing it very slowly. Just as we've ramped up to 44 S/RT, packet #696 gets lost and the throughput again halves to 22 S/RT. We get three more "halvings" - dropping to 10 S/RT due to the loss of #1130. We get to 42 S/RT when #2295 is lost (retrans = #2357) halving again to 21 S/RT. We only ramp up to 31 at the end of the transfer (terminated with a Reset). The server's Receive Window is 627,584 bytes for the almost the whole transfer. Your problem is that the sender can't fill that receive window because of the frequent Transmit Window reductions. That is, due to the lost packets in the flow (which all occur after the capture point). This TCP Stream chart shows the transition from "Slow Start" to "Congestion Avoidance" mode. The yellow packets are the retransmissions of the "lost" packets. Note the slope of the packets changing to the reduced rate. If you view the flows later in the trace, you'll be able to see the other "halvings".
See my answer to Question #55972 for similar behaviour. answered 10 Apr '17, 17:58 Philst edited 10 Apr '17, 18:03 |
Hello Philst, thx a lot man! you're awsome! it have been a great exaplanation!
May i just add 1 more question? i would like to understand wich one is the cause of the packet loss, it is possbile?
thx again! Andrea
@ancestrale012
Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.
If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.
Thanks Andrea, there doesn't seem to be any particular pattern to the losses. They occur at the start, middle and end of packet bursts (if they were always at the end of a burst, we might look for router buffer overflows).
All we can say is that they all happen after the capture point. That is, we see all the packets in the trace, but they must go missing sometime "downstream" because the receiver sends us SACKs indicating that they weren't received.
We can also say that they only get lost one at a time (not in groups).
Out of the total 2,754 packets in that connection (includes ACKs) there are 8 missing data packets.
Unfortunately then, there's no further clue as to where they are going missing.
The only real way to find the loss point is to take captures at various places along the path and see which traces they are missing from.
You could also check switch counters to see if they happen to be counted as "dropped" somewhere.