Xref: utzoo comp.protocols.tcp-ip:4874 comp.dcom.modems:2659 comp.dcom.lans:1920
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!gatech!purdue!decwrl!vixie
From: vixie@decwrl.dec.com (Paul Vixie)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.modems,comp.dcom.lans
Subject: SLIP, Telebits, header compression
Message-ID: <12@jove.dec.com>
Date: 11 Oct 88 07:52:12 GMT
References: <8246@alice.UUCP> <166@tunscs.UUCP> <6217@watcgl.waterloo.edu>
Organization: DEC Western Research Lab
Lines: 137

[ This has turned into a summary of what I said at the Interop 88 SLIP BOF.
  If you were there and heard me, you don't need to read this. --vix ]

[ The IP/TCP explaination is fast and loose, intended for comp.dcom.modems
  readers, and is probably wrong in ways that many comp.protocols.tcp-ip
  readers would love to explain.  I am, for example, calling everything a
  "packet" even though sometimes I mean "frame" and sometimes I mean
  "segment" and sometimes I really do mean "packet".  If you must explain,
  please do so by mail.  --vix ]

Before I start, a disclaimer: I hack SLIP for fun, not for work.  Although
we may use some of my work here at WRL, I am _not_ working on a DEC product
and I am _not_ speaking here as a representative of DEC or anybody else.
I'll repeat this at the end of this article since many novices to e-mail
seem to want to quote people without maintaining context.  Please try to
avoid that; if you don't include my disclaimer when quoting me, please don't
include my name or any other identification, either.

idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes:
# I managed to get SLIP working using direct-connected Trailblazer modems
# at 19200 bps between two VaxStation 2000 Ultrix 2.0 systems using some
# 4.3bsd SLIP source from the net, slightly modified to compile and fit
# into our Ultrix binary distribution.  Interactive response (via rlogin
# over the SLIP line) was abysmal.  Bulk data transfer (via rcp) was not
# bad for large files.  I was going to test interactive response with
# data compression mode off, to see if that helped, but I haven't done
# that yet.

I have not yet tried it with data compression _on_, but with data compression
_off_, I get barely tolerable echo-delay for interactive things like rlogin
and telnet, and I get about 1000 bytes/sec with rcp or ftp.  Neither one is
impressive, considering that I'm talking to the modem at 19,200 baud, and
when I set up a 19,200 baud hardwired connection I have much better inter-
active response and get about 1700 bytes/sec on bulk file transfer.

I'll finish answering this other note and then add something original...

# Ultrix 2.4 seems to have a much nicer dial-up SLIP capability via an
# /etc/sliphosts file and login accounts that run /etc/slattach.  Haven't
# tried that yet.

The story I hear is that Ultrix 2.4 will never be released, and that Ultrix
3.0 is coming real soon now.  The dial-up SLIP stuff works extremely well;
once you grok /etc/sliphosts, you can get two systems to talk to eachother
by saying "slattach remotename" and all the dialing and logging in and etc
just happens.  Getting /etc/sliphosts and /etc/hosts right took some doing,
but maybe I'm disadvantaged since I didn't know what it was supposed to do
for me and I was used to doing it by hand.

One thing that _doesn't_ happen in Ultrix 3.0 SLIP is _dynamic dialup_.  This
is hard to even design properly, since you don't want a stray broadcast
packet to start all your modems dialing their neighbors.  Among other
problems.  But the ability to get the connection set up without having to
use "tip" and ~^Z and all that stuff is pretty nice.  Unfortunately it uses
the Ultrix /etc/acucap stuff, so it's largely nonportable (even if it were
releasable, which it probably is not).

Anyway, SLIP performance on the Telebits is Not Good, so let's talk about that
next.  The problem is basically that the Telebit is a half-duplex modem.  This
is what makes the UUCP spoofing so useful -- if the uucicos had to wait for
their ACK packets to get all the way back from the other side, they'd wait a
very long time indeed.  The Telebits have to "turn the line around" whenever
they have to send data in the "other" direction.

Well, wait, that's not quite right.  I've been told that there's this little
"ping pong packet" that the Telebits invisbly exchange, and that if the data
that wants to go in the "other direction" can fit in this invisible packet,
it can go without turning the line around.  I've been told that the amount
of data that will fit is "around 11 bytes".  I was unable to ascertain how
many bytes (or how much time) had to pass in the "forward" direction before
one of these "ping-pong packets" would be sent; basically I don't know what
ratio of forward/backward data will work and what ratio will not work.  From
my discussion with the expert, I gathered that that's not the right question.

I'm assuming that I can send 11 bytes backward for every 256 bytes I send
forward, since the PEP packet size is 256 bytes.  This would explain why the
UUCP spoof was needed, since UUCP likes to send about 64 bytes forward per 4
backward.  (Or something, somebody correct me if I'm wrong.)  With a SLIP
MTU of 1006, one assumes that if there are large FTP or RCP packets on in
the forward direction, an occasional TCP ACK in the backward direction might
get through without making the modem stop and turn around.  You can
definitely see the modem turning around, which is why the 1000 bytes/second
figure stunned me so much -- the modem was idle about half the time,
according to my eyeballs, and _still_ got 1K/sec.  Amazing device.

Anyway, 11 reverse bytes is not enough, not even for 1006 forward bytes.  So,
it's time to talk about S L I P H E A D E R C O M P R E S S I O N.  Before I
get going, I'd better explain that I'm a hacker and understand this stuff
only trivially.  But: your average IP packet has a 20 byte header, followed
by "data".  If the packet is TCP, there's (on average) another 20 bytes of
header, followed by "data", which, again, will depend on the protocol being
used.  Telnet, FTP, and rlogin all use TCP.  Note that there is therefore an
overhead of _40 bytes_ on the average Telnet/rlogin keystroke, unless you
batch them, which can cause unacceptable echo delays if you get too
ambitious about waiting for more things to add to the current "batch".

A TCP ACK packet is 40 bytes even.  There's no data area, it's all in the TCP
header.  One of these goes back for every RCP or FTP or Telnet or rlogin
data packet that gets sent out.  Note that in the worst (and also most
common) case, Telnet/rlogin cause 41 bytes to go in the forward direction
and 40 bytes to come back a beat later in the reverse direction, for every
character that you type.

The headers are too big.  Too big for the Telebit ping-pong packet, anyway.

They can be compressed.  Someone (Van again?) found that most of the headers
don't change from one packet to the next, in a single virtual connection.
The trick to header compression is to "diff" a packet against the last one
you sent and only send the parts that have changed.  You also have to send
a bitmap of the bytes you're sending.

A SLIP packet has a framing character at the front (sometimes) and a framing
character at the end.  These tell the remote SLIP driver where the packet is,
and they are non-negotiable overhead.  That leaves about 9 bytes ("about" is
the way the Telebit expert explained it, don't get mad at me") before the
modem has to turn around to get the packet across.  A TCP ACK is normally
40 bytes.  I don't know yet but I am hoping that the headers are full of
enough repeated information that these 40 bytes will fit in the 9 I have
available.  Remember that we've got to send a bitmap of changed header bytes
as part of each packet.

It sounds hopeless.  Like many hopeless-seeming things, it may work anyway,
depending on whether I can get more steam out of compression by looking at
bigger fields and getting more out of each bitmap element.  Or it may work
well enough as it is.

One thing I'm toying with (mentally; right now I'm just trying to keep the
system from crashing it :-)) is maintaining several different packets to
"diff" against so that if two virtual connections go on at the same time, it
won't go immediately to worst-case.  Details of this are presently out of
control; don't ask.  Suggestions (by mail!) are welcome.

I'll let you all know how it goes.
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013