Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!rice!rice!sun-spots-request
From: henry@zoo.toronto.edu
Newsgroups: comp.sys.sun
Subject: Re: CSLIP + Telebits + SunOS (was Re: Telebit T1000 vs T1500 (S
Keywords: Software
Message-ID: <1990Aug23.225521.10448@rice.edu>
Date: 16 Aug 90 17:00:00 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 23
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 311, message 1
X-Refs:  Original: v9n293

> I believe the [Van Jacobson] header compression is supposed to make
>single character TCP/IP packets much smaller, hopefully small enough to
>fit into one of Telebit's micro-short packets...

Yes; in the most common case, he gets a TCP/IP header down to 3-4 bytes,
which is not bad when you consider that two of those are the TCP checksum
(which is non-removable and non-compressible if you really want end-to-end
checking, and yes, you really want end-to-end checking).  So a
one-character packet will fit.

The Usenix terminal room in San Diego, I think it was, used PEP and an
alpha version of CSLIP begged from Van for its Internet link.  It was not
wonderful, but it was tolerable.  You should not expect beautiful TCP/IP
behavior from a PEP modem; TCP/IP really wants a really truly full-duplex
channel.  The next Usenix terminal room, Baltimore, used V.32 over a T2500
instead, which was considerably better.

>2) Will SLIP's successor, PPP, have different modem requirements?

I believe Van had considerable input into PPP, so it should not be worse.
(I haven't studied PPP carefully.)  I doubt that it will be better, except
that it will probably get better manufacturer support since it is a real
standard and (in most ways) a superior one.