Date: Mon, 15 Jan 1996 16:04:53 +0100 From: Andras Olah <olah@cs.utwente.nl> To: michael butler <imb@scgt.oz.au> Cc: current@FreeBSD.org Subject: Re: PPP header compression ? Message-ID: <2453.821718293@curie.cs.utwente.nl> In-Reply-To: Your message of "Tue, 16 Jan 1996 00:24:42 %2B1100." <199601151324.AAA24819@asstdc.scgt.oz.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2453.821718293>