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
retagged 10 Apr '17, 18:05
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
edited 10 Apr '17, 18:03