Messages in this thread | | | Date | Fri, 23 Jul 1999 08:52:56 -0700 | From | "David S. Miller" <> | Subject | Re: [PATCH] real fix found? (Re: timestamps, tcp_paws_discard and out of order packets/acks (fwd)) |
| |
Date: Thu, 22 Jul 1999 00:49:47 -0400 (EDT) From: "Benjamin C.R. LaHaise" <blah@kvack.org>
Ahh, you're right! I went back over RFC1323 and found out that the code in tcp_replace_ts_recent seems to be the root of this problem. The comment simply don't jive with the code or my reading of the rfc.
I have to think about this change some more. There are 3 independant issues working here.
1) RFC1323 describes the check wrong, as stated by the comment.
2) The rules stated by all RFCs and working drafts do not allow for best utilization of ACK feedback when ACKs are massively reordered. This is what my PAWS workaround is trying to accomplish.
I brought this issue up, with detailed traces, to the tcp-impl list, showing how detrimental it was to performance.
And the best response I got was "oh that bug, it hurts my head each time I think about it" So Linux will perform well in these cases and nobody else will because aparently even the RFC authors themselves do not care. Note that what Linux does makes the PAWS check rules for pure-ACKs orthogonal to the out of order data packet cases.
3) Audrey found some other RTT estimation problems which are being dealt with too, and these fixes have security implications as well. (before you could quite easily make a connection believe that the RTT was some nearly infinite value, effectively making the connection useless)
Until I can verify that the bug in question is fixed, and the above #3 issues are still addressed, I cannot apply this patch.
Later, David S. Miller davem@redhat.com
- 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/
| |