From owner-freebsd-current  Mon Jan 15 07:07:21 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA17035
          for current-outgoing; Mon, 15 Jan 1996 07:07:21 -0800 (PST)
Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA17029
          for <current@FreeBSD.org>; Mon, 15 Jan 1996 07:07:15 -0800 (PST)
Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelayMX-SVR4_1.2/RBINF)
	id QAA26160; Mon, 15 Jan 1996 16:05:05 +0100
Received: from curie.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB)
	id QAA23979; Mon, 15 Jan 1996 16:04:57 +0100
Received: from localhost by curie.cs.utwente.nl (SMI-8.6/SMI-SVR4)
	id QAA02454; Mon, 15 Jan 1996 16:04:56 +0100
To: michael butler <imb@scgt.oz.au>
cc: current@FreeBSD.org
Subject: Re: PPP header compression ? 
In-reply-to: Your message of "Tue, 16 Jan 1996 00:24:42 +1100."
             <199601151324.AAA24819@asstdc.scgt.oz.au> 
Date: Mon, 15 Jan 1996 16:04:53 +0100
Message-ID: <2453.821718293@curie.cs.utwente.nl>
From: Andras Olah <olah@cs.utwente.nl>
Sender: owner-current@FreeBSD.org
Precedence: bulk

On Tue, 16 Jan 1996 00:24:42 +1100, michael butler wrote:
> This is curious .. kernel mode PPP is doing different things according to
> who it's talking to ..

The difference in the number of compressed packets is due to the use
of TCP options (apparently Linux doesn't use RFC 1323 options).  The
timestamp option (RFC 1323) is likely to change often, which
prevents compression of those packets.  This is from
/sys/net/pppcompress.c:

	/*
	 * Make sure that only what we expect to change changed. The first
	 * line of the `if' checks the IP protocol version, header length &
	 * type of service.  The 2nd line checks the "Don't fragment" bit.
	 * The 3rd line checks the time-to-live and protocol (the protocol
	 * check is unnecessary but costless).  The 4th line checks the TCP
	 * header length.  The 5th line checks IP options, if any.  The 6th
	 * line checks TCP options, if any.  If any of these things are
	 * different between the previous & current datagram, we send the
	 * current datagram `uncompressed'.
	 */

If a machine is behind a modem, it may make sense to switch
net.inet.tcp.rfc1323 off.  T/TCP (net.inet.tcp.rfc1644) doesn't hurt
here because the CC option doesn't change during the lifetime of a
connection.  Actually, when other hosts start to support T/TCP, it
should help by speeding up connection setup by one RTT (useful for
WWW).

Andras