J. Noel Chiappa (JNC@XX.LCS.MIT.EDU)
Wed 22 Jan 86 09:57:18-EST
One thing I'd advise for slow speed links is header compression.
Two sequential TCP packets on a connection look pretty much alike, and
if you only send the bytes that are different you wind up with
substantially smaller packets. For interactive typing, this makes a big
Dave Reed at MIT was one person who noticed this, and he took
some statistics on which patterns of repeated bytes were most common.
He proposed using a 'type byte' to identify the 250 most common patterns
of commonality (the extras were for various flags, etc). He was going to
compare the packet to the previous one, figure out which pattern applied
best, and send the pattern number and the changed bytes; the packet
would then be reassembled into the previous form at the far end.
He also had a framing system that had only one byte per packet of
overhead for sequential packets, and there are tricky issues like
needing a checksum on the *uncompressed* data otherwhise things can
get out of synch, etc.
He wrote a note describing this but I don't think it is
available online. If you want a copy (and please don't ask unless you
are really interested, since the supply is limited) send a message to
"Staton@xx.lcs.mit.edu", asking for "RFC 248, Improving Internet
Protocol Performance on Low Speed Lines".
I implemented the bulk of his proposal on the serial line code
for the Portable C Gateway; this has been in service on the 4800 baud
link to Proteon for several years, and works well. It was measured to
reduce the amount of bytes actuallly sent down the wire by about 50%
over a 2 month period! This is a figure averaged over *all* traffic,
including mail and file transfer!
We used a slightly different scheme for the compression, since I
couldn't figure out an easy algorithm to pick the best pattern (he
didn't give one)! I simply used a 32 bit mask, one bit for each of the
first 32 bytes; you sent the mask, the changed bytes, and the rest of
the packet. It was easy to compute the mask, and on a 4800 baud line I
didn't need to squeeze every drop of compression out. (I think I figured
out that 32 was almost as good as 48, even though the TCP header is
40 bytes, since many of the 8 bytes that are missed change from packet
to packet, and you have to have an extra two bytes to mask to charge
against the savings.)
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:39 GMT