Comments on Network Protocol from NWG/RFC #36

S.M. Wolfe

doi:10.17487/RFC0038

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC38

UNKNOWN

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 ]

[Page 1]

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.