On 27 feb 2011, at 10:11, Andrej van der Zee wrote:
>
>> It's saying "I saw the bytes with sequence numbers from 533 through 1129" (i.e., in the half-open interval [533, 1130)), presumably because there are some bytes with sequence numbers preceding 553 that it hasn't yet acknowledged because it hasn't seen yet - it wants to have the other end re-transmit those bytes without having it also retransmit bytes 533-1129, which I suspect were the retransmitted bytes.
>
> Actually, the weird thing is that the "normal" ACK Number in this
> packet is 1130 and there are no "holes" in the acked data. The RFC
> sais:
>
> "The SACK option does not change the meaning of the Acknowledgement
> Number field"
>
> So the SACK option in this packet seems to have no affect whatsoever
> and I wonder why it is sent then. Bad TCP implementation (Windows 7)?
>
> Attached you find the pcap-file (packet 11 is the SACK-packet).
The RFC also says:
"If sent at all, SACK options SHOULD be included in all ACKs which do
not ACK the highest sequence number in the data receiver's queue."
Which in your case is not the case, but...
Sincce selective acking is used (both the SYN and SYN/ACK contain the "Permit SACK" option), I think the following happened:
- The client received the packet with seq 533, but waits to ACK it because of delayed ACK mechanism (which can also be seen in frame 19, where it acks frame 17 after ~200ms)
- The server has a very low retransmit timer and retransmits the segment with seq 533
- The client received the retransmission of the packet with seq 533. But as it sees it already has that data, it uses the sack mechanism instead of the ack mechanism (without first determining if this is the special SACK case where only the last segment was retransmitted).
Of course digging into the code of the TCP stack of windows 7 would give the ultimate answer... But with the additional SACK options, no harm is done and it does still compy to the RFC IMHO.
Just my $0.02
Cheers,
Sake
