Experimenting with No SACK
Hello, I tried to disable SACK, just to see how the download of the same ISO file (see my previous thread on SACK and Fast Rentransmission) behaves; performances were ugly: it took 6 times the time it took with SACK enabled!
One thing that I noticed is the following. The last acknowledgement from the receiver, before a 'TCP Segment not captured', was 20321203; then the receiver desperately kept asking for it until eventually the server did a TCP retransmission of 20321203-20322643 (1440 bytes).
The strange thing (at least to me) is that the receiver acknowledged 20365843, that is 30 packet more than expected; that value corresponds to the sequence number just before a second 'TCP Segment not captured' arrived at the receiver, I don't know if that's a coincidence. I thought that, with SACK disabled, the receiver didn't keep not-acknowledge packets in its buffer and the sender was forced to resend those packets again.
Can anyone please explain this behaviour?
Roberto
I think I misunderstood a concept above; the receiver keeps out-of-order packets in its buffer with or without SACK option enabled, doesn't it? That's why it is acknowledging 20365843. So is SACK option a feature that is mostly useful to the sender, in that it sees in the receiver's option the sequence numbers that the receiver has in its buffer?