Ethernet – Wireshark trace – POST data with SLE and SRE missing sequence numbers

ethernettcpwirelesswireshark

enter image description here

-Segment 237, the client (10.xxx) sends a POST request to server (128xxx) with a payload of (TCP Len) 4096.

-Segment 238, the client continue with the transmission with a payload of 1460 (seq 4097-5557)

-239, the server 128.x.x.x acknowledges the receipt of segment 238 with an Ack=1461 (right??)

At this point it seems the Ack for 237 is missing, because the server hasn’t received it (the first 1-4096 bytes of data) yet.

-However, at 243, the server tells the client, the server is actually missing data with sequence number from 1-1460 (these missing data is from segment 237, and not 238??), and sequence number 1461-4097 (partially from 237) has been received.

-244, the server updates the SACK, saying it is missing data with sequence number from 1-1460, and sequence number 1461-5557 has been received (assuming the seq num between 4097-5557 is from segment 238 which the server acknowledged previous in 239).

Am I interrupting this correctly? Please correct me if I am wrong, because I do not see any retransmission of the missing seq num 1-1460 later on in the trace: https://www.cloudshark.org/captures/1a890ba09b92

Any help will be greatly appreciated. Thanks.

Best Answer

I think you are misinterpreting the initial ACK. That first segment is 4150 bytes long, which is way more than you can fit into most standard segments, and is typically an indication that the host is doing TCP Large Segment Offload, which allows the application layer (including PCap) to think you are sending large segments, but the NIC is actually splitting them into smaller segments compatible with the MSS/MTU limitations.

So here instead of sending one segment with a data size of 4096 bytes, you are probably sending three: two of 1460 bytes, and one of 1176 bytes (or something like that). So frame 238 in this capture is actually the 4th segment actually sent.

The series of ACKs looks bizarre, as if you had out of order packet delivery in this network. It would have seemed more logical if you had first received segment 243 & 244 (you got the segment for bytes 1461 to 5557, so you SACK that) and then the first packet arrived and got ACKed (packet 239), and then at packet 245 everything gets caught up.

I honestly don't see how you can end up with this particular sequence of segments, unless:

  1. There are multiple paths of different latency being taken by packets from the client to the server,

and

  1. There is something which is fiddling with the initial ACK, sending it even though the server hasn't actually received that first segment.

Could there be a WAN optimization device such as a Riverbed somewhere between client and server? They have mechanisms which try to ACK some segments as quickly as possibly in order to accelerate the session's throughput ramp-up.

I may be completely wrong here; that's a really unusual sequence!

Related Topic