Back to Blog
Tcp dup ack wireshark5/15/2023 We see SACK #5040 report that 2776 bytes are missing, #5042 is a retransmission of 1388 bytes. The result is that your throughput more than halves at that point.Ī short time later, there is another loss event. However, the loss of those 4 small packets causes the sender to reduce the transmit window to just 850 KB (620 packets x 1400 bytes) per round trip. In your case, the sender's transmit window initially ramps up to 2MB (1482 packets x 1400 MSS) per RT. The first set of SACKs start at #3458 and the first set of retransmitted packets are #3569, #3570, #3571 & #3572. The retransmitted packets are the correct size in this capture (ie, not the very large ones due to being captured before the IP layer "packetised" them). ![]() You will then see the retransmissions of the data that the SACKs reported as being lost. ![]() There can be multiple left and right edges, indicating multiple "gaps" in the flow. If you delve into the packet detail of the Dup-ACKs, you'll see the "left edge" and "right edge" values that identify them as SACKs. In this case you have to find the Selective ACKs - which are shown as "Dup-Acks" in Wireshark. This is clearly visible, several times, in blue on the Wireshark chart (Statistics - TCP Stream Graphs - Window Scaling).Īn excellent presentation about Congestion Avoidance algorithms was made by Vladimir Gerasimov at SharkFest 2019 did a lot of valuable research and preparation. When there are multiple packet loss events, a chart of the "Bytes-in-Flight" value forms a sawtooth pattern with fast decreases and slow increases. The subsequent "gentle" ramp up (usually by one packet per RT) means that overall throughput suffers severely. ![]() When a sender detects packet loss it is supposed to "halve" its transmit window and then ramp up very slowly.Ī halving of bytes-per-round-trip or packets-per-RT results in a halving of throughput. It is some relatively small packet losses at various times which trigger the TCP "Congestion Avoidance" mechanism/algorithm. However, the reason for the slow transfer is actually quite basic and common. That is, missing from the trace file but were there in real life. Your original "AIX-to-Cloud" capture file is made more difficult to analyse due to the fact that there are a lot of packets that weren't captured.
0 Comments
Read More
Leave a Reply. |