The RFC Archive
 The RFC Archive   RFC 38   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 38

Comments on Network Protocol from NWG/RFC #36

Last modified on Thursday, March 13th, 1997

Permanent link to RFC 38
Search GitHub Wiki for RFC 38
Show other RFCs mentioning RFC 38







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 top


Comments on Network Protocol from NWG/RFC #36 RFC TOTAL SIZE: 2536 bytes PUBLICATION DATE: Thursday, March 13th, 1997 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 38: The IETF Trust, Thursday, March 13th, 1997
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement