Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!KA9Q.BELLCORE.COM!karn
From: karn@KA9Q.BELLCORE.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Tcp/Ip vs a store & forward network
Message-ID: <8703300458.AA02844@ka9q.bellcore.com>
Date: Sun, 29-Mar-87 23:58:42 EST
Article-I.D.: ka9q.8703300458.AA02844
Posted: Sun Mar 29 23:58:42 1987
Date-Received: Tue, 31-Mar-87 01:13:18 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 48
Approved: tcp-ip@sri-nic.arpa

Actually, I thought the Internet WAS a store-and-forward network. Gateways
store up packets as they are received and forward them after a queueing
delay.  I think you really meant "message switching" as opposed to "packet
switching".

But even this distinction is rather artificial.  One of the most popular
message switching networks is UUCP. Like the Internet, each UUCP node also
stores up a block of information, makes a routing decision (sometimes
specified in a source route) and sends it on its way.   The only real
differences are quantitative, i.e., the maximum allowable message size and
the typical end-to-end delivery delay, although admittedly they heavily
influence the way end-user nodes make use of the service.  You *could* run
TCP on top of UUCP (encapsulating one segment per message) as long as it is
prepared to deal with RTTs of several days.  On the other hand UDP
query-response applications use the Internet as though it were a message
switching network, since messages fit neatly into Internet datagrams.

Perhaps the only real qualitative distinction is whether the network is
useful for "real time" communications, however you define them. Nobody runs
SMTP/TCP/IP on UUCP because few are willing to wait several days for a TCP
3-way handshake to complete.  Instead UUCP mail consists of single, large,
self-contained "datagrams" with no end-to-end protocol other than the
implicit human-to-human one.  Of course this means you have no real
guarantee that the message will get there, so everyone puts in lots of
low-level reliability enhancing mechanisms.  I prefer SMTP across the
Internet over UUCP whenever available, not only because it's usually faster,
but because I *want* that end-to-end reliability provided by TCP.  Assuming
a fully connected Internet, I can feel pretty confident that if my mail
disappears from the spool then it has safely reached its destination and
isn't stuck in some unknown place halfway across the path.

I think the distinction between message and packet switching will blur
further as very high speed transmission facilities become available and RAMs
get even cheaper. You can allow very large packets on a high speed fiber
link without sacrificing "real time" performance. Chopping up a data stream
into tiny packets will no longer be necessary or even desirable: the packet
rate would get completely out of hand.  For example, if each packet could
hold an entire NTSC video frame, real time packet video would only be 30
packets per second, well within the capability of even a Z-80 as long as
data paths are kept separate.

An interesting project would be to see just how applications might make use
of "megapackets".  Interactive timesharing probably can't make use of much
more than a few K (a screenful of text) but clearly file transfers could use
much more. (Think of an entire magtape occupying a single packet.  At
gigabit rates it would still only take a second or so to transmit).

Phil