Tcp/Ip vs a store & forward network

Phil Karn (
Sun, 29 Mar 87 23:58:42 EST

self-contained "datagrams" with no end-to-end protocol other than the
mplicit 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).


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:46 GMT