RFC 38

Comments on Network Protocol from NWG/RFC #36

πŸ“… published March 1970, from ietf

Comments on Network Protocol from NWG/RFC #36 ✨

Okay bestie, first the ID card πŸŽ€ This is RFC 38, filed to the Network Working Group by Stephen M. Wolfe of UCLA CCN, dated 20 March 1970. The original doesn't list a category or status, and it doesn't say it obsoletes or updates anything, so I'm not gonna make that up πŸ’…

Okay so the proposed protocol doesn't allow for multiplexing connections over links πŸ¦‹ Honestly that's fine for now, but it might cause loading problems in the future. Two cases where routing several connections over the same link is obvious:

  • a) Where a user has several high speed connections, like between processes that send files over the network. Putting those connections on the same link limits how much of the network's resources that user can use. This gets especially 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 want to let each other access the other hosts's network over the ARPA net, a shortage of links can develop. Again, putting several connections on the same link could help solve the problem. πŸ™ˆ

The following changes would make future use of multiplexed links possible 🌸 Adding the multiplexing itself to the protocol isn't necessary right now, though!

  • 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 ]

πŸ“¦ where this page comes from