USENIX Board Studies UUCP

[Erik E. Fair]

In the referenced article, zeeff at b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
>
>All we really need is for vendors to fix the larger packet sizes 
>code in uucp so that acks will fit in small reverse channels.  Telebit 
>has made alot of money providing a workaround for this "bug" in uucp.  

A UUCP ACK is 6 bytes. My understanding is that the telebit "reverse
channel" allows for 11 bytes. Why doesn't it work the way you expect?
Could it be the small standard window size (2 to 3 packets), or the
small outbound packet size (64 bytes)? (rhetorical questions, don't
bother to answer)

There is no "bug" here; UUCP g-protocol was not engineered to use these
half-duplex pseudo-full-duplex modems. If you can't fix UUCP, you fix
the modem. Telebit did this and is selling quite well. There are other
advantages in having the modem understand what is going on and helping
too.

EUNET had the same problem (poor performance) with UUCP g-protocol over
the X.25 networks in Europe. Their solution was f-protocol, which works
well over X.25, when you have UUCP sources to play with to get the
f-protocol module in there. The Internet community did the same thing
with t-protocol (even simpler than "f") for UUCP over TCP/IP.

Carl Gutekunst of Pyramid experimented with f-protocol over early
(pre-spoof) telebit trailblazers with good (but not great) results. The
g-protocol support in the modems is better. No source changes required,
and performance is limited primarily by your CPU and serial interfaces
(and the other guy's).

By the way, splitting out the protocols into another module, either a
process or a linkable object is a good idea. Should do the same with
dialers too. Good luck getting the changes accepted back at AT&T.


The bottom line here is that a "new UUCP" has to meet the following
criteria:

1. it must be efficient in time, because that's how telephone usage is
	charged for.

	Preparing things offline and then blasting the bits as fast as
	you can while connected is still the best approach that I've
	heard; the other suggestion for lots of parallelism in virtual
	connections over the phone would seem to require real-time
	response from *both* computer systems involved (and potentially
	lots of CPU crunch on both sides of the connection to keep a
	9600 baud link really busy during all the "connected" time).

	Fixed cost leased lines are another matter, and there are
	better protocols than UUCP to be used in that situation (i.e.
	IP/TCP). ISDN is different yet again - I bet they'll charge by
	the byte for that service, which changes the base assumptions.

2. it had better interoperate with g-protocol; getting everyone to
	switch all at once is impossible (and then there is that
	investment in telebit trailblazers to consider).

3. it had better offer significant improvements in performance,
	functionality, and ease of administration over standard
	UUCP implementations, or no one will use it.

4. it had better be very cheap or free, or no one will use it.
	(alternative: get the UNIX vendors to take it and give it to
	the customers bundled like UUCP is now).


good luck with the study,

	Erik E. Fair	apple!fair	fair at apple.com