Subject: kern/854: VJ-compression/RFC1323-extensions don't work together; patch included
To: None <gnats-admin@NetBSD.ORG>
From: Lon Willett <lon%softt.uucp@math.utah.edu>
List: netbsd-bugs
Date: 03/08/1995 15:05:09
>Number:         854
>Category:       kern
>Synopsis:       VJ-compression/RFC1323-extensions don't work together; patch included
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar  8 15:05:07 1995
>Originator:     Lon Willett
>Organization:
none
>Release:        NetBSD-current 8 Mar 95
>Environment:

System: NetBSD hilly 1.0A NetBSD 1.0A (HILLY) #150: Wed Mar 8 13:40:25 MST 1995 lon@hilly:/usr/src/sys/arch/i386/compile/HILLY i386

>Description:

(BTW, may this PR should have the class "change-request"; I'm not quite
sure where it fits in...)

Briefly: Van Jacobson header compression essentially doesn't happen
between two NetBSD machines.

Details are...

Van Jacobson header compression (for SLIP/PPP) relies on the TCP/IP
headers being nearly the same for sequential packets.  Otherwise, it
just does nothing and sends the packet uncompressed.  The RFC-1323
timestamp TCP option changes with just about every packet (or at least
with every other packet, depending on precise traffic patterns).

So if two machines use the RFC-1323 extensions, but are on opposite
sides of a slow serial link, their performance (latency wise) suffers
quite badly, since essentially no VJ compression is done for them.
(NB: neither machine has to be actually connected with a serial link;
just as long as there is one somewhere on the path between them).

The NetBSD kernel always does the RFC-1323 stuff (assuming the other end
is willing), with no obvious way of disabling it.  I believe that there
is a large enough group of NetBSD users who need the VJ compression more
than the RFC-1323 extensions to justify at least a CONFIG option to turn
off the RFC-1323 stuff; probably a sysctl() would be a good idea too.

The *right* way to do this would be to make a route-specific flag that
disables the timestamp use, but that can probably wait.

Or even better, talk the IAB into changing the timestamp option so that
it can be disabled from either end in the middle of a connection, and
dynamically detect when a connection can probably safely cease using the
timestamps.

This is digressing...

For now, I think that it would be a very good idea to provide a config
option and/or sysctl() to disable the RFC-1323 use, and some
documentation so that people are aware of it and when they might want
it.

>How-To-Repeat:

Have two NetBSD machines talk over a PPP link, and check out "pppstats".
The results are not good.

>Fix:

This patch ("diff -u" format) allows you to build a kernel with
the RFC-1323 use disabled by including the line:

	options "TCP_DO_RFC1323=0"

in you kernel configuration.

--- usr/src/sys/netinet/tcp_subr.c.orig	Mon Nov 21 15:48:13 1994
+++ usr/src/sys/netinet/tcp_subr.c	Wed Mar  8 13:25:10 1995
@@ -38,7 +38,21 @@
 /* patchable/settable parameters for tcp */
 int 	tcp_mssdflt = TCP_MSS;
 int 	tcp_rttdflt = TCPTV_SRTTDFLT / PR_SLOWHZ;
-int	tcp_do_rfc1323 = 1;
+
+/*
+ * Configure kernel with options "TCP_DO_RFC1323=0" to disable RFC1323 stuff.
+ * This is a good idea over slow SLIP/PPP links, because the timestamp
+ * pretty well destroys the VJ compression (any packet with a timestamp
+ * different from the previous one can't be compressed), as well as adding
+ * more overhead.
+ * XXX "tcp_do_rfc1323" should be sysctl() changeable.
+ * XXX And it should be a settable per route characteristic (with this just
+ * used as the default).
+ */
+#ifndef TCP_DO_RFC1323
+#define TCP_DO_RFC1323 1
+#endif
+int	tcp_do_rfc1323 = TCP_DO_RFC1323;
 
 extern	struct inpcb *tcp_last_inpcb;
 
>Audit-Trail:
>Unformatted: