> On Thu, 10 Sep 1998, David S. Miller wrote:
>
> > Yes, and I am furious too that this went in, it made us non-RFC
> > compliant for fast retransmit (again, for the 3rd time) as well. The
> > dup_ack changes are totally wrong, and make us respond to the wrong
> > duplicate ACK.
>
> Ah, now that explains the huge numbers of TCPv4 bad checksum errors over
> ppp in my logs since I booted 2.1.120. Normally there aren't a lot.
Huh? What are you talking about?
The change in question went into *2.1.121*, not 2.1.120. And it has
nothing whatever to do with checksums, the patch changes code that only
executes after the checksums have been verified.
<rant>
Could we please be a little more restrained here? Everybody seems to have
ignored the fact that this patch made FACK retransmissions work for the
first time in a very long time, perhaps the first time ever. And the fact
that the previous fast retransmit code was very wrong anyway - it would
have triggered non-RFC-compliant fast retransmits, except that the SACK
bug hid this problem. I know this for sure - my understanding of kernel
code is definitely inferior to that of a lot of other people, but my
printk()s and my tcpdump work as well as anybody else's. Even now I cannot
see how the wrong dupack triggers retransmit with the new code, and I
would have loved to see some explanation of this statement. As for the
other thing pointed out by Andrey (thank you for your detailed message),
the only correctness issue was with my explanation. With the code, it is
only an optimization thing, and I have already agreed his way is better.
</rant>
Regards,
-Vijay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html