[comp.protocols.tcp-ip] Using SLIP to link two ethernets?

randy@DBNET.CS.WASHINGTON.EDU (William Randy Day) (05/15/87)

Imagine two ethernets separted by several miles. The hosts on both subnets
are speaking TCP/IP. Has anyone given any thought to using SLIP and a
dedicated phone line to link the two subnets? How easy would this be
to cobble together?

Randy Day.
ARPA: randy@dbnet.cs.washington.edu
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy
CSNET: randy%washington@relay.cs.net

PAP4@AI.AI.MIT.EDU.UUCP (05/17/87)

I was wondering: why use SLIP?  There are superior protocols that have
a very useable number of implementations.  Yes, SLIP does run on just
about any asynchronous port, but if you are really serious about this
connection, there is hardware that is better suited for passing packets.

I suggest a board that has BISYNC or SDLC/HDLC.  The advantages are:

	You don't have to worry about escaping framing characters
	(the hardware does this for you)

	The CPU gets an interrupt per packet, instead of per character
	(big win on a machine with poor interrupt latency, like a VAX)

	You can run at higher speeds with synchronous modems than you
	can with asynchronous modems given the same phone line

	Packets are framed and checksummed; added reliability

It depends on your host, of course.  But most minis and mainframes
have this sort of serial interface option.  Even PC's have boards
that can do this...

With appropriate software, you can run IP encapsulated in X.25 on
an HDLC interface as well, though not everyone considers this a win.
I believe the IMPs (excuse me, PSNs) can use HDLC for HOST/PSN
communication too, when they are geographically separated.

Oh well, just thinking out loud...  Hope this helps.

-Philip

rick@SEISMO.CSS.GOV.UUCP (05/17/87)

The reason SLIP is popular is that it doesn't cost anything
(except maybe CPU cycles). You don't have to buy an external
board, you don't have to buy the software.

In most cases it is almost as good as a dedicated board.

---rick

roy@phri.UUCP (Roy Smith) (05/18/87)

In article <201108.870516.PAP4@AI.AI.MIT.EDU> PAP4@AI.AI.MIT.EDU ("Philip
A. Prindeville") writes:
> I was wondering: why use SLIP?

	We are considering setting up a SLIP connection.  There is a spare
9600 bps STAT-MUX channel on a 56 kbps leased line connecting the two
locations we want to link that we can get access to for free.  We would
love to run sync IP on something like DMR's but even if we could convince
the bean counters to buy the DMR's and lease a private line, we can't run
sync through the MUX.  It's either take the free asynch channel or nothing.
Nowitz and Lesk had the right idea so many years ago when they got UUCP
going -- it's a lot easier to start a network if it doesn't involve
up-front expenditures for hardware.  SLIP may not be as good as "real" IP
on a synch line with smart DMA controllers, but it's a lot better than
dial-up UUCP, and the hardware cost is a lot closer to the latter than the
former.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

Mills@UDEL.EDU.UUCP (05/21/87)

Roy,

Some years ago Ford Scientific Research Labs had a 14-kbps stat mux running
between Dearborn and London, with a DDCMP link between two TCP/IP-speakers
embedded in the trash. Be advised the stupendous delay dispersion introduced
by the stat-mux protocol does nasty things to the TCP retransmissio-timeout
estimation algorithm. There is in fact a data point described in RFC-889
involving that link. A skeptic might conclude it can't be done, then misght
be pleasantly surprised when it almost works, and come away with a new
respect for TCP robustness.

Dave