Index Journeys
RFC 38 UNKNOWN FEEDBACK · HISTORY

Comments on Network Protocol from NWG/RFC #36

Comments on the proposed ARPANET host-to-host protocol protocol multiplexing problem.

On rfc-editor.org ↗
PUBLISHED
March 1970
AUTHORS
S.M. Wolfe
STREAM
Legacy
CATEGORY
Informational
COMMENT ON
RFC 36
DOI
10.17487/RFC0038

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
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 ]

AI ELI5

On this page
PROBLEMRFC 36 proposed a host-to-host protocol that did not allow multiple connections to share the same network link, which could waste network resources.
MECHANISMStephen Wolfe from UCLA CCN points out two scenarios where link multiplexing would be valuable: when a single user has multiple high-speed file transfers, and when networks want to interconnect over limited links. He proposes that the protocol include socket numbers in control messages and message headers so that multiple connections can share a link.
HISTORICAL COMMENTThis feedback influenced the evolution of early ARPANET protocols. It is now purely historical.

§1The Multiplexing Problem

RFC 38 is a brief technical comment on RFC 36's proposed protocol. The core observation is that the protocol restricts each connection to one link, preventing multiple connections from sharing the same communication link. Wolfe argues this creates a resource bottleneck: a user with several high-speed transfers could monopolize many links, and when two independent networks connect via the ARPANET, a shortage of links could occur.

If every message needs its own private road to travel on, you run out of roads fast. Better to let many messages share the same road.

§2Proposed Solutions

Wolfe proposes three changes to enable multiplexing. First, the END and RDY (ready) control messages should specify socket numbers in addition to the link number, allowing the receiver to identify which connection a message belongs to. Second, the protocol should clarify whether flow control (RSM, SPD commands) applies to the whole link or to a single connection. Third, the destination socket should appear in the header of each data message on the link, in a field immediately following the header.

Each message should say not just which road it is on, but which car it belongs to. That way the receiving computer can sort messages from different conversations.

§3Significance for Future Protocol Design

Wolfe emphasizes that multiplexing need not be implemented immediately, but the protocol should be designed to allow it in the future. This forward-thinking approach meant reserving space for socket identifiers in control messages and data headers without requiring implementations to use multiplexing right away. The comment reflects early recognition of a fundamental networking principle: as networks grow, the ability to share resources becomes critical.

Wolfe is saying, 'You do not have to use multiplexing now, but leave room for it later in case we need it.' This turned out to be very wise.

§4References

[RFC36]RFC 36Crocker, S., "Protocol Notes", RFC 36, March 1970.March 1970