Commentary on procedure calling as a network protocol
RFC 684

Document Type RFC - Unknown (April 1975; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 684 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group
RFC #684
NIC #32252
April 15,1975

    A Commentary on Procedure Calling as a Network Protocol

                        Richard Schantz



This RFC is being issued as a first step in an attempt to  stimulate
a dialog on some issues in designing a distributed computing system.
In particular, it considers the approach taken in a design set forth
in  RFC #674, commonly known as the "Procedure Call Protocol" (PCP).
In the present document, the concentration is on what we believe  to
be the shortcomings of such a design approach.

Note at the outset that this is not the first time we are  providing
a critical commentary on PCP.  During the earlier PCP design stages,
we met with the PCP designers for  a  brief  period,  and  suggested
several  changes,  many  of  which became part of PCP Version 2.  We
hasten to add, however, that the nature of  those  suggestions  stem
from  an entirely different point of view than those presented here.
Our original suggestions, and also some subsequent ones, were mainly
addressing  details  of implementation.  In this note the concern is
more with the concepts underlying the PCP design than with  the  PCP

This note is being  distributed  because  we  feel  that  it  raises
certain  issues  which  have not been adequately addressed yet.  The
PCP designers are to  be  congratulated  for  providing  a  detailed
written  description  of  their  ideas,  thereby  creating a natural
starting  point  for  a  discussion  of  distributed  system  design
concepts.  It is the intent of this note to stimulate an interaction
among individuals involved with distributed computing,  which  could
perhaps  result in systems whose designs don't preclude their use in
projects  other  than  the  one  for  which  they  were   originally

The ideas  expressed  in  this  RFC  have  benefited  from  numerous
discussions with Bob Thomas, BBN-TENEX, who shares the point of view

          A COMMENTARY on PROCEDURE CALLING         Page   2


     While the Procedure Call Protocol (PCP) and its use within  the
National  Software  Works (NSW) context attacks many of the problems
associated with integrating independent computing systems to  handle
a  distributed  computation,  it  is  our  feeling  that  its design
contains flaws which should prevent its widespread use, and  in  our
view,  limit  its overall utility.  We are not voicing our objection
to the use of PCP, in its current  definition,  as  the  base  level
implementation  vehicle for the NSW project.  It is already too late
for any such objection, and PCP may, in fact, be very effective  for
the  NSW  implementation,  since they are proceeding in parallel and
have probably influenced each other.   Rather,  we  are  voicing  an
objection  to  the  "PCP philosophy", in the hope of preventing this
type of protocol from becoming the  de-facto  network  standard  for
distributed  computation,  and in the hope of influencing the future
direction of this and similar efforts.

     Some of the objectionable aspects of PCP, it can be argued, are
differences  of  individual  preference, and philosophers have often
indicated that you cannot argue about  tastes.   We  have  tried  to
avoid  such  arguments in this document.  Rather, we consider PCP in
light  of  our  experience  in   developing   distributed   systems.
Considered  in  this  way,  we  feel  that  PCP  and  its underlying
philosophy have flaws which  make  it  inappropriate  as  a  general
purpose protocol and virtual programming system for the construction
of distributed software systems.  It is  our  opinion  that  PCP  is
probably  complete  in  the  sense that one can probably do anything
that is required using its primitives.  A key  issue  then,  is  not
whether this function or that function can be supported.  Rather, to
us an important question is how easy it is to do  the  things  which
experience has indicated are important to distributed computing.  In
addition, a programming discipline dedicated to network applications
should  pay  particular  attention  to  coercing its users away from
actions which systems programming in general and network programming
in particular have shown to be pitfalls in system implementation.

A Point of View_ _____ __ ____

     At the outset, we fully support the aspects of the  PCP  design
effort  that  have  gone  into  systematizing  the  interaction  and
agreements between distributed  elements  to  support  inter-machine
computing.   This  includes  the  definition of the various types of
replies, the  standardization  of  the  data  structure  format  for
inter-machine  exchange,  and  the process creation primitives which
extend the machine boundaries.  Such notions are basic and  must  be
part  of any distributed system definition.  Our main concern is not
with these efforts.

          A COMMENTARY on PROCEDURE CALLING         Page   3
Show full document text