🚀 go-pugleaf

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.

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

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

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.

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

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

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

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.

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.

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