Subject: Re: tcp_do_rfc1323 vs Linux - any solid understanding?
To: None <current-users@NetBSD.ORG>
From: None <is@Beverly.Rhein.DE>
List: current-users
Date: 06/09/1996 21:34:17
Peter Seebach ( 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 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.