tslee@oracle.uucp (Terry Lee) (10/17/90)
I need to configure a TCP network, where sizzling performance is not necessary. In fact, the primary user of the net will be UUCP. I'm trying to minimize routers, bridges, etc. where not necessary, so things like SLIP look very promising. However, it seems that everyone I ask about SLIP seems to speak ill of it, and curiously mostly "heard that it's bad" not "used it and it was bad." I hear comments about it being slow, but is it SLIP, or merely the serial line? E.g., what does one expect off a 9.6k line? I did hear one concrete complaint; that SLIP does not do error correcting efficiently (or at all?)- is this true? I have used SLIP, but from a user standpoint a couple of years ago. It wasn't the fastest when running RFS over it, but it was cheaper than buying an ether- net board. So in summary, is SLIP all that bad? Are there other relatively standard methods of running TCP without sizable investments in hardware? Thanks in advance- Terry Lee tslee@oracle.com
pww@bnr.ca (Peter Whittaker) (10/17/90)
In article <1990Oct16.225610.3505@oracle.com> tslee@oracle.uucp (Terry Lee) writes: >However, it seems that everyone I ask about SLIP seems to speak ill of it, >So in summary, is SLIP all that bad? Are there other relatively standard >methods of running TCP without sizable investments in hardware? See UnixWorld, October 1989, page 85: "TCP/IP Over Serial Lines" (see also RFC 1055, the SLIP RFC (anon ftp to nic.ddn.mil to get it). Quote from article: "SLIP represents an interesting paradox. The protocol itself is quite simple -with some implementations taking just 24 lines of code. On the other hand, use of SLIP is generally limited to sites with a high concentration of UNIX gurus, such as universities and technical companies, because it can require 'tinkering', users say.... In short, SLIP is a classic UNIX solution - it's quick and dirty, but it gets the job done." Other quote (about leased line vs no leased line SLIP): "I'm not sure if it's doable. It's generally easiest with a leased line installed". (Above used without permission. The author can be contacted on the Internet as slf@well.uucp, sharonfisher on BIX, or 76012,1147 on CompuServe). Note: the Internet community is apparently working on the PPP (Point-to-Point protocol) as a way of curing some SLIP headaches. Anyone know PPP's status? Hope this helps a bit. Peter W.
joe@astph.UUCP (Joe Broniszewski) (10/17/90)
In article <1990Oct16.225610.3505@oracle.com>, tslee@oracle.uucp (Terry Lee) writes: > > So in summary, is SLIP all that bad? Are there other relatively standard > methods of running TCP without sizable investments in hardware? We used slip for a while between unix machines in conjunction with an intelligent multi port serial board. I used a 38.4K line and got a throughput of 27.9K. It worked well. We could have multiple telnet sessions, file transfer, and remote printing. I thought that it would be a low cost ethernet substitution, but the support for it was not there. ISC is our unix vendor and they have no plans to support nfs on slip. They claimed that it was very error prone and not a good networking solution. I never got around to getting it to work with a modem. The main problem that I saw with our direct connection was the inability to network more than 2 machines together (multi serial line slip is not a option for me - ISC). Over all, my experience with slip was very positive, however limited. My feeling is that many networking programmers, etc. look at slip as an inferior solution. Unfortunately, there is not a lot of money to be made for slip research, so it goes by the way side. I have heard that there are a few other standards for running tcp over serial lines coming out soon. -- Joe Broniszewski || Philadelphia || (814) 234-8592x4 astph!joe@psuvax1 || Phillies || psuvax1!astph!joe
scooper@max4.llnl.gov (Steve Cooper) (10/17/90)
|> Note: the Internet community is apparently working on the PPP (Point-to-Point |> protocol) as a way of curing some SLIP headaches. Anyone know PPP's status? Some PPP products were featured at Interop '90 last week in one of their "Solutions Showcase (tm) Demonstrations". The topology of PPP demonstrations had cisco, Telebit, 3Com, and Network Systems communicating over 56K bps synchronous links and Telebit, INTERACTIVE, and Xylogics communicating over 9.6K and 19.2K bps asynchronous links. RFC 1171 describes the protocol and obsoletes RFC 1134. RFC 1172 describes the initial configuration options. ---------------------------------------+-------------------------------- Stephen P. Cooper | scooper@aracmax1.llnl.gov (now) who works at but does not represent | cooper10@llnl.gov (soon) Lawrence Livermore National Laboratory |
csg@able (Carl S. Gutekunst) (10/17/90)
SLIP is simple to use and quite reliable over serial links where the error rate is low, e.g., over a TrailBlazer or MNP modem, or just plain point-to- point RS-232. SLIP itself has no error correction at all; it just does framing of IP packets, which *do* have a checksum. There are timing problems in pre- 4.3BSD-tahoe kernels that limit throughput, particular in interactive sessions (like telnet or an X server). FTP, NFS, SMTP, and NNTP all work quite well. It is extremely easy to use over a direct wire or leased line. It is not very difficult over a dialup, *if* you have a modem that can autodial a previously stored number when DTR is raised. Someone at NASA Ames (Steve Schoch?) did a little package called slipsh (the SLIP Shell) that makes the dialin procedure more complex, but provides password (i.e., login) security. PPP is really just HDLC asynchronous. A proper implementation is complex, and can be a real CPU hog. Were I to write from scratch, I'd need about 6 weeks, and I'm an HDLC expert. Present PD versions are little more than toys; I don't know who/when someone is going to write a better version that they are willing to give away. (Pyramid's version, if done at all, would be based on priority HDLC code that we already have.) I do not see PPP is a viable replacement for SLIP. It is just way too complex for the job. It does offer vastly increased realiability over noisy links. But I would not consider using a TCP/IP-type protocol over those kinds of links, anyway. If I really want to go big time, I'll run IP right over real HDLC, on synchronous modems, the way Cisco does. Then you have something that you can use over the new cheap 56K DDS lines. Alas, synchronous hardware on UNIX is rare, and far more expensive than asynch.... (But what do I know? I thought implementing uucp 'g' protocol on the Trail- Blazer wouldn't fly, either. :-)) <csg>
bob@MorningStar.Com (Bob Sutterfield) (10/18/90)
In article <1990Oct17.133028.14849@bnrgate.bnr.ca> pww@bnr.ca (Peter Whittaker) writes: In article <1990Oct16.225610.3505@oracle.com> tslee@oracle.uucp (Terry Lee) writes: However, it seems that everyone I ask about SLIP seems to speak ill of it... is SLIP all that bad? Are there other relatively standard methods of running TCP without sizable investments in hardware? Yes, SLIP was all that bad, at least by modern standards (as usual, it was an inspired wonder in its time!). It was a first cut, and as noted, quick and dirty and hard to manage. The second cut included compressed headers and so then at least provided more reasonable performance. But most of the problems remained, and that's OK, because they showed what needed to be done when serial line IP was done Right, From Scratch again: Note: the Internet community is apparently working on the PPP (Point-to-Point protocol) as a way of curing some SLIP headaches. Anyone know PPP's status? PPP is standardized in RFC1171, with initial configuration options in RFC1172. A Sun implementation is available from omnigate.clarkson.edu:pub/sun/ppp.tar.Z, and a KA9Q implementation from ucdavis.ucdavis.edu:dist/ppp/*. Others, of various ancestry and heritage, are available from CMU (parent of the UCDavis KA9Q stuff, I think) and Hawaii, though I can't point directly to them offhand. (Brad Clements wrote that Sun stuff for the 386i. Karl Fox <karl@morningstar.com> ported it to SPARC under SunOS 4.0.3 and will share his changes with folks who ask, via mail. I don't know whether it's been ported to SunOS 4.1 yet.) Unless you have a dire need for backward compatibility, you shouldn't be bothering with SLIP in this day and age, particularly not Classic SLIP without header compression. New installations should use PPP.
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (10/19/90)
However, it seems that everyone I ask about SLIP seems to speak ill of
it, and curiously mostly "heard that it's bad" not "used it and it was
bad." I hear comments about it being slow, but is it SLIP, or merely
the serial line? E.g., what does one expect off a 9.6k line? I did
hear one concrete complaint; that SLIP does not do error correcting
efficiently (or at all?)- is this true?
SLIP does no error correcting. This is not a problem - IP doesn't do
and error correcting either. The big problem is that it doesn't do any
error detection either (whereas HDLC and Ethernet have 16 and 32 bit
CRCs). Now, IP does have a HEADER checksum, and both UDP and TCP are
SUPPOSED to checksum the data portion of the packets, there are cases
(NFS comes to mind) where this is not necessarily true. Furthermore the
IP/UCD/TCP checksum algorithm is not designed to detect the sorts of
errors that can occur over async data paths. This is not just an
accademic problem - real data has been corrupted over cnonections where
it looks like everthing was going fine.
I have used SLIP, but from a user standpoint a couple of years ago. It
wasn't the fastest when running RFS over it, but it was cheaper than
buying an ether- net board.
So in summary, is SLIP all that bad? Are there other relatively
standard methods of running TCP without sizable investments in hardware?
Slip isn't that bad, especially if you use the headercompressing, CRCing
CSLIP. It is not esthetically pleasing. Have you priced ethernet boards
recently? I see them advertised all the time for less than $150 (for PCs).
BillW
-------rob@lafayet.UUCP (Rob Freyder) (10/19/90)
In <12630877138.27.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: > However, it seems that everyone I ask about SLIP seems to speak ill of > it, and curiously mostly "heard that it's bad" not "used it and it was > bad." I hear comments about it being slow, but is it SLIP, or merely > the serial line? E.g., what does one expect off a 9.6k line? I did >errors that can occur over async data paths. This is not just an >accademic problem - real data has been corrupted over cnonections where >it looks like everthing was going fine. What if you want to connect two remote systems via Telebit T2500 in PEP mode ? Is this reasonable ? I am planning on using a regular voice line to do this. Is this at all common ? Is there a better way ? The sites will be running Open Desktop. Thanks for any suggestions or comments. Rob. -- Rob Freyder Core Laboratories a division of ____ ____ ____ Western Atlas International Inc. \ \ / /\ / /\ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- \ \/ / \ / / \ Humans (318) 235-9431 \ / / \ / /\ \ Internet rob@lafayet.UUCP \/___/ \/___/ \___\ Bang ...!uunet!lafayet!rob
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (10/20/90)
What if you want to connect two remote systems via Telebit T2500 in PEP
mode ? Is this reasonable ?
It's not unreasonably, but it won't work very well. PEP really
thrashes when used with SLIP or PPP. You will be much better off
using v.32 on the modems.
I am planning on using a regular voice line to do this.
Is this at all common ? Is there a better way ?
PPP provides better error detection. Remember that the voice line part
of the circuit is not the only place that errors can occur.
Personally, I'd run the telebits in SYNC mode, and use routers. Of course,
this isn't always ecconmically feasible.
BillW
-------BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (10/20/90)
PPP is really just HDLC asynchronous. A proper implementation is
complex, and can be a real CPU hog. Were I to write from scratch, I'd
need about 6 weeks, and I'm an HDLC expert. Present PD versions are
little more than toys; I don't know who/when someone is going to write
a better version that they are willing to give away. (Pyramid's
version, if done at all, would be based on priority HDLC code that we
already have.)
I don't think you understand PPP. It uses HDLC framing, but does not have
a lot of the other baggage that goes along with HDLC. (In particular, it
does NOT do retransmission or assure reliable delivery.) A simple
implementation of PPP (direct SLIP replacement - eg ignore most of the
option negotiation) should take considerably less than 6 man-months.
It should not be that much of a CPU hog, either - the time spent doing
the CRC is software (for async) is easilly outweighed by the interrupt
processing overhead...
BillW
-------csg@able (Carl S. Gutekunst) (10/20/90)
In article <966@lafayet.UUCP> rob@lafayet.UUCP (Rob Freyder) writes: >What if you want to connect two remote systems via Telebit T2500 in PEP >mode ? Is this reasonable ? Reasonable, sure. Usable? Yes for SMTP, NNTP, and FTP; no for telnet. The PEP turnarouns kill performance on any interactive session. Better to use V.32. <csg>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/21/90)
In article <966@lafayet.UUCP>, rob@lafayet.UUCP (Rob Freyder) writes: > What if you want to connect two remote systems via Telebit T2500 in PEP > mode ? Is this reasonable ? SLIP/PEP works fine for FTP, giving ~1000 Bytes/second transfer rates, but less than the 1400 Bytes/sec. you can get with a pair of PEP modems doing UUCP. Vanillia SLIP/PEP is almost useless for interactive TCP work, because the line turn around time caused by 41 byte headers (1 for SLIP, 40 for TCP/IP) in front of every data packet makes response far from crisp. Compressed-SLIP/PEP, is almost indistinquishable from dumb terminal use over PEP. I find it usable. Many people find the 0.02 to 0.14 second delays from the PEP line turn-arounds objectionable, with compressed-SLIP or remote terminals. For interactive use, SLIP or not, the v.32 mode of T2500's (and others) is probably better, even if the file transfer rate for FTP/SLIP/v.32 is <960 Bytes/sec. Vernon Schryver, vjs@sgi.com
bill@polygen.uucp (Bill Poitras) (10/21/90)
In article <12630877138.27.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: >SLIP does no error correcting. But it would help to use an error correcting modem.
bob@MorningStar.Com (Bob Sutterfield) (10/22/90)
In article <72778@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: In article <966@lafayet.UUCP>, rob@lafayet.UUCP (Rob Freyder) writes: What if you want to connect two remote systems via Telebit T2500 in PEP mode ? Is this reasonable ? SLIP/PEP works fine for FTP, giving ~1000 Bytes/second transfer rates, but less than the 1400 Bytes/sec. you can get with a pair of PEP modems doing UUCP. PPP (with compressed headers) gives 1.3-1.5Kb/sec FTP throughput over a PEP connection, which is getting close to the advertised bandwidth. I've forgotten whether that's with in-modem compression turned on, but I suspect not. For interactive use, SLIP or not, the v.32 mode of T2500's (and others) is probably better, even if the file transfer rate for FTP/SLIP/v.32 is <960 Bytes/sec. ...if you're able to maintain a V.32 carrier over a particular call. There are some places where PEP will get only 3-400 bps for UUCP or Xmodem, but nobody complains because nothing else will even latch a carrier because of the rotten lines. Probably not as much of a problem in the industrialized world as around the Indian Ocean.
lan@cup.portal.com (Los Altos Networks) (10/26/90)
After working with TCP/SLIP, TCP/CSLIP, and PPP for over
a year, here is what I see as the answer to serial IP
internetworking:
LOS ALTOS NETWORKS IS PLEASED TO PRESENT THE FOLLOWING
NEW PRODUCTS INFORMATION:
T E L E B I T N E W S R E L E A S E
TELEBIT ANNOUNCES DIAL-UP INTERNETWORKING
NetBlazer(tm) is the first in a family of products
SUNNYVALE, Calif., INTEROP '90, October 8, 1990 -- Telebit Corporation,
pioneer of the high-speed dial-up modem, introduced today the industry's
first automated dial-up TCP/IP router. The NetBlazer(tm) integrated
communications server is the first product to use modems and the public
switched telephone network (PSTN) to automatically provide virtual wide
area networking for TCP/lP-based ethernets. By automating the modems'
connection establishment, the NetBlazer offers seamless wide area network
connections between diverse computers and/or local area networks (LANs).
In addition to its virtual routing functions, NetBlazer also integrates
traditional terminal server capabilities, LAN-based modem sharing, a 56K
bps leased line connection, dial back-up, and ethernet to ethernet routing
functions, all in a single product.
The introduction of the NetBIazer represents the next major step in
Telebit's strategic diversification and fuels the new dial-up
internetworking marketplace.
NetBlazer Answers Customers' Demands
Prior to NetBlazer, expanding networks was a time consuming and costly
process due to technical obstacles. NetBlazer, however, represents the
marriage of the power of internetworking to the flexibility of the PSTN.
As a result, the enterprise wide network has greatly increased flexibility
because the PSTN offers immediate, low-cost, on-demand access. NetBlazer
enables an organization to expand its network to any location in the world
where there is a public telephone system. This flexibility creates a number
of applications including telecommuting, which is the ability of NetBlazer
to bring the network into the users' home, allowing them to become a node
on the network using their personal computer or workstation in combination
with a modem. Yet another application is the ability to cost effectively
connect remote sites on the PSTN as opposed to incurring the expense of a
leased line. This, for example, enables large companies to tie thir
smaller offices together in a virtual wide area network.
"We chose to begin with support for TCP/IP and Ethernet because our
customers asked for a product that combines open systems standards in high-
speed modems with today's most widely installed open system networking
protocols, TCP/IP, and media, Ethernet. NetBlazer's open architecture will
allow support for other networking protocols and media as the market
demands," said Michael Ballard, Director of Telebit's Network Systes unit.
Cost Effectiveness is Major Benefit to Customers
NetBlazer is a cost-effective wide area networking tool with combined
functionality that offers numerous additional features to the end-user.
Some of these include three levels of security, multi-vendor connectivity,
and on-board SNMP network management software. "Our aim with this new dial-
up internetworking product is to provide the customer with more solutions
within a single product (NetBlazer), easing the expense and technical
obstacles associated with using different devices to provide these
communications services," said Ballard.
Telebit is introduced NetBlazer at Interop '90, a major conference and
exhibition for the internetworking industry.
Prices for the NetBlazer begin at $2,995, not including modem(s), and increase
depending on the configuration. The product includes a one-year warranty on
parts and labor. NetBlazer will be avaiiable by the end of November 1990.
Telebit Corporation designs, manufactures and markets advanced high-speed
products for dial-up networking and wide-area communications. The company's
proprietary digital signal processing technologies provide extremely
reliable error-free communications across the worldwide switched telephone
network. Telebit markets its products worldwide through distributors,
original equipment manufacturers and value-added resellers.
Located in Sunnyvale, California, Telebit is a publicly held corporation and
is traded on the National Association of Security Dealers Automated
Quotations (NASDAQ) OTC market under the symbol TBIT.
###
Telebit and NetBlazer are registered trademarks or credits of Telebit
Corporation. Other trademarks or credits used are those of their respective
holders.
LOS ALTOS NETWORKS IS AN AUTHORIZED AND STOCKING TELEBIT
VALUE-ADDED DISTRIBUTOR PROVIDING UNIX DATA COMMUNICATIONS
PRODUCTS AND SERVICES.
FOR MORE INFORMATION ON THIS AND ALL TELEBIT PRODUCTS, PLEASE
CALL 1-415-941-8031.
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \|| \\|
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
NTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================sloan@cis.uab.edu (Kenneth Sloan) (10/26/90)
Bob- The sealed move was 42. Re8, and the game was drawn (before continuing, I think). Re8 is marginally better than Rd8 (Qc7 doesn't force liquidation), but apparently there is nothing in the position. I predict a quiet draw today (save this message so you can embarrass me tomorrow a.m.)! -Ken
sloan@cis.uab.edu (Kenneth Sloan) (10/26/90)
Oops - sorry! -Ken Sloan