Comments on Network Protocol from NWG/RFC #36
A comment proposing that several connections share one ARPANET link.
Wolfe, S.M., "Comments on Network Protocol from NWG/RFC #36", RFC 38, DOI 10.17487/RFC0038, March 1970, <https://www.rfc-editor.org/info/rfc38>.
@misc{rfc38,
series = {Request for Comments},
number = 38,
howpublished = {RFC 38},
publisher = {RFC Editor},
doi = {10.17487/RFC0038},
url = {https://www.rfc-editor.org/info/rfc38},
author = {S.M. Wolfe},
title = {{Comments on Network Protocol from NWG/RFC #36}},
pagetotal = 1,
year = 1970,
month = mar,
} RFC text
Network Working Group Stephen M. Wolfe
Request for Comments: 38 UCLA CCN
20 March 1970
Comments on Network Protocol
from NWG/RFC #36
The proposed protocol does not allow for the possible multiplexing of
connections over links.
Generally, this presents no problem, but it might cause loading
restrictions in the future. Two cases where routing multiple
connections over the same link are apparent:
a) Where a user has several high speed connections, such as
between processes that transmit files over the network.
Assigning these connections to the same link limits the
percentage of network resources that may be used by that
user. This becomes particularly important when several
store-and-forward IMP's are used by the network to effect
the communication.
b) When two hosts each have their own independent network and
desire to allow access to the other hosts's network over
the ARPA net, a shortage of links may develop. Again, the
assignment of several connections to the same link could
help solve the problem.
The following changes in the protocol would make possible the future
use of multiplexed links. It is not necessary to add the
multiplexing, itself, to the protocol at this time.
a) The END and RDY must specify relevant sockets in addition to
the link number. Only the local socket name need be
supplied.
b) Problems arise with the RSM and SPD commands. Should they
refer to an entire link, or just to a given connection?
Since there is a proposal to modify the RFNM to accommodate
these commands, it might be better to add another set of
commands to block and unblock a connection, but I am not
convinced that that is the best solution.
c) The destintation socket must be added to the header of each
message on the data link. Presumably this would consist of
32 bits immediately after the header and before the marking.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Karl Reinsch 1/97 ]
ISO Plain Language
On this page
§1Why Share a Link
Stephen Wolfe notes that RFC 36 does not allow multiple connections to share a link. He describes two cases where sharing could help: one user has several high-speed connections, or two hosts want to provide access to their separate networks over the ARPA Network.
In both cases, assigning several connections to one link could avoid a shortage of links.
Wolfe says one network link could carry several connections. He gives multiple high-speed transfers and links between separate networks as reasons this could be useful.
§2Changes to Identify Connections
Wolfe proposes that the END and RDY control messages include socket numbers as well as the link number. He also says the protocol needs to clarify whether the RSM and SPD commands control an entire link or one connection.
For data messages, he proposes adding the destination socket immediately after the header. The note describes a 32-bit field for that socket.
Control messages would identify the socket as well as the link. Data messages would also name the destination socket so the receiver can identify the connection.
§3A Future Option
The RFC says that multiplexing itself does not need to be added immediately. Instead, Wolfe recommends changing the protocol so that multiplexing can be used later.
The proposal is to make future link sharing possible without requiring it in the initial protocol.