Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!PURDUE.EDU!narten
From: narten@PURDUE.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Tcp/Ip vs a store & forward network
Message-ID: <8703300117.AA15165@gwen.cs.purdue.edu>
Date: Sun, 29-Mar-87 20:16:58 EST
Article-I.D.: gwen.8703300117.AA15165
Posted: Sun Mar 29 20:16:58 1987
Date-Received: Tue, 31-Mar-87 01:49:32 EST
References: <8703300006.AA19177@arthur.cs.purdue.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 22
Approved: tcp-ip@sri-nic.arpa

One big problem with S&F networks is the lack of end-to-end acks. Once you
drop a "transaction" (e.g. batch ftp or piece of mail) in the queue of
one of the intermediate nodes, it is out of your hands. You don't know
where it is, and you can't find out. How many times have you sent mail
into a black hole? It happens much more often in store and forward
networks than in the TCP world.

Based on my experience, when I send mail over TCP to a user, I feel
very confident that it gets to them. If the mail gets lost, its almost
always because the mail subsystem at the receiving site is messed up.
Sending mail through mail lists (which puts in an extra S&F hop) is
also pretty reliably, though not as much. On the other hand, when
mailing via one of the S&F networks, my confidence falls rapidly as
the number of hops increases.

You might argue that the reliability of S&F networks could be
improved. No matter how reliable you make them, you will still be left
with a system where everything you drop in disappears, and there is
no way of finding out where it is until it comes out at the other end
(if it does). Not too good when you just sent an important message.

Thomas