[comp.org.usenix] USENIX Board Studies UUCP

ellie@usenix.UUCP (Ellie Young) (11/14/89)

     At the recent USENIX board meeting in Vienna, USENIX and EUUG agreed to
jointly study UUCP, and I have agreed to be the contact and collection point
for thoughts, proposals, suggestions, and flames.

     Most people would agree that UUCP has many problems.  Compatible versions
are not available throughout the entire UNIX community, and its penetration of
non-UNIX systems is minimal.  Maintaining and administering UUCP threatens the
sanity of even reasonably stable individuals, and is seriously damaging to
UNIX hackers.  The robustness and performance of the transmission protocols is
open to question.  The CPU and disk load that UUCP places on the operating
system can and probably should be improved.  ISO and X.25 compatibility are of
interest to the Europeans.  The list goes on.

     So what can USENIX do about this?  As you recall, a similar series of
discussions about Usenet led to sponsorship of the Stargate experiments and
eventually establishing and spinning off the very successful UUNET service.
Some of the concrete actions that we have discussed are:

      o Sponsoring a public-domain re-implementation of UUCP.

      o Picking up and distributing one of the existing re-implementations.

      o Hiring people to make studies or specific proposals.

As Treasurer of USENIX, I naturally objected to the third of these alter-
natives, which is why I got stuck with doing it.

     In my view, there are several things that a YACP (Yet Another Communica-
tion Protocol) program should do:

      o Be able to send and receive from existing UUCP sites.

      o Be sensitive to the security risks of network communication.

      o Be written for today's machine memories, disks, and network traffic.

      o Talk at least a few other protocols; ideally, make it easy to add new
        protocols through streams or dynamic linking.

      o Allow administration of incoming and outgoing traffic that is both
        easy and helpful for the naive, and not sadistic to the full-time ad-
        ministrator.

      o Be widely available, even for non-UNIX licensees, through some form of
        flexible licensing scheme.

      o Be robust enough that the hackings of cretins not disrupt the network,
        and produce clear error messages.

     From the organizational point of view, there are also some non-technical
questions:

      o What should we do, in detail?  Can we do the work in stages?

      o When we decide what to do, who does it?

      o How much does it cost?  How do we pay for it?

      o How do we distribute the final product?  On what terms?

      o If distributed in source form, how do we keep people from ``improv-
        ing'' it into incompatibility or worse?

      o Is this really the way we should be spending our money?

     USENIX is fortunate to have significant financial reserves, and can af-
ford to do this project right, if we decide to do it at all.  That is where
you come in.  We would like to hear from our members on all aspects of this
project - technical, organizational, the works.  Alternative projects are also
gratefully accepted.  Please send mail to:

        scj@usenix.org

We will be discussing this project at the next board meeting in January, and
hope to decide then how (or whether) to move forward.

                                                                 Steve Johnson

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/15/89)

In article <287@usenix.UUCP>, ellie@usenix.UUCP (Ellie Young) writes:
|        o Talk at least a few other protocols; ideally, make it easy to add new
|          protocols through streams or dynamic linking.

  Given the diversity of non-unix environments, I would suggest looking
closely at the idea of a flexible and easily configured scheme, such as
having a clear text file with the name of the protocol and the path of
the program to run it. The program could be started with stdin and
stdout pointing to the comm device, and stderr to the error log (or a
pipe back to the parent).

  Note that I'm not suggesting this as the best or only way to do it,
just that there be a way in which user written protocol modules may be
inserted without compilation and linking, and that the mechanism be
portable to at least {BSD,USG} unix, VMS, and MS-DOS.

|        o Be robust enough that the hackings of cretins not disrupt the network,
|          and produce clear error messages.

  Having the hacking of cretins produce clear error messages is a might task!

|        o How do we distribute the final product?  On what terms?

  If this is to be a success I think giving it away is the only
reasonable choice. If it is truely better vendors and standards groups
will adopt it, but having it free would prevent the situation with
current uucp, in which there are a large number of reimplementations
from various sources, with various levels of compatibility and
reliability.

|  
|        o If distributed in source form, how do we keep people from ``improv-
|          ing'' it into incompatibility or worse?

  You can't, and shouldn't. Define the license such that anyone
distributing a modified version would be required to distribute the
original with it (physical distribution) or make it available
(electronic distribution). If a small group of people releases updated
or enhanced versions a few times a year people will tend to send changes
back to the official version. This works well for a lot of existing net
software. 
|  
|        o Is this really the way we should be spending our money?

  On distribution, sure. Even on lobbying OSF and UI to adopt it. I
think you will be able to get people to offer their services to do the
design, creation and maintainence. I would certainly like a chance to
review the administrative interface before code got written, and I'm
sure a lot of other sysadms would too.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

henry@utzoo.uucp (Henry Spencer) (11/17/89)

In article <1624@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>|        o How do we distribute the final product?  On what terms?
>
>  If this is to be a success I think giving it away is the only
>reasonable choice. If it is truely better vendors and standards groups
>will adopt it, but having it free would prevent the situation with
>current uucp, in which there are a large number of reimplementations
>from various sources, with various levels of compatibility and
>reliability.

An even more pointed example is the ACSNet software.  It is approximately
the equivalent of UUCP, plus a number of extras.  In many ways it looks
better than UUCP.  But outside of Australia, where its ubiquitous presence
makes it essentially a necessity if you want to communicate, it's never 
caught on.  In my opinion, a major reason for that is that it costs money.
Not a lot... but enough to make it uncompetitive with UUCP.

If you really want a UUCP replacement to catch on, it has to be something
that *everyone*, even the folks with nervous lawyers or absolutely no money,
can run, and that vendors can distribute without extra paperwork or cost.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

taylor@limbo.Intuitive.Com (Dave Taylor) (11/17/89)

The discussion of the Usenix board studying UUCP has been most
interesting, and I'd like to continue some thoughts that Henry
Spencer (henry@utzoo.uucp) recently posted.

First off, I wholeheartedly agree that the Australian Computer
Science Network (ACSNet) is a much better implementation of a phone-
line based file exchange protocol than UUCP or HDB UUCP.  It has
such features as multiple "channels" so small messages can be 
inserted in the midst of a large 'batch' transfer, for example, as 
well as a much more sophisticated error catching and retransmission
algorithm.

Henry adds that he believes the problem with ACSNet not catching on 
outside of Australia is that it cost money to obtain.  I think he's 
off a bit on this, however, and he points out the problem I believe
it had in the US with his comment that ".. outside of Australia, where 
its ubiquitous presence makes it essentially a necessity if you want to 
communicate..."  If your neighbors are running ACSNet, you have to be
running it also.  Just like UUCP.  Basically, then, you can't successfully 
run a site that has ACSNet on some lines and UUCP on others without 
much difficulty and parallel administration.

ACSNet, however, *can* be a successful replacement for the existing
UUCP packages, even with it costing money.  What would need to happen
would be for the Usenix Association to arrange with the appropriate
schools in Australia the right to add complete UUCP functionality (on
the wire) to the package, all the while continuing to evolve and 
improve the administrative and user interfaces.

Then we'd be able to offer a scenario where those sites that opt to
stick with UUCP are okay, and those that choose to upgrade can, with
a simple field in L.sys/Systems, say, indicate whether the remote is
running ACSNet or one of the UUCP variants.  This would allow a very
graceful migration of larger, then smaller sites to the more sophisticated
package, and then would also allow vendors time to understand and
integrate the technology in with their current offerings.

It would, by the way, be very interesting to investigate having this
research occur in conjunction with the Open Software Foundation 
Research Institute...

						-- Dave Taylor
Intuitive Systems
Mountain View, California

taylor@limbo.intuitive.com    or   {uunet!}{decwrl,apple}!limbo!taylor

brad@looking.on.ca (Brad Templeton) (11/18/89)

In article <1989Nov16.182104.23746@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>If you really want a UUCP replacement to catch on, it has to be something
>that *everyone*, even the folks with nervous lawyers or absolutely no money,
>can run, and that vendors can distribute without extra paperwork or cost.

You mean like the group III FAX standard?   Yeah, right, a communications
protocol spoken by machines from hundreds of manufacturers, and you
actually have to pay for the hardware and/or software?

You're right, it'll never catch on, unless they give it away.  :-)
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473

henry@utzoo.uucp (Henry Spencer) (11/18/89)

In article <192@limbo.Intuitive.Com> taylor@limbo.Intuitive.Com (Dave Taylor) writes:
>Henry adds that he believes the problem with ACSNet not catching on 
>outside of Australia is that it cost money to obtain.  I think he's 
>off a bit on this, however, and he points out the problem I believe
>it had in the US... If your neighbors are running ACSNet, you have to be
>running it also.  Just like UUCP.  Basically, then, you can't successfully 
>run a site that has ACSNet on some lines and UUCP on others without 
>much difficulty and parallel administration.

Parallel administration is neither difficult nor new; lots of sites run
with both UUCP and TCP/IP, for example.  Many people hereabouts were quite
interested in the idea of talking ACSNet to capable sites, while inevitably
retaining UUCP to talk to backward parts of the world.  The licence and
the price tag killed that idea dead, however.  Getting other ACSNet sites
to talk to would not have been difficult if the software had been free;
we could all see the technical advantages.  But having to pay for it 
makes the chicken-and-egg problem *much* worse, because the cost and
paperwork of the software have to be justified, and it is difficult to
justify being the first site in the neighborhood to spend the money.
Or the second, or the third.  Especially when UUCP is free, and almost as
good for the most important purposes.  ACSNet succeeds in Australia mostly
because it has a de-facto monopoly.  Elsewhere, *nobody* runs it.

I would say that there is virtually no market for a UUCP lookalike that
provides only modest advantages but costs a substantial amount of money.
It would have to be a *lot* better.  That's difficult; UUCP does ship
data around pretty well.  Its administrative headaches are serious for
small sites run by naive users, but a controllable nuisance to bigger
sites with experienced personnel.  If the new software is to be really
widely adopted, the cost/benefit ratio has to be really favorable for
almost everyone.  Either it has to provide major benefits to just
about everyone or it has to have very low cost.  Preferably the latter,
given the number of sites with zero networking budget.  UUCP has been a
roaring success partly because it requires *no* explicit investment --
the software comes with Unix and most sites already have modems for other
reasons.

Much depends on the objective of the effort.  If it is to provide a
more-easily-administered version of UUCP for a substantial niche market --
e.g. the folks who can afford money for software but don't want to learn
to do UUCP sysadmin work -- then a serious pricetag is okay.  However,
then it has to be compatible over the phone lines, and major extra
functionality won't be much use unless it also gets added to UUCP, because
those niche-market sites talk to bigger sites much more than they talk to
each other.  If the objective is to provide something decisively superior
to UUCP that everybody will use, it has to be free or cost almost nothing.

I suggest that Usenix ought to be aiming for the second, not the first,
objective.  The pricey niche-market UUCP lookalike is just the sort of
thing that a commercial firm could pursue profitably, and indeed the UUNET
folks have expressed interest in the idea.  Usenix should be looking at
doing things that other people *won't* do.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (11/19/89)

There have been several attempts to write uucp replacements or
look-alikes over the years.  Many of them fail on the issue of
assurance:  how do we know this will work in the real world?  The
better versions of uucp (HDB, and I think 4.3bsd's) are the product of many
years of learning to deal with improbable or impossible conditions
(to say nothing of the bug fixes they have).  The odds are high
that you'll end up with new bugs, unless someone *very* experienced
and *very* gifted write it.  Even that's no guarantee.  HDB uucp was
supposed to be much more secure than its predecessor.  It was, but
not by much at first -- mostly because it let the shell get too close
to user-supplied data.  But the creation of uusched provided powerful
isolation from ``poison pill'' files that would kill off uucico.
One site might be affected, but communication with others would survive.

A few years ago, I had the opportunity to evaluate a uucp replacement.
It was far cleaner, and inherently far more secure.  I rejected it,
though, for the reasons I cite above:  the programmer was insufficiently
paranoid.  I'd seen too many wedged links caused by ``impossible''
conditions, and this program made no attempt to detect or recover from
such errors.  A pity; it had promise.

henry@utzoo.uucp (Henry Spencer) (11/19/89)

In article <49017@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:
>>If you really want a UUCP replacement to catch on, it has to be something
>>that *everyone*, even the folks with nervous lawyers or absolutely no money,
>>can run, and that vendors can distribute without extra paperwork or cost.
>
>You mean like the group III FAX standard?   Yeah, right, a communications
>protocol spoken by machines from hundreds of manufacturers, and you
>actually have to pay for the hardware and/or software?

Brad, note the word "everyone", which was emphasized.  My computer isn't
equipped for sending or receiving FAX.  Nor are most of the others on
Usenet.  Most of us would find it useful, but we can't justify the cost.
Like it or lump it, that is the nature of a large fraction of the UUCP
community.  Our attitude to a costly UUCP replacement will be *exactly*
like our attitude to FAX:  good stuff, but not useful enough to us to
justify the expense.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

bzs@world.std.com (Barry Shein) (11/19/89)

My thoughts...

1. What level are we talking about? Just transport level? Should this
new protocol fit underneath all existing UUCP applications?
Particularly management applications (e.g. the /usr/spool/uucp/
structure, uulog, etc.)?

2. If we're just talking about transport (maybe even if not) then I
think the way to go is "tried and true".

How about CSNET's Dial-up IP (or equivalent)?

It's in production and has the nice advantage that you're getting into
a protocol (and learning administration/management) which is the same
when you upgrade to a leased line, WAN service and probably the same
technology as you're using on your LAN. A lot of the knowledge will be
portable.

With ISDN coming and cheaper leased line alternatives I suspect most
people would be better off moving towards WAN protocols that can later
support them on higher-grade connections.

I realize there are possibly problems with Dial-Up IP but it would
seem a lot more effective to deal with those than to just invent
something. Unless someone really wants to support a huge amount of
work, including probably appealing to standards bodies and all that.

Then everyone can start using NNTP and other existing protocols (ftp
etc) on top of this transport. It dovetails with existing work.

I'm sure there's plenty of good work that would need to be done to
make Dial-Up IP completely satisfactory, but that's kind of the whole
idea. If it were all perfect we wouldn't be having this conversation.

Just a couple of thoughts.
-- 
        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

rsalz@bbn.com (Rich Salz) (11/20/89)

In <1989Nov19.032449.7940@world.std.com> bzs@world.std.com (Barry Shein) writes:
>I'm sure there's plenty of good work that would need to be done to
>make Dial-Up IP completely satisfactory, but that's kind of the whole
>idea. If it were all perfect we wouldn't be having this conversation.

First and foremest would be retro-fitting TCP/IP support into every machine
out there that currently doesn't have it....
	/r$
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/21/89)

In article <49017@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:

| You mean like the group III FAX standard?   Yeah, right, a communications
| protocol spoken by machines from hundreds of manufacturers, and you
| actually have to pay for the hardware and/or software?

  group III fax is not a replacement for something I get for free with
something else I have to buy. That's the difference. What Henry said,
(and more or less what I said by mail) is that it has to be (a) better
and (b) very cheap, such that individual users will use it, and OSF/UI
might consider picking it up and distributing it.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

scott@nastar.UUCP (Scott Barman) (11/21/89)

In article <1989Nov19.032449.7940@world.std.com> bzs@world.std.com (Barry Shein) writes:
>2. If we're just talking about transport (maybe even if not) then I
>think the way to go is "tried and true".
>
>How about CSNET's Dial-up IP (or equivalent)?

On this line of thinking, how about a version of SMTP over dial-up lines
to pass mail to different sites.  Just a thought...

>With ISDN coming and cheaper leased line alternatives I suspect most
>people would be better off moving towards WAN protocols that can later
>support them on higher-grade connections.

I recently investigated the cost for us to join the Internet through
Suranet and when I presented it, the response was "yea... sure... talk
to us next year... if we are still in business."  So reguardless of
the pending costs, ISDN and any other WAN is just out of reach for a
lot of people.  And this not only effects me here in the office, but
my machine at home--and I can't afford more than a telephone line!
Just because it's new and nice doesn't mean it's practical.  Hell, I
still know where there are IBM 360s still in use!

>Then everyone can start using NNTP and other existing protocols (ftp
>etc) on top of this transport. It dovetails with existing work.

I think this is what I was suggesting with my SMTP suggestion...  It
might not be practical but it sounds good!

-- 
scott barman
{gatech, emory}!nastar!scott

peter@ficc.uu.net (Peter da Silva) (11/21/89)

In article <2167@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes:
> First and foremest would be retro-fitting TCP/IP support into every machine
> out there that currently doesn't have it....

If you're just implementing a UUCP-level program, this wouldn't be necessary.
It could be set up to run like KA9Q if there's no support for any kind of
IPC beyond plain pipes... as a standalone program that makes and services
requests.
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>.
 'U`  --------------  +1 713 274 5180.
"ERROR:  trust not in UUCP routing tables"
	-- MAILER-DAEMON@mcsun.EU.net

steve@nuchat.UUCP (Steve Nuchia) (11/21/89)

In article <2167@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes:
>First and foremest would be retro-fitting TCP/IP support into every machine
>out there that currently doesn't have it....

Actually it would be pretty easy to glue a loop around Phil Karn's
FTP support that understands uucp's queueing conventions.  Just open
an FTP session in each direction, entirely in user space if necessary,
and pass the contents of the spool/uucp/sysname directory back and
forth.  Then let uuxqt take over -- you don't even need to use NNTP
and SMTP initially, but this bootstraps us up to SLIP, so those who
are ambitious enough can slap additional services into their ka9q.

This seesm to me to be the obvious way to go.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"Man is still the best computer that we can put aboard a spacecraft --
 and the only one that can be mass produced with unskilled labor."
					- Wernher von Braun

limonce@pilot.njin.net (Tom Limoncelli) (11/21/89)

Two things:

1 -- I agree that a link-layer should be developed.  i.e. split the
bandwidth between different channels.  On one channel, be xmitting news
(or mail, etc.).  On another channel be xmitting control packets
(ihave/sendme, whatever).  Another channel for playing nethack :-)
	-- this could be done with SLIP or dNet (by Matt Dillion)
	   dNet hasn't been implemented on anything but Unix and
AmigaDOS; MS-DOS and non-multitasking OSs would be a non-trivial port.
	-- Would NNTP over SLIP be good or could something more
optimal be devised?  (That is, NNTP used for full transport, not just
for reading news like it's used at some sites).
	-- I am not 100% versed in NNTP, but I don't think it does any
compression.  It would be interesting to compress on the packet level,
or have NNTP send compressed mail.

(Quick tangent: COMPRESSing a UUENCODED files isn't as good as
COMPRESSing the UUDECODED file...  does anyone think it'd be worth it
for a special COMPRESS that would detect a line of UUENCODED data, and
compress it using a different algorithm?  Maybe even decoding it,
compressing it, but marking it for the other side to re-encode it;
doing this on just for each line might be a non-trivial programming
task.  Any comments?)


2 -- It would be really nice to see configuring and maintenance
automated.  A nice (semi-flashy) curses-based program that asks you
questions and outputs configuration files and a nice configuration editor.
I am in the process of setting up UUCP on a VMS system (DECUS UUCP,
nice UUCP clone for VAX/VMS, BTW) and I worry about how well it will
be maintained after I graduate.

Just thoughts, no flames please; serious comments will be well-received.
-Tom
-- 
Tom Limoncelli    -- limonce@pilot.njin.net        Standard Disclaimer
CM 1060           -- tlimonce@drunivac.bitnet
P O Box 802       -- ...!rutgers!njin!drew!tlimonce
Madison, NJ 07940 -- 201-408-5389
  "I do not like green eggs and spam, I do not like them, Sam I am!"

mjl@cs.rit.edu (11/21/89)

In article <49017@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:
>In article <1989Nov16.182104.23746@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>If you really want a UUCP replacement to catch on, it has to be something
>>that *everyone*, even the folks with nervous lawyers or absolutely no money,
>>can run, and that vendors can distribute without extra paperwork or cost.
>
>You mean like the group III FAX standard?   Yeah, right, a communications
>protocol spoken by machines from hundreds of manufacturers, and you
>actually have to pay for the hardware and/or software?
>
>You're right, it'll never catch on, unless they give it away.  :-)

I think Brad's ignoring the fact of an existing, usable, if admittedly
non-optimal alternative.  Henry's comments are to the point, and simply
echo something I heard Bill Joy once state:  the first entry in a new
market niche sets the standard; to dislodge it, a competitor has have
significant advantages -- marginal advantages won't do.  In that
particular case he was discussing C vs. Modula-2, but the concept
applies equally well here.

And what's significant, of course, is determined by the buyers in the
target market.

Mike Lutz
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!rit!mjl
INTERNET:	mjlics@ultb.isc.rit.edu

peter@ficc.uu.net (Peter da Silva) (11/21/89)

In article <16645@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
> This seesm to me to be the obvious way to go.

As someone else mentioned to me, "You're making sense, that's the problem".
A dial-up SLIP-type protocol is just too logical (hopefully with packet-
level CRC and header compression).

> "Man is still the best computer that we can put aboard a spacecraft --
>  and the only one that can be mass produced with unskilled labor."
> 					- Wernher von Braun

I take it Wernher didn't have any kids of his own.

"Once they go up, who cares where they come down?"
	-- Tom Lehrer, "Wernher Von Braun".
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>.
 'U`  --------------  +1 713 274 5180.
"ERROR:  trust not in UUCP routing tables"
	-- MAILER-DAEMON@mcsun.EU.net

peter@ficc.uu.net (Peter da Silva) (11/22/89)

In article <1416@cs.rit.edu> mjl@prague.UUCP (Michael Lutz) writes:
> In article <49017@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:
> >You mean like the group III FAX standard?  ...

> >You're right, it'll never catch on, unless they give it away.  :-)

> I think Brad's ignoring the fact of an existing, usable, if admittedly
> non-optimal alternative.

Not to mention that FAX itself is an existing, usable, if admittedly non-
optimal alternative to email for a large percentage of cases.
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>.
 'U`  --------------  +1 713 274 5180.
"I agree 0bNNNNN would have been nice, however, and I sure wish X3J11 had taken
 time off from rabbinical hairsplitting to add it." -- Tom Neff <tneff@bfmny0>

fair@Apple.COM (Erik E. Fair) (11/22/89)

So long as telephone calls cost by the minute, NNTP and SMTP in their
existing form are not appropriate - they have way too much dead time
waiting for the remote to process the last command you sent them (and
no, NNTP does no compression - a conscious design decision, because we
weren't interested in reimplementing FTP to get the bits across
unscathed). These protocols were designed for networks with dedicated
or no cost links, where CPU time was the thing to be conserved, not
communication time.

UUCP in its present form is is perfect for telephone based
interactions; prepare files, place the call, blast the files over the
phone as fast as you can, hang up, and process what you got in from the
remote.  You spend minimum time actually on the phone (and therefore,
you minimize your communication costs). Dialup IP is for people with
unlimited local service, or money to burn.

Netnews batching is about as optimal as you can get right now. The only
way to make it cheaper is to try and figure out what the other guy has
(i.e. what you don't need to send him) before you call him. Netnews
already does this to the extent that it has the information (it never
sends to a site already in the Path: header), but beyond that we need
information we can't get without making the phone call we're trying to
avoid in the first place. NNTP cheats, because it can ask before it
sends and it's not a killer to wait for the answer.

UUCP Email, on the other hand, needs work - moving all those little
files is costly. BSMTP from BITNET land is one obvious alternative,
particularly since you should be able to compress the batched SMTP
transactions, and it will eliminate a whole raft of problems related to
passing Email addresses through the shell on the way to the rmail
command.

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

news@bbn.COM (News system owner ID) (11/22/89)

henry@utzoo.uucp (Henry Spencer) writes:
< If you really want a UUCP replacement to catch on, it has to be something
< that *everyone*, even the folks with nervous lawyers or absolutely no money,
< can run, and that vendors can distribute without extra paperwork or cost.

For a real-world example of just this (even a communications
program!), just look at the way Columbia handles Kermit.  The Columbia
license for use is even less restrictive than the FSF license
(partially because the Columbia folks aren't out to prove something
religious about software, freedom, and intellectual property).

If it isn't free, it won't be as widely distributed as, say, Kermit or
Emacs or TeX.

As a side note, I've thought of purposing Kermit as a new UUCP
protocol, because it's a good worst-case fall back (Kermit is even
better than 'g' at getting around bad communication situations).

		-- Paul Placeway <pplaceway@bbn.com>
		   (Mac Kermit coord; comm. hacker in general)

news@bbn.COM (News system owner ID) (11/22/89)

peter@ficc.uu.net (Peter da Silva) writes:
< In article <16645@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
< > This seesm to me to be the obvious way to go.
< 
< As someone else mentioned to me, "You're making sense, that's the problem".
< A dial-up SLIP-type protocol is just too logical (hopefully with packet-
< level CRC and header compression).

This would be a Good Way to do things, as long as you have an _eight_
bit clear channel to speak through.

 "Now let's see... I want to go out through my MNP-5 modem, which is
 locked at high speed, but my Unix box is too stupid to understand
 hardware flow control, so I have to use XON/XOFF (darn).  I'll be
 talking to their MNP-5 dial in modem, which is hooked up to a Micom
 port selector, which is in turn hooked to an Annex PAD, talking only
 telnet to their system, which doesn't understand the 8-bit option to
 telnet (darn, a 7-bit channel), and there's that stupid telnet escape
 character, not to mention the modem escape sequence.  But I still want
 to exchange news with them..."

(No, this isn't an invented scenerio -- it describes comming from the
outside world to one of many machines on the Ohio State U. main
campus.  I know -- I wired up that Annex)

The problem is that if you go SLIP (or PPP) only, you will discover
the same problem all those ZMODEM users have -- I can't get from here
to there (ZMODEM copes with XON/XOFF fine, but can't deal well with
random escape characters or 7-bit channels).

Perhaps we should start with an extension of PPP that can degrade down
to 6 1/2 bit clean, very short packets, if needed, but is more
efficient on a wider channel.

		-- Paul Placeway <pplaceway@bbn.com>

brad@looking.on.ca (Brad Templeton) (11/22/89)

There are two debates to be done here.   One thing that I think should be
established is a Universal protocol for start of conversation.

Such that every computer that answers phone calls would talk this protocol
to start.  It would be used by fax machines, e-mail stations, file-transfer
stations etc.

This protocol would negotiate A) what kind of data is being
transmitted (fax, e-mail, news, file transfer, EDI invoice, login session
etc.) and what protocol will be used for transfer of that info.

Then it should drop to the commonly negotiated protocol.

You *could* even negotiate modem protocols here.  I always thought it
would be better if smart modems started at 300 bps or something, and
figured out what they were, then jumped to the higher speeds.  None of
this 'present 6 carriers in strange order until one works' stuff.

Then you get one phone number on the phone system for all data calls.  Or
on the ISDN network.
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473

peter@ficc.uu.net (Peter da Silva) (11/23/89)

In article <48623@bbn.COM> pplacewa@antares.bbn.com (Paul W Placeway) writes:
> peter@ficc.uu.net (Peter da Silva) writes:
> < A dial-up SLIP-type protocol is just too logical (hopefully with packet-
> < level CRC and header compression).

> This would be a Good Way to do things, as long as you have an _eight_
> bit clear channel to speak through.

That's why I said "A SLIP-TYPE PROTOCOL" instead of plain SLIP. I believe
that Matt Dillon's DNET protocol passes IP information through a 7-bit
channel. At least it lets you open sockets at each end. With the right
configuration capability and handshaking you can switch to plain SLIP
where appropriate. And everybody wins.
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>.
 'U`  --------------  +1 713 274 5180.
"The basic notion underlying USENET is the flame."
	-- Chuq Von Rospach, chuq@Apple.COM 

romain@pyramid.pyramid.com (Romain Kang) (11/23/89)

Questions of cost aside, before anyone seriously considers ACSNet, they
should ask the Australians what they think of it.  Certainly it has
technical merit, but the sample of 1 that I have taken considers ACSNet
administration even more inscrutable than pre-Nutshell-documented UUCP,
and an order of magnitude more time-consuming.  (Incidentally, I do not
believe a judicious fee will deter users if they gain clearly superior
service; witness UUNET.)

If someone actually writes something from scratch, it would be best to
offer a protocol that is a) robust, and b) utilizes maximum bandwidth
over both full and half duplex links.  'g' protocol looses on both
counts.  (There's supposedly a BTL memo somewhere that explains why 'g'
happens to work as well as it does in the real world; if anyone can
tell me where to find it, I'm sure it would make great bedtime
reading).  Likewise, SLIP is not engineered for hostile environments,
and it has been already pointed out that the traditional TCP suite
(SMTP, FTP, and NNTP) requires unacceptable dead time.

Do we agree that backward compatibility with UUCP is merely a frill?
After all, most people will continue to receive it as part of their
UNIX systems for the foreseeable future.

brad@looking.on.ca (Brad Templeton) (11/23/89)

I wasn't saying that it wasn't sometimes easier for free software to become
widespread.

A whole bunch of people were saying it was effectively impossible for
a new communications standard to develop if people had to pay for it.

I brought up Group III fax as a counter-example.  It *is* possible.  In
fact it happens all the time.

In fact, it happens more often than with free software.  All the
"make software free so it can be widely distributed" advocates constantly
ignore the fact that the most widely distributed programs in the world
are all commercial products.   Counter-intuitive as it might be to you,
making something proprietary, *in the right way* usually increases
distribution, rather than reducing it.

Define a communications standard and get some commercial vendors to
implement and *support* it.  Let anybody implement it, including freeware
writers.  But if you want it to become widely used, there had better be
somebody out there promoting, advertising, distributing and supporting it.

This is a bit of a tangent to the issue, of course.
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473

marc@dumbcat.UUCP (Marco S Hyman) (11/23/89)

In article <36700@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
    UUCP in its present form is is perfect for telephone based
    interactions; prepare files, place the call, blast the files over the
    phone as fast as you can, hang up, and process what you got in from the
    remote.
    
I almost agree with Erik. Adding a standard full-duplex protocol to take
advantage of the other direction is the missing piece.  This is based upon
the assumption that the world will eventually migrate to full duplex links.
V.32 modems are a reality. ISDN may not be that far away.

// marc
-- 
// Marco S. Hyman		{ames,pyramid,sun}!pacbell!dumbcat!marc

steve@nuchat.UUCP (Steve Nuchia) (11/24/89)

In article <92074@pyramid.pyramid.com> romain@pyramid.pyramid.com (Romain Kang) writes:
>reading).  Likewise, SLIP is not engineered for hostile environments,
>and it has been already pointed out that the traditional TCP suite
>(SMTP, FTP, and NNTP) requires unacceptable dead time.

SLIP as it stands isn't suitable for hostile environments, but perhaps
a SLIP2 with link-level compression + error detection + retransmission
would work better, and could be written after "release 1.0".  I agree
completely with the idea expressed by another writer that the startup
and negotiation protocol needs to be nailed down first, but would add
that the transfer request and file spec protocol and the remote execution
control file semantics need to be nailed down in the same standard.

As far as dead time goes, a suitable amount of parallelism should
keep even the fastest links busy.  No reason not to allow each end
to keep several sessions going, at least one of which should be
blasting data at any given time.  The ability to keep the channel
busy is the primary reason for going to a multiplexed protocol.

This may require minor or major changes to the protocols -- for
instance NNTP could queue the article for the uucp module once
it determined that the remote wanted it, then continue negotiating.
This is the sort of thing that would be worked out over time.

The most important thing, in my view, is to get a package out that
is in source form and capable of interoperating with existing
TCP/IP and UUCP applcations without too much grief.  Having it
out there will enable a renaisance of experiments with the high
and low level protocols and a year from now we will know the
answers to some of the questions appearing here.  If we try to
answer all the questions first we're wasting everybody's time.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"Man is still the best computer that we can put aboard a spacecraft --
 and the only one that can be mass produced with unskilled labor."
					- Wernher von Braun

brad@looking.on.ca (Brad Templeton) (11/24/89)

Rather than SLIP or uucp/g, it is far easier to write a protocol that
supports 'stacked' multiple transmissions.   Yes, arbitary multiple sessions,
as found in X.25 and IP are nice, but it's complex to implement and not
as efficient as stacked transmissions.

If you allows stacked multiple transmissions, then a higher priority
transmission can interrupt a low priority one.  The low priority one is
suspended until the higher one is done.

Thus a long file transfer can be interrupted by a higher priority transfer
of a short file or a news batch, and a mail message can interrupt these,
and a 'msg' or 'finger' request etc can supersed that.

This is very easy to implement, and good for all lines that don't expect
to run dialogues like login sessions or SMTP.  ie. transaction systems, the
kind you want over phone lines.

Ease of implementation is important.  We want this to come up on a lot
of systems, and if we tell everybody to implement IP or X.25, it just makes
it less likely.
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473

ggw@wolves.uucp (Gregory G. Woodbury) (11/24/89)

In article <36700@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
>
>UUCP in its present form is is perfect for telephone based
>interactions; prepare files, place the call, blast the files over the
>phone as fast as you can, hang up, and process what you got in from the
>remote.  You spend minimum time actually on the phone (and therefore,
>you minimize your communication costs).
	Call this point 1
>
>Netnews batching is about as optimal as you can get right now. The only
>way to make it cheaper is to try and figure out what the other guy has
>(i.e. what you don't need to send him) before you call him. Netnews
>already does this to the extent that it has the information (it never
>sends to a site already in the Path: header), but beyond that we need
>information we can't get without making the phone call we're trying to
>avoid in the first place. NNTP cheats, because it can ask before it
>sends and it's not a killer to wait for the answer.
	Call this point 2
>
>UUCP Email, on the other hand, needs work - moving all those little
>files is costly. BSMTP from BITNET land is one obvious alternative,
>particularly since you should be able to compress the batched SMTP
>transactions, and it will eliminate a whole raft of problems related to
>passing Email addresses through the shell on the way to the rmail
>command.
	And this is point 3.

Point 1 and point 2 are (relatively) self-evident.  Uucp does send batches
quite well (up to a point!) and NetNews batching is quite efficient.
However, point 3 does not seem to follow from point 1 - to me it seems that
you contradict yourself (calling uucp efficient in point 1 and inefficient
in point 3).

	The unfortunate truth is that the de-facto 'g' protocol is very
inadequate in certain situations -- just watch the dead time on the line
when pushing 'g' uucp through a 9600 line without a telebit to buffer and
spoof the protocol!  This is especially true when one or both of the machines
have other processes running that make either end miss the window for the
ack.  Waiting for an alarm kills the throughput.

	The other point made by the original message was how to provide
a universal protocol for as many machines as possible!  My binary-only
System V machines have a fair amount of trouble talking to a vanilla
BSD uucp - it takes a lot of fiddling to make it work.  Additionally,
as a binary-only site, I can't add (easily) a new protocol to the uucp
stack.
	A full implementation of a PD or Freely Redistributable uucp-like
exchange system would make a lot of sense - borrow what is good from both
the socket and streams worlds, and provide it as a service.  Allow for
changing the window or packet length, or even other base protocols (like
xmodem or even kermit ;-) and it would be a wonder.  I would possibly
rip uucp out of (some) of my systems and install that!

-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>

henry@utzoo.uucp (Henry Spencer) (11/25/89)

In article <51949@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:
>Ease of implementation is important.  We want this to come up on a lot
>of systems, and if we tell everybody to implement IP or X.25, it just makes
>it less likely.

Uh, Brad, IP is not a complex protocol.  Really.  Not like X.25.  Especially
if, as in this situation, you really only need to be able to interoperate
with yourself -- many of the odds and ends in good TCP/IP implementations
boil down to enforcing proper behavior on congested shared networks.

Note also that there are several semi-freeware TCP/IP implementations
already in existence.  There is no need to reinvent the wheel.
-- 
That's not a joke, that's      |     Henry Spencer at U of Toronto Zoology
NASA.  -Nick Szabo             | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

fair@Apple.COM (Erik E. Fair) (11/25/89)

In the referenced article, marc@dumbcat.UUCP (Marco S Hyman) writes:
>    
>I almost agree with Erik. Adding a standard full-duplex protocol to take
>advantage of the other direction is the missing piece.  This is based upon
>the assumption that the world will eventually migrate to full duplex links.
>V.32 modems are a reality. ISDN may not be that far away.

Marc, I'm pretty sure that UUCP over trailblazers with 'g' spoofing
will *always* do better than UUCP over CCITT V.32. I've never seen UUCP
get better than 760 cps over a 9600 baud direct serial link. I
regularly see throughput in the 1000 to 1200 cps range (i.e. faster
than 9600 baud can give you) using trailblazers with my normal UUCP
neighbors. Stats available upon request.

The only reason to buy V.32 modems is for interactive access, and
protocols that really want it (e.g. IP). For unidirectional file
transfer protocols (e.g. UUCP g, xmodem, kermit), a trailblazer with
spoofing should always win bigger, because it's got more bandwidth to
allocate in the right direction, and it "understands" what's going on
(and helps the packets along).

CCITT V.32 is not as big win for UUCP as a Telebit Trailblazer.

ISDN is another question entirely, and the answer depends entirely upon
how the PTT's want to charge for it.

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

CYA:	I am nothing more than a satisfied customer of Telebit Corporation.

henry@utzoo.uucp (Henry Spencer) (11/26/89)

In article <36766@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
>The only reason to buy V.32 modems is for interactive access, and
>protocols that really want it (e.g. IP). For unidirectional file
>transfer protocols (e.g. UUCP g, xmodem, kermit), a trailblazer with
>spoofing should always win bigger, because it's got more bandwidth to
>allocate in the right direction, and it "understands" what's going on...

One can, of course, do what the ACSNet software did and develop a protocol
that can exploit a full-duplex link to transmit data in both directions
simultaneously.  Trouble is, most of the traffic on most sites is news,
and the flow there is usually almost entirely unidirectional.  Having a
bidirectional protocol won't help much for that.

I agree with Erik; for the file-transfer work that constitutes most UUCP
traffic in particular, Trailblazers clobber V.32 any day.
-- 
That's not a joke, that's      |     Henry Spencer at U of Toronto Zoology
NASA.  -Nick Szabo             | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

shri@ccs1.cs.umass.edu (H.Shrikumar{shri@ncst.in}) (12/01/89)

In article <1989Nov24.042806.23926@wolves.uucp> ggw@wolves.UUCP (Gregory G. Woo
dbury) writes:

>	A full implementation of a PD or Freely Redistributable uucp-like
>exchange system would make a lot of sense - borrow what is good from both
>the socket and streams worlds, and provide it as a service.  Allow for
>changing the window or packet length, or even other base protocols (like
>xmodem or even kermit ;-) and it would be a wonder.  I would possibly
>rip uucp out of (some) of my systems and install that!
>
>-- 
>Gregory G. Woodbury

 This problem which binary-only sites face is very real today, as has been
said before. This might happen again, were technology to confront us with
another new medium (After all 'g' protocol *was* at one time optimised for
telephone lines of the time, and then 'simplified' for real needs of the
time when E-mail and News did not bog them.)

 Time to plug my favorite idea....

 The "Pgxftg" "Ug" negotation in UUCP is a very nice feature. This can be
retained. Soon after a protocol is negotiated, a file "proto.g" must be
exec-ed.

 Now specify some interface spec. for this module, (spool area etc.) and 
let it do whatever to get it across ... (simple ack-timeout, or windowing
or dynamic negotiation with copmpression or ...).

 Newer protocols can be added by just writing code for a "proto.?". Binary
only sites will also be able to add their own protocols for any special
requirements withing house (UUCP over AMTOR/ARQ anyone?).

 The USENIX efforts for a modem-efficient protocol can implemented as such
a module within this specification.

-- shrikumar ( shri@ccs1.cs.umass.edu, shri@ncst.in ) 

romain@pyramid.pyramid.com (Romain Kang) (12/01/89)

Clearly, the Telebit 'g' spoof works well for us now.  Philosophically,
though, it bothers me that we have an OS as vendor-independent as UNIX,
yet we are so dependent on Telebit.  Ideally, other equipment should be
so friendly to UUCP as TBs, but in the two years since the 'g' spoof
came out, no company has followed Telebit's lead.  Maybe this isn't
anything to worry about.

What do other people see in the future?  Will we all be plugged into
ISDN or some "real" network, and if so, will UUCP have a place in such
an environment?  If this future doesn't happen, are we to expect a
post-Telebit dialup strategy to meet our UUCP needs ten years from now?

snoopy@sopwith (Snoopy) (12/04/89)

In article <1989Nov19.032449.7940@world.std.com> bzs@world.std.com (Barry Shein) writes:

| With ISDN coming and cheaper leased line alternatives I suspect most
| people would be better off moving towards WAN protocols that can later
| support them on higher-grade connections.

"Most people" are not going to have ISDN or leased lines.  "Most people"
are going to have POTS.  Any new system must run well on POTS lines.

    _____
   /_____\    Snoopy				"I read banned newsgroups."
  /_______\   cse.ogc.edu!sopwith!snoopy (until Dec 4)
    |___|     cse.ogi.edu!sopwith!snoopy (after Dec 4)
    |___|     uunet!tektronix!tessi!illian!sopwith!snoopy

markk@censor.UUCP (Mark Keating) (12/04/89)

    With the current discussions of what an New UUCP should be and how
it should be controlled distributed etc..., the topic seems to have
diverged to a discussion of what low level transport is better for what
type of lines etc... While this is an important part of UUCP, it seems
to me that UUCP more importantly is a store and foreward facility for a
variety of transports and communications methods.

    What I would really like to see is a UUCP that was modular so that
various transport protocols could easily be added in as seperate
functions, and were called as seperate processes. What I'm really asking
for is that the core Unix part, and the various physical interfaces
of UUCP be seperated, and connect them by having UUCP simply call them.

    This would require that a calling convention and status return be
defined for the transport and could allow for adding in "ANY" type of
transport, without the need to access or change the source. This would
allow for a basic UUCP 'g' to be supplied as the basic initial protocol,
and provide a minimum functional product, and allow for the independant
testing and implementation of other protocols. Then protocols could be
developed and distributed as independant modules that would link to UUCP
by their name.

    With the different communications methods available (V.32,
Trailblazer, X.25, Networks, ISDN etc...), I think it unlikley that
there will be ONE that does everything best, and more likey that several
will be required. With the facility to easily integrate and test new
ones, the race for the best protocol would be on (and may the best
protocol win :-) ).

    The same thing should be done with dialers where it should be
possible to replace the send-expect functions with a more capable and
flexible program or even simple shell script.  If a dialer as an
executable could be called then much better dialer functions could be
developed and distributed independantly as well. As modems get more
complex like the trailblazers with gobs of registers that do all kinds
of things and different models with different capabilities, this type
individual control would allow much more intelligent control of the
devices. The same thing goes for networks ISDN or whatever else may
be required to establish a link.

    I really think that the functional aspects of UUCP and the physical
interface be seperated, and that the main area of concern at this point
should be the administration and operational and generic Unix aspects of
UUCP. With the physical and logical sides of UUCP seperated a better
effort could be applied to provide enhanced support facilities and
things a like window based administration (windows meaning either simple
character based with curses, or X/GUI), monitoring like the uustatus
program by Edwin Carp etc.., while allowing individual efforts to deal
with different protocols, that could be easily distributed as single
stand alone modules.

    While I may be off on the exact proper split, the point here is that
"IF" it is possible to create a version of UUCP that is modular and open
ended, that a open ended core be produced that would allow the simple
addition of any require physical interfacing or transports required. It
seems reasonable to me that a solid core and well done Unix part of
UUCP, would allow better control and portability of that section, while
leaving it completely open ended now and in the future.


flames welcome, comments too. ( I've probably asked for it now.  :-) )

PS:  while Henry's suggestion of VVCP is kind of natural, the UU is
     for Unix to Unix, and I'd hate to lose that part of it, how about
     UUUCP, then as we add more U's we could go to scientific notation. :-)
 

zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (12/05/89)

>Clearly, the Telebit 'g' spoof works well for us now.  Philosophically,
>though, it bothers me that we have an OS as vendor-independent as UNIX,
>yet we are so dependent on Telebit.  Ideally, other equipment should be

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.  

-- 
Jon Zeeff    		<zeeff@b-tech.ann-arbor.mi.us>
Branch Technology 	<zeeff@b-tech.mi.org>

bzs@world.std.com (Barry Shein) (12/05/89)

From: snoopy@sopwith (Snoopy)
>bzs@world.std.com (Barry Shein) writes:
>
>| With ISDN coming and cheaper leased line alternatives I suspect most
>| people would be better off moving towards WAN protocols that can later
>| support them on higher-grade connections.
>
>"Most people" are not going to have ISDN or leased lines.  "Most people"
>are going to have POTS.  Any new system must run well on POTS lines.

(I assume by "most people" we both mean "most people who are likely to
use this service at all.)

I was under the impression that ISDN's PRI will be readily available
and relatively inexpensive. Haven't a few states (or perhaps BOCs)
already proposed tariff schedules for PRI service? Does anyone know
what these costs look like?

I also think leased lines are more within reach than most people
realize. Installation, last I checked, is a little expensive (like
$300) but a local 9600b leased line can be in the $100/mo range.
That's quite affordable by private individuals with even modest means
(they do have to want it, of course.) Multi-drop T1 also seems worth
investigating.

Given the current density of UUCP and/or USENET hosts in metropolitan
areas it might be surprisingly inexpensive to set up ad-hoc WANs. My
suspicion is that it's lack of organization that's preventing more of
this from happening rather than opportunity or cost, many are probably
spending more in message units right now than similar leased lines
would cost them. And the software could be better (although Cypress
did demonstrate that this kind of thing can work.)

If anyone would like to get together and take a serious look at the
possibilities for the Boston area get in touch by e-mail or phone. It
could be an interesting case study of what's really possible these
days (I'll be out of town the rest of this week, 12/5-9, but next
week.)

I'd really hate to see these proposals be based on bad information.
-- 
        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

fair@Apple.COM (Erik E. Fair) (12/06/89)

In the referenced article, zeeff@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@apple.com

dwh@cfcl.UUCP (Dave Hamaker) (12/06/89)

This thread seems likely to be followed by people with unusual interest in
and/or knowledge of modem file-transfer protocol issues.  I can't resist
the chance to reach that audience, although the relevance to the subject
at hand is marginal.  It could become relevant, but it really isn't yet.

You see, I have produced a specification for a file-transfer protocol which,
I believe, takes a very fresh look at the problem.  I think it is capable of
operating under any communications conditions that Kermit can handle, while
being able to (slightly) outperform Zmodem (or anything else I am aware of).
The design is emphatically public domain.

I will be happy to email the specification document to anyone interested.
Be forewarned that it is about fifty pages worth of text.  If you might be
tempted to try implementing the design, I would love to hear from you.  I
would also cherish ruthless criticism.

-Dave Hamaker
dwh@cfcl.UUCP
...!ucbvax!ucsfcgl!hoptoad!cfcl!dwh

zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (12/07/89)

In article <37014@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
>In the referenced article, zeeff@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 
>
>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

It's the small packet size.  11 bytes how often?  On a percentage 
basis: 6/64 ~= 10% which is too big for a trailblazer or HST reverse 
channel.  6/512 = 1% which should fit.  

>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

Whether it was engineered for it or not, uucp using 'g' can support 
larger packet sizes which, with a fixed ack size, are what these 
modems need to avoid reversing the channel.  If fact, large packets 
even work on some versions of uucp (I've tried it).  

Telebit did a smart thing and is being rewarded for it.  It doesn't mean
that other solutions should be neglected.

-- 
Jon Zeeff    		<zeeff@b-tech.ann-arbor.mi.us>
Branch Technology 	<zeeff@b-tech.mi.org>

wcs) (12/08/89)

]>Clearly, the Telebit 'g' spoof works well for us now.  Philosophically,
]>though, it bothers me that we have an OS as vendor-independent as UNIX,
]>yet we are so dependent on Telebit.  Ideally, other equipment should be

Actually, it's the opposite - the protocol Telebit modems use to
talk to each other interferes with vendor-independent protocols such
as uucp-g, kermit, xmodem, etc., by having long line-turn-around
delays and doing large-packet transmissions, both of which are much
different from the default case (even flow on full-duplex, which you
get either from real wire or conventional modems.)

Telebit has done a lot of work to create workarounds so we can use
normal software making normal assumptions, and still have their
boxes in the middle.  The reason we're all dependent on them is
because their boxes cost such a reasonable price that it's much
cheaper to pay $500-1000 (depending on when you bought it) than it
is to pay the additional phone bills for 1200-2400 baud.

-- 
# Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 api.att.com!wcs

#		We did it for the formlessness ...

stevesc@microsoft.UUCP (Steve Schonberger) (12/08/89)

In article </}_S!#@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
>>Clearly, the Telebit 'g' spoof works well for us now.  Philosophically,
>>though, it bothers me that we have an OS as vendor-independent as UNIX,
>>yet we are so dependent on Telebit.  Ideally, other equipment should be

>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.  

Things like this can be done to fix the problem between pairs of
sites.  Assuming sites A and B have a large-packet uucp but C just has
regular uucp, A and B can configure their mail to use enhanced uucp
between each other, but old uucp with C, just as is now done when A
and B are on the Internet but C isn't.  The change doesn't have to
happen for everyone at once.  Unless there's something particularly
hardware dependent about uucp, an enhanced public domain version could
be posted and soon a lot of sites could be using it.

-- 
	Steve Schonberger	microsoft!stevesc@uunet.uu.net
	"Working under pressure is the sugar that we crave" --A. Lamb

meissner@dg-rtp.dg.com (Michael Meissner) (12/12/89)

In article </}_S!#@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:

|  >Clearly, the Telebit 'g' spoof works well for us now.  Philosophically,
|  >though, it bothers me that we have an OS as vendor-independent as UNIX,
|  >yet we are so dependent on Telebit.  Ideally, other equipment should be
|  
|  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.  

Another thing to look into is dealing with small mail messages as well
as the large news batches.  As I understand the way uucp works, it has
to syncronize both ends when each file is completely transfered.  This
leads to poor performance if you don't have a large file to amortize
the startup and shutdown costs before the next file is transfered.
--
--
Michael Meissner, Data General.
Until 12/15:	meissner@dg-rtp.DG.COM
After 12/15:	meissner@osf.org

fair@Apple.COM (Erik E. Fair) (12/13/89)

In the referenced article, meissner@dg-rtp.dg.com (Michael Meissner) writes:
>
>Another thing to look into is dealing with small mail messages as well
>as the large news batches.  As I understand the way uucp works, it has
>to syncronize both ends when each file is completely transfered.  This
>leads to poor performance if you don't have a large file to amortize
>the startup and shutdown costs before the next file is transfered.

This is the problem that BSMTP can solve (as I mentioned a week or two ago).

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

spencer@eecs.umich.edu (Spencer W. Thomas) (12/14/89)

You should all read the Viewpoint column in this month's CACM.  John
McCarthy writes "Networks considered harmful for electronic mail".  He
pushes development of a standard that will compete with FAX, where you
can send mail to "any" telephone number, without pre-arrangement with
the receiving party.  Otherwise, he feels, e-mail will never "make
it", since FAX is just easier.

Quote: "E-mail could work the same way at similar costs [as FAX,
projected to be $200/machine by 2010, and present in 50% of all homes
(yes, something like 30 MILLION installations)], but because of a
mistake by DARPA about 20 years ago, i.e., making a special-purpose,
special-politics ARPANET network the main vehicle for e-mail, it was
combined with other network uses that require higher bandwidth and
packet switching.  Another mistake was UUCP.  It uses the telephone
network, but three features inherited from its use within Bell
Telephone Laboratories made its widespread adoption a blunder."

Read it yourself if you want to know why.  And factor his points into
the "future of UUCP", if you can.


--
=Spencer (spencer@eecs.umich.edu)

rpw3@rigden.wpd.sgi.com (Robert P. Warnock) (12/15/89)

In article <SPENCER.89Dec13124514@spline.eecs.umich.edu> spencer@eecs.umich.edu (Spencer W. Thomas) writes:
>You should all read the Viewpoint column in this month's CACM.  John
>McCarthy writes "Networks considered harmful for electronic mail".  He
>pushes development of a standard that will compete with FAX, where you
>can send mail to "any" telephone number, without pre-arrangement with
>the receiving party.  Otherwise, he feels, e-mail will never "make
>it", since FAX is just easier.
>
>Quote: "E-mail could work the same way at similar costs [as FAX,
>projected to be $200/machine by 2010, and present in 50% of all homes
>(yes, something like 30 MILLION installations)], but because of a
>mistake by DARPA about 20 years ago, i.e., making a special-purpose,
>special-politics ARPANET network the main vehicle for e-mail, it was
>combined with other network uses that require higher bandwidth and
>packet switching.  Another mistake was UUCP.  It uses the telephone
>network, but three features inherited from its use within Bell
>Telephone Laboratories made its widespread adoption a blunder."
>
>Read it yourself if you want to know why.  And factor his points into
>the "future of UUCP", if you can.
>
>
>--
>=Spencer (spencer@eecs.umich.edu)

peter@ficc.uu.net (Peter da Silva) (12/15/89)

In article <SPENCER.89Dec13124514@spline.eecs.umich.edu> spencer@eecs.umich.edu (Spencer W. Thomas) writes:
>You should all read the Viewpoint column in this month's CACM.  John
>McCarthy writes "Networks considered harmful for electronic mail".

Yeh, I read about it. It'd take a trivial change to uucp to support
"mail phone-number!user", and after that it's a matter of politics
to get people to allow the anonymous UUCP login.

There wasn't a hell of a lot of meat to that article. It's nothing that
gobs of people haven't been saying all along. It just takes someone to
write the code.

Change 1: you'd need to get uucp to do the connect to phone-number.
Change 2: you'd need to get uucp to identify itself as your-phone-#
	when it makes the connection.
Change 3: you'd need to do something about the chat script.

All we need to get it started is to get someone to make the changes
and ship the code. Certainly fair game for the Usenix folks.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

brad@looking.on.ca (Brad Templeton) (12/16/89)

I am not so sure that E-mail by phone is so good an idea, in the end.

I feel fairly certain that within just a few years, E-mail will be available
for a fixed price -- ie. for $10/month, you get all the E-mail you
can type.  (To avoid people sending megabyte files around this way, no
doubt there will be limits on the total data to any one destination for
a given user.)

It has to go this way, I think.  Unlike phone, video and other things
which require almost 0-latency in delivery, E-mail doesn't care if it
takes 1 second or even 1000 seconds to reach its destination.   There
are so many high bandwidth channels being built that we could send all
the typed messages of the whole world in their spare bandwidth.

And this can't result in anything but fixed-price E-mail, because people
*love* fixed price services, and companies love them even more.

So E-mail by modem and phone may be dead before long, anyway.
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473

rpw3@rigden.wpd.sgi.com (Robert P. Warnock) (12/16/89)

[I apologize for the null article <46406@sgi.sgi.com>; I'm still getting
plugged into a new environment, and news isn't *quite* the same here as
before. Let's try again...]

In article <SPENCER.89Dec13124514@spline.eecs.umich.edu>,
spencer@eecs.umich.edu (Spencer W. Thomas) writes:
+---------------
| You should all read the Viewpoint column in this month's CACM.  John
| McCarthy writes "Networks considered harmful for electronic mail".  He
| pushes development of a standard that will compete with FAX, where you
| can send mail to "any" telephone number, without pre-arrangement with
| the receiving party.  Otherwise, he feels, e-mail will never "make
| it", since FAX is just easier.
+---------------

"When it's steamboat time, steamboats get built."

This may be an idea whose time has come. I recall Dave Yost proposing this
exact thing a few months ago, before he left L.A. and moved to New York.
We were talking about what it would take, and decided that the cost would
be somewhere between a telephone answerer and a small PC. Not $200, since
you really do need a hard disk (even a small one), but less than $1000.
The idea is that you have this small black shoebox that sits on a phone
line, and has an RS-232 line you can connect to your Mac or PC or whatever,
but your Mac/PC does *not* have to be on for the box to send/receive mail,
only for you to read/compose/queue it.  Of course, the box has a modem
and some sort of (slow, cheap) CPU, but from outside you see something
like a hard-wired ATTmail session... *NOT* a "computer".

Obviously, one wants such a thing to *also* be able to talk to/from
Unix-based mail systems, but as usual, the gateway/conversion burden
will probably be on the Unix system.

Anyway, sounds like a great market opportunity for "somebody"...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@wpd.sgi.com	rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

snoopy@sopwith (Snoopy) (12/18/89)

In article <1989Dec5.005413.7500@world.std.com> bzs@world.std.com (Barry Shein) writes:
|
|From: snoopy@sopwith (Snoopy)
|>bzs@world.std.com (Barry Shein) writes:
|>
|>| With ISDN coming and cheaper leased line alternatives I suspect most
|>| people would be better off moving towards WAN protocols that can later
|>| support them on higher-grade connections.
|>
|>"Most people" are not going to have ISDN or leased lines.  "Most people"
|>are going to have POTS.  Any new system must run well on POTS lines.
|
|(I assume by "most people" we both mean "most people who are likely to
|use this service at all.)

Well, not necessarily.  What if I want to take a laptop along when I
go visit mom in Lotech, USA?

|I also think leased lines are more within reach than most people
|realize. Installation, last I checked, is a little expensive (like
|$300) but a local 9600b leased line can be in the $100/mo range.
|That's quite affordable by private individuals with even modest means

I'm currently getting 11000bps using a Telebit on my voice line which
I need anyway.  Why should I pay $300 inst + $100/month for lower
performance?  I have much better things to spend that money on.


    _____
   /_____\    Snoopy				"I read banned newsgroups."
  /_______\   cse.ogi.edu!sopwith!snoopy
    |___|     sun!nosun!qiclab!sopwith!snoopy
    |___|     uunet!tektronix!tessi!illian!sopwith!snoopy

ellie@usenix.UUCP (Ellie Young) (01/15/90)

UUCP Project Draws Strong Response

     As discussed in the last issue of ;login: and in this newsgroup, USENIX is studying uucp to see
whether we can help promote better communication, in a literal sense, by
activities which might range from standardization up to a possible sponsored
implementation.

     We have received more than 30 mail messages on this topic from Europe,
Australia, and the U.S.  Many of these were cheers and bravos, and most
requested further information.  A number were from people who were actively
working on uucp itself, or on programs that were similar to, or ``better''
than uucp.  In particular, there was relevant work going on at AT&T, GNU, in
Australia with ACSnet, in Great Britain with UKUUCP, and at Prime Computer in
Australia, with MYL.  A program called PP, which supports numerous protocols,
is in the beta stage in Great Britain, and will be ``openly available.''
Finally, Rick Adams, has been doing advanced CPR on uucp for years to keep
uunet running smoothly, and has suggested that he might make this available.

     There appear to be three major decision areas (battlegrounds?).  One is
technical - what do we want, given that we can't have everything.  Some people
wrote and suggested that using anything other than streams and TLI was
senseless and short-sighted; others wrote that the use of streams and TLI
would lock us out of a large number of smaller and older machines, and should
be avoided at all cost.  I personally would like to have some graphic (X-ish)
administration interface so I can add a phone number without screwing up the
company-wide system for days; but this limits our communication scope.

     The next set of decisions has to do with the distribution of the system;
will it be free, or merely cheap.  The majority think it should be distributed
in source code; a vocal minority paint a picture of a totally snarled net
created by enthusiastic hackery by hundreds of monkeys at their terminals.
Some think it should be licensed, others totally free.

     The related problem is how to get it done; should USENIX endorse,
support, initiate, or purchase the work?  There are a lot of touchy issues
here, including what the cost would be, how it would be recovered (hold on to
your wallets, members!), and how USENIX would ensure that it got its money's
worth (ever try to manage a software project with volunteers?).

     The USENIX board of directors will be taking this topic up again at its
meeting in Washington, D.C.  We shall report on the outcome of that meeting in
the next issue of ;login: and on the net. I haven't really done justice in this summary to
some of the lengthy, thoughtful comments that we have received; thank you for
the encouragement and the information.  Further comments and suggestions can
be sent to scj@usenix.org or discussed with other USENIX board members.

                                                                 Steve Johnson