Peter Seebach (seebs@solon.com) wrote:
: 
: Does anyone know *why* the rfc 1323 option produces pessimal network
: behavior?
: 
: 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. 

Regards,
	Ignatios