Wietse:
> Here is one event in a tcpdump file that I received a few hours
> ago (full context is below the signature):
>
> 10:49:57.930285 80.74.176.142.25 > 217.11.85.59.2528: . ack
> 1998901 win 32767 <nop,nop,sack sack 1 {1994821:1996181} > (DF)
>
> What happens is that the receiver (80.74.176.142) says:
>
> I have received all data up to offset 1998901
>
> But the receiver (80.74.176.142) also sends a selective ACK for
> offset range 1994821:1996181, that is, for data that it has already
> acknowledged.
I have a correction to my earlier analysis.
This behavior is defined in RFC 2883 (duplicate selective
acknowledgment, or D-SACK). Look for the example in section 4.1.1
with ACK=4000, SACK=3000:3500. I'm never too old to learn new stuff.
The receiver can use D-SACK to tell the sender that it has received
1994821:1996181 multiple times already while the ACK is at 1998901.
This is exactly what happens in the recording fragment that I
included a few posts ago.
Wietse:
> Of course the bigger problem is that the sender keeps retransmitting
> the data offset range 1994821:1996181 over several minutes.
>
> Either way, if you turn off SACK support (RFC 2018) on the receiver
> it should stop triggering this bug on the sender side.
There is negligible performance loss if you could turn off RFC 2883
(D-SACK support) in the receiver.
I don't know if this is a problem with Windows TCP/IP, or if this
is a problem with a firewall on the client side. Reportedly, some
firewalls randomize TCP sequence numbers but don't update the
sequence numbers in SACK fields. That would be a sure way to mess
up TCP.
Turning off SACK support (RFC 2018) would hurt with data loss on
connections that use large TCP window sizes.
Wietse
