Subject: Re: tcp_do_rfc1323 vs Linux - any solid understanding?
To: None <current-users@NetBSD.ORG>
From: None <is@Beverly.Rhein.DE>
Date: 06/09/1996 21:34:17
Peter Seebach (email@example.com) wrote:
: Does anyone know *why* the rfc 1323 option produces pessimal network
: Symptom: Assume two NetBSD systems with rfc 1323 enabled. Connect
: one via ethernet to a Linux box, and the other via ppp to the same
: Linux box.
: PPP connection to Linux will be excellent and responsive. Ethernet
: likewise. But the connection between the NetBSD boxes is pessimal.
: This works with less direct connections on one side. For instance, if
: I enable 1323, my connection to sup.netbsd.org will take about 6 hours
: to get new changes since, say, a day earlier. Yes, *6 hours*. With
: rfc 1323 off on my end, I generally do the same thing in 10-15 minutes,
: unless the changes are vast.
This is a known problem with Linux, KA9Q and CISCO boxes with old
software. They will mangle TCP/IP option fields of packets in transit
--- illegally, but neithertheless effective, and destroy the timestamps
RFC-1323 tcpip uses to boost TCP performance by _measuring_
the one-way propagation delay instead of guessing it.
This is a pretty old problem, but unless (for the Linux systems)
somebody of us identifies and repairs the faulty code, it won't go away,
as all knowledgeable Linux users I know aren't aware of the problem at
all, or don't care about it.