> > 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.
Great.. I've read the RFC too, and indeed seems to me that this
behaviour is feasible. So the server behave correctly. What it could be
wrong is something on the "client side" (infact, the client - I don't
know exactly if the guilty is the router interconnecting the client LAN
to the Internet, or the PC behind it - send packets that the server
claims has already received).
Just for this I don't think that is the case to disable SACK on the
server side. It should be the client (Windows workstation or router XXX)
ro disable SACK, if anything..
rocsca
