RFC 928 (rfc928) - Page 2 of 21

Introduction to proposed DoD standard H-FP

RFC 928                                                    December 1984
Introduction to H-FP


   NCP and do it outboard: the only thing that really matters in the
   Host is associating sockets with processes, and if we had common
   implementations of all the bit-diddling stuff in the IMPs, we
   wouldn't have disputes over the interpretation of the spec and we'd
   also save a lot of Host CPU cycles!"

   As far as the author knows, that incident was the beginning of what
   came to be called "Network Front-Ends" and, more recently, "Outboard
   Processing Environments."  (The name change, by the way, was
   motivated by a desire to prevent further confusion between NETWORK
   Front Ends--always conceived of as distributed processing mechanisms
   for the offloading of intercomputer networking protocols from
   Hosts--and traditional communications front-ends, which have no
   connotation of bearing protocol interpreters invokable by Host-side
   programs.)  At least, the idea was original to him and he later was a
   principal designer and the primary author of the first Host-Front End
   Protocol.  So, on the one hand, the present document might be marred
   for some readers by undertones of parental pride, but on the other
   hand, if you like primary sources....

   The evolution of the outboard processing idea has been dealt with
   elsewhere [1]. For present purposes, it should suffice to observe
   that some half-a-dozen implementors of "NFE's" of various sorts are
   known to the author to have met with success.  The topic of why use
   an explicit protocol in the first place (as opposed to emulating a
   device, or devices, already known to the Host/operating system)
   deserves a word or two here, however.  ([2] deals with it in more
   general terms.)  The crucial consideration is that in the general
   case you wind up "not doing real networking" if you attach a Host to
   a network by known device emulation, where real networking is taken
   to mean what has been called "resource sharing" in the ARPANET
   literature, and what appears to be dubbed "open system
   interconnection" in the ISO literature: Operating systems' built-in
   assumptions about known devices--whether terminals, terminal
   controllers, or RJE stations--tend to get in the way of the sort of
   process-process and eventually procedure-procedure communications
   that serve as the basis for applications more interesting than simple
   remote login.  To those unfamiliar with the outboard processing
   approach, the premise that the way to attach is via an explicit
   protocol may be difficult to accept, but to those who have done it,
   it makes almost perfect sense.

   To those, by the way, who have worked in intercomputer networking
   from the perspective of inboard (Host-side) implementations of
   protocol suites, the outboard processing idea often seems to lead to
   less than optimal results, especially as to maximizing throughput.
   And it is difficult to argue that if a given Host were well and truly


Padlipsky