Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!BARILVM.BITNET!HANK
From: HANK@BARILVM.BITNET.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Tcp/Ip vs a store & forward network
Message-ID: <8703291921.AA12554@ucbvax.Berkeley.EDU>
Date: Sun, 29-Mar-87 08:48:42 EST
Article-I.D.: ucbvax.8703291921.AA12554
Posted: Sun Mar 29 08:48:42 1987
Date-Received: Sun, 29-Mar-87 23:46:36 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 39
Approved: tcp-ip@sri-nic.arpa

All the calculations about the bandwidth of a station wagon got me thinking.
Why was Tcp/Ip not designed as a store and forward network (in addition to
the protocols it does support)?  Let me explain why I am asking this.  In
Bitnet, you might have as many as 20 9.6Kb lines separating you from the
place you wish to send a file to.  The probably that all 20 lines are
working and that all 20 intermediate machines are up (yup - no IMPs)
simaltaneously becomes quite small.

(Imagine if the probability of any machine being up and working is 98% and
that the probablility that any leased phone line is working is 99.5% - after
10 machines - 77.7% successful connection).

Well you can say alternate paths and better reliability make the connection
rate closer to 95%.  I would perhaps doubt that when the two nodes are
separated by a number of physical links and that the data has to pass thru
a couple of hardware boxes that will not work if there is a power outage
in the building or other "things" that can cause a hardware box to not
respond.

So, a S&F network would alleviate much of the problem.  Try to get the data
as close to the destination node and then spool it.  Instead SMTP makes
a valiant attempt to emulate S&F by spooling the mail locally and occassionally
trying to establish a connection to the destination.  After 'n' of days
SMTP gives up and sends mail to the sender.  I think it would have been nicer
that SMTP try to get it as close to the down node as possible and then let
that node try polling the down node for 'n' number of days.

But FTP is even worse.  FTP is basically an interactive process.  You want
a file you gotta establish a connection and suck it off or slap it into place.
Transferring files should really be a batch orientated feat - you say what
file you want to store or retrieve and you type in all the necessary
options and parameters and you don't hear about it until it completes (with
appropriate return codes of course).

Bitnet uses BSMTP (Batch SMTP).  Is there such a thing as BFTP (Batch FTP)?
Is there a very strong technical reason why S&F was not part of the design
of Tcp/Ip??  I have a lot of questions but very few answers.

Hank