REM%IMSSS@SAIL.STANFORD.EDU (Robert Elton Maas) (06/22/87)
<RE> Date: 20 Jun 87 18:05:26 GMT
<RE> From: munnari!kre@seismo.css.gov (Robert Elz)
<RE> Subject: Re: OSI-model software
<RE> To: protocols@RUTGERS.EDU
<RE> Incidentally, the x.25 nets that charge by segments (and time) are
<RE> generally much cheaper than the odd one that charges by octets, as
<RE> long as you're rational in your use of the resources .. if you send
<RE> 1 character packets, you lose big, but so you should, those things
<RE> (on any network) are very wasteful of resources.
Why are you assuming any user would send 1-character packets by
choice? With packets used across each link, with all data in the
packets disassembled at each node and reassembled into new packets
according to which next-hop they will use, there's no need to force
each user's data into its own packet. Rather multiple users can share
packets, so that fourty users each sending one byte of data need
consume only one packet of eighty bytes (40 bytes telling which
logical stream the data is on, and 40 corresponding bytes of user
data). Then the charge for a user sending single isolated bytes of
data is at worst twice the cost sending the same total number of bytes
in a long burst. This mode of packet-sharing allows interactive use
(press one key or a few keys and see the response) instead of forcing
users into batch mode (type ahead many many commands which are
buffered locally, then issue a SEND keystroke to pack them all into a
segment which corresponds to one or a few packets).
Of course you can't do packet switching with this method, you have to
allocate a stream over a fixed route and send all your data over that
route until you decide to close that route and establish another. But
"you" needn't be YOU, i.e. the network can automatically establish the
route, and automatically divert & resynch when a link along that route
goes down, and for military use a mode could be set where the send
route was different from the receive route and where each route was
automatically diverted & resynched at any pause in data or every so
many bytes whichever came first.
Encryption could be done end-to-end by XORing the key with the data,
but public-key cryptosystems wouldn't work well over this kind of
link, although public-key cryptosystems could be used at session-start
to pass the parameters of the randomly-selected XOR key sequence, so
it would still be possible to send messages which were effectively
public-key at the overall (gestalt) message level.
Rebuttal? Anything basically wrong with my idea? If my idea is ok,
then why all this assuming single-byte segments must be horrendously
expensive? For interactive editing remotely, a vast majority of the
data is host-to-user, which is bulk anyway, but there's no reason the
keystrokes of the user must cost more than twice the byte-rate of the
bulk, so there's no reason the cost of the keystrokes should be the
dominant cost of interactive service.
P.S. I believe packet switching is a poor choice for two major reasons:
(1) Immense overhead per segment, precluding interactive use.
(2) Lack of per-link error checking & retransmission in most
implementations, forcing end-to-end retransmission which screws up
interactive use terribly.
Packet-link with per-hop reassembly of logical-stream data avoids
these problems.