 | 1 | initial version |
It looks like an issue with TCP Segmentation Offload / Large Send Offload. Those TCP segments are much larger than what actually goes on the wire - presumably you captured on the sending machine.
If you look at the ACKs, you can see that they ACK 425428307 and they also have selective ACKs, with the SACK Left Edge (SLE) being 425444235. If you look at the sending packets, those are the sequence numbers of frames 72201 and 72203, and the length of the segment in 72201 is 15928. As 425428307 + 15928 = 425444235, naively, that looks like no missing bytes! Both segments are ACKnowledged, just one in the normal ACK and one in the SACK.
In practice, what must have happened is that the 15928 octet segment starting at 425428307 was actually split into much smaller segments smaller than the MSS, the first one was received but the second one was lost. The TSO/LSO sender apparently can't understand that the receiver is missing all the smaller segments other than the first, so it doesn't try to resend.
| | 2 | No.2 Revision |
It looks like an issue with TCP Segmentation Offload / Large Send Offload. Those TCP segments are much larger than what actually goes on the wire - presumably you captured on the sending machine.
If you look at the ACKs, you can see that they ACK 425428307 and they also have selective ACKs, with the SACK Left Edge (SLE) being 425444235. If you look at the sending packets, those are the sequence numbers of frames 72201 and 72203, and the length of the segment in 72201 is 15928. As 425428307 + 15928 = 425444235, naively, that looks like no missing bytes! Both segments are ACKnowledged, just one in the normal ACK and one in the SACK.
In practice, what must have happened is that the 15928 octet segment starting at 425428307 was actually split into much smaller segments smaller than the MSS, the first one was received but the second one was lost. The TSO/LSO sender apparently can't understand that the receiver is missing all the smaller segments other than the first, so it doesn't try to resend.
If you look at some of the earlier ACKs, you will see that they ACK sequence numbers that don't appear to be the start of segments sent - they are sequence numbers that appear in the real segments after divided up.
If this keeps happening to you, you should disable TSO or LSO (depending on whether the sending host is Linux or Windows) as a workaround.
