Hi,
>>
>>
>>
>>
> 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
I guess it is a matter of coincidence rather than a low retransmit timer. The retransmit timer just "went off" before the delayed ACK timer on the client.
> - 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).
Yes that could be the scenario i guess...
>
> But with the additional SACK options, no harm is done and it does still compy to the RFC IMHO
I think you are right.
Cheers,
Andrej
>