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