CS 736 Reviews - Spring 2016

1. Summary
This paper discusses the design & implementation of an easy-to-use and efficient RPC mechanism for communication between application programs across a network.
The authors detail the various options they chose from while designing the RPC package and focuss on the binding mechanism along with the transport level communication protocol and several optimizations used. The authors then present the evaluation with basic measurements, which do not give detailed insights about their performance.

2. Problem
The primary problem authors wanted to solve in their work is to make distributed computation and application as easy as local procedure calls, so that it would be easy to write distributed applications. The authors also wanted to make RPC communication highly efficient and powerful so that the solution is accepted. They also wanted to make communications involved in RPCs is secure.

3. Contribution
The authors main idea in the work is to make design simple and based on the way local procedure calls operate.
The presented design has below novel contributions according to me:
a) Exported and imported interfaces and making use of auto generated stubs which hide out the innner implementation details of network communication. This allows RPC to have similar semantics as local procedure calls.
b) RPC binding which made system flexible by leveraging the inherent reliability of database and secure with the use of access controls.
c) Transport protocol tailored for RPC as existing protocols weren’t suitable for this scenario due to connection setup overheads. They optimized the protocol to avoid sending unnecessary acknowledgement packets when conclusions can be inferred by occurrence of specific events. As an example there is no connection establishment protocol, no communication overhead in maintaining idel connections and subsequent packets are used for implicit acknowledgement of previous packets. The protocol largely focused on making small calls efficient rather the long bulk data transfers.
d) Process swaps and stock of idle server processes to handle multiple clients.

4. Evaluation
The authors evaluated the performance of the implementation by making remote calls between 2 Dorado machines connected by Ethernet. They just reported the time it takes to make remote calls between the above two machines on a lightly loaded network which is then compared against the time as if it were a local procedure call. But, there is no adequate comparison between their proposed RPC mechanism with other contemporary communication systems to substantiate their claim that their proposed solution is more efficient. I feel the authors haven't justified how the custom packet level protocol would perform against the general purpose transfer protocols for complicated calls. Also the claim process swaps and idle server processes gives the needed efficiency in handling multiple clients doesn't have evaluation for it. Moreover the evaluation numbers are for single ethernet network, what about distributed internet networks, how does the latency and performance of RPC calls vary.

Confusion
The bulk data transfer, how would it impact the performance of RPC is not so clear to me. Also would be interesting to know about TCP/IP impact to this research.

1. summary
In this paper, authors describe the overall design of their Remote Procedure Call (RPC) mechanism. They describe the structure of RPC mechanism, binding procedure, transport level communication protocol along with performance measurements. The RPC mechanism is designed for enabling easy communication between programs distributed over a network through normal procedure calls at low costs and high performance.

2. Problem
The mechanism for RPC then only presented low level of abstractions that had several issues such as lack of semantics of a call in the presence of machine and communication failures, lack of binding (how a caller determines the location and identity of the callee), lack of suitable protocols for transfer of data and control between caller and callee and how to provide data integrity and security in an open networks. Their design of RPC addresses these issues.

3. Contributions
The overall contribution of this paper is that it designed and implemented RPC and demonstrated its effectiveness by addressing some of the major problems mentioned above. Here are their contributions:
* User-stub provides a easy way to invoke a procedure in a remote system that be plugged into any existing programs without the need of any modifications in the program.
* It is designed to resemble the local procedure calls and does not burden programmers with additional coding requirements.
* Lupine generates the communication code responsible for packing and unpacking arguments and results and hides the details and complications from users / programmers.
* Use of grapevine database to solve the problem of discovering callee and available interfaces. It also allows the use of access controls to handle security.
* Exception handling mechanism and crash recoverability using UID.
* A packet-level transport protocol for RPC the removes the handshakes and other overheads.

4. Evaluation
The authors evaluate their system using measurements of use of RPC packages for remote calls between two Dorados running Cedar and connected by an Ethernet with a raw data rate of 2.94 Mbps and on a lightly loaded network. They report the min, median and transportation latency for arguments of various length and compare that with latency for local procedure call. This evaluation provides readers an idea of overheads of RPC and latency tradeoffs.
However the authors do not thoroughly evaluate some of the claims they make. For e.g. it was only tested on a lightly loaded network that does not provide readers any information on how this system behaves when the network is congested and packets are dropped (since it does not have timeout mechanism). This evaluation mechanism also does not provide any detail on the nature of applications used. How does the exception handling work and what the overheads are on a complex distributed application? Some evaluation and analysis of overheads of moving from local procedure calls to the remote procedure calls would also have solidified authors claims.

5. Confusion
How does it work when it has to return a more complex data, with pointers inside? Since it does not support any shared addresses it is not clear how this design handles passing of a complex data structure.
It is also not clear how it proceeds when the server crashes or deadlocks since there is no timeout.

1. Summary
This paper describes the design and implementation of a remote procedure call framework that emulates local procedure calls as closely as possible, uses stubs to provide the calling interface, and includes its own packet-level transport protocol.
2. Problem
At the time that the paper was written, even expert systems researchers found it very hard to write distributed systems, since the knowledge needed was so specialized. Many remote procedure call systems had been designed, but very few had been implemented, and those that had been implemented were generally inefficient.
3. Contributions
The paper contributes a remote procedure call interface that emulates local procedure calls as closely as possible. It uses stubs which handle the transmission of data and provide an interface so that the caller calls a local procedure (with the same signature as the remote procedure) and the callee is called by a local procedure. These stubs are generated from interface modules that specify the method signatures and group them into interfaces, such as the interface for a mail server. This generator refuses to generate stubs for any signature that uses arguments that would be in shared memory since no memory is shared between the user and the server. The generator is actually the largest code in the program.
To perform binding, the connection of a user machine with the procedure on a remote machine, the implementation uses a distributed database, which contains information about which interfaces can be called on which machines, called instances. Entries are added to the database by users when they call remote procedures and by servers at initialization. Users must specify an can optionally specify a particular instance on which the remote procedure must run: if this is unspecified, the system finds a suitable server.
The paper also contributes a new packet-level transport protocol which avoids using explicit acknowledgements as much as possible, instead understanding further packets as acknowledgments of previous ones. This protocol also uses call identifiers to avoid confusion from duplicate call packets and to ensure that packets are correctly interpreted.
4. Evaluation
The evaluation of this paper seems fairly poor. While the paper gives metrics calling procedures which vary in their number of arguments and some of which use arrays, they give no tests of any applications, much less commonly-used applications. (Admittedly, remote procedure calls were new enough that no commonly-used applications really existed.) While they compare to local procedure calls, they compare to no distributed-communication systems. Also, they claim that "[The semantics] were easy and efficient to implement," but do not give even anecdotal evidence for this, with the possible exception of code sizes. Their evaluation was somewhat suitable for research work, but did not indicate that these techniques would be practically useful.
5. Confusion
I was somewhat confused by how the connection identifier was initialized, seemingly from the current time.

1. Summary
The paper presents the design and implementation of Remote Procedure Calls for providing communication between programs in high level language through the network. The authors explain the overall structure of their RPC design, handling of binding, transport layer communication mechanism and some optimizations to achieve high performance.

2. Problem
Construction of programs communicating with each other across a distributed setting was not an easy task as there were no tools and mechanisms to abstract out communication logic from the program. A communication mechanism was needed to be implemented as part of the distributed application. The main problem the authors wish to resolve was to provide an efficient and lightweight communication mechanism across various processes by simply extending the semantics of procedures in programming languages for the remote setting.

3. Contributions
The authors explain the various options they encounter while designing the RPC package and explain the decisions they made. The program structure of RPC was based on the concept of stubs. For communication between the user and server process, user-stub RPCRuntime package and the server stubs are also involved with the user stub packages the procedure call parameters to RPCRuntime which forwards it to server-stub which passes it to the server for execution and returns the result to user similarly. With this contribution, the programmer does not need to write communication related code as the stubs are generated by the compiler. The problem of binding is addressed using the notion of RNames in the Grapevine which is a distributed database containing information about processes importing and exporting interfaces for binding. Grapevine is also used in the RPC mechanism for implementing a secure protocol when a client wishes to bind to the server. Another contribution was the packet-level transport layer protocol which had a low cost for setting up and tearing down connections, and do not require low maintenance of state information, which allows the RPC mechanism to serve substantial number of clients. The authors also talk about the modified protocol in the case when procedure has large size of arguments, requiring multiple packets to be sent through the network, and have added support for exception handling.

4. Evaluation
The evaluation experiment was performed by executing procedures with varying size of arguments and results and measuring the minimum time, median time, transmission time and local-procedure time for each of the instance. However the experiment was only performed on a very lightly loaded network. They authors do not provide the performance for a busy/congested network setting and also in the setting where many clients are connecting to a given server for execution of procedure. This would have tested the efficiency and light-weightedness of the RPC mechanism which the authors claim.

5. Confusion
Some explanation on the binding mechanism done using Grapevine.

1) Summary : The paper proposes Remote Procedure Calls(RPC) to be an important paradigm for providing communication in a distributed system. It deals with the challenges the designers faced, the decisions they opted, the overall structure of RPC, the facilities for binding RPC, the transport level communication protocol, few performance evaluations comparing it with local procedure calls and few optimizations such as minimizing load on server to maximize performance.

2) Problem : The idea of RPC and distributed computing had been present for a considerable amount of time. However there lacked a concrete implementation and use of RPC owing to the inherent complexities in the communication mechanisms, timing, failure of components and coexistence of independent execution environments. The authors hence strive to design RPC that was transparent, efficient, had powerful semantics, secure communication to make distributed computation easy and to leverage the very large,very powerful network, numerous powerful computers and environment to build programs easy.

3) Contribution : The primary goal of the authors was to design RPC and demonstrate the possibility of distributed computing using RPC to encourage further research in this area. Hence they strived to present to the application programmer semantics very similar to local procedure calls to enable wide scale adoption. The general flow of their design is as follows: a]when an RPC is caller/user->user stub-> RPCRuntime->network transmission->RPCRuntime->server_stub->server/callee and response propagated back in the reverse path. b]Lupine create the stubs that are responsible for packing and unpacking the parameters at client and server side. c]RPCRuntime transfers packets reliably over the network.d]User is needed to know only the interface imported at client and exported at server. e]binding on an importer to exporter by an interface{type + instance}. f]Grapevine a central database that serves as a lookup table containing 2 types of entries-individual{interface instance, network address} and group{interface type, list of instance}. an instance is entered in the DB when it is exported with its machine address. g]packet level transport protocol involves a call ID{machine number, process ID, sequence number} and activity{machine number and process ID}, each activity ensures only one outstanding request at a time, sequence numbers used to handle duplicates, no ACK is sent for short packets(response packets denote reliable communication), complicated packets involve ACK, RPCRuntime retransmits of ACK is lost. h]Security is ensured via encryption details of which are presented in a following paper.
Having seen the above contributions in their design few assumptions and optimizations that I feel are a good design choices are: a]to have RPCRuntime protocol over conventional TCP that saved time involving extensive handshaking mechanisms. b]Access control taken care by Grapevine’c lists and caller ids thereby freeing the server side the burden of memory to store this additional data. c]short probe packets and the time gaps between each probe packet is increased exponentially, this reduces overhead compared to the scenario of have to retransmit packets every time to monitor server side status.d]Exception handling via a special exception packet instead of a response packet. e]processes to service requests at server side are initially attempted to be served by picking one of the appropriate interface in a free list before creating one, this reduces the overhead of process creation.

4) Evaluation : The authors present measured performance results(in terms of time taken for a RPC to complete) of their implementation on a light load network comparing it with local calls by varying the size of data sent across(different number of arguments). Local calls as expected take very less time compared to RPC. The drawbacks inherent in the evaluation is that it is bound to degrade to a further extent when done in a loaded network. By comparing times it is evident that most of the time is spent in marshaling and unmarshalling at caller and caller end. Knowing that this was the first of a kind attempts to demonstrate the plausibility of RPC it is encouraging to know that this time can be further optimized by better processing techniques. It would be interesting to look into performance evaluations taking into consideration encryption, large number of server and clients leading to increased Grapevine DB size and server load.

5) Confusion : How are component failures or system crashes handled ? Caller deems callee alive even when server side is deadlocked, how is this situation handled to exit deadlock?

1. Summary
This paper describes a package providing RPC facility. The authors also give details regarding the various options they had to choose from while designing the aforementioned package and the rationale behind their decisions. They focus on the binding mechanism along with the transport level communication protocol designed by them and the various optimizations used. The authors go on to evaluate the performance of their proposed package with some basic measurements, which do not give detailed insights about their performance.
2. Problem
The main purpose of this work was to make distributed computation and application as easy as local procedure calls, so that people would be encouraged to venture in the domain of distributed application development. The authors also wanted to make RPC communication highly efficient and powerful so that application developers do not avoid working in this area. Lastly, they also wanted to ensure that the communications involved in RPCs is secure. However, this is not the focus of this paper.
3. Contribution
The authors made it a point to ensure that their design was simple and based on how local procedure calls operate. I believe that this was one of the key reasons why their proposed idea was widely accepted. The authors build on the RPC structure that was proposed in Nelson’s thesis (also a co-author). The proposed design of the RPC involved 5 pieces – user, user-stub, RPCRuntime, server-stub and server. According to me, this approach was a winner because the developer just had to implement the user and server pieces. The stubs were automatically generated using Lupine and were responsible for the packing and unpacking of the data whereas the RPCRuntime is responsible for packet-level communication. Another interesting feature was the use of Grapevine for RPC binding. Reason being, this made the entire system more flexible (by leveraging the inherent reliability of the database) and secure via the use of access control. The authors also decided to design and implement their own transport protocol for RPC, as existing protocols weren’t apt for this scenario due to the connection setup overheads. However, their protocol design was largely focused on making simple small calls efficient rather than long bulk data transfers. The authors ensured that long bulk transfers was made viable by multiplexing the data between several processes and also introduced another optimization by reusing processed whenever possible. Overall, their design seems to be acceptable. However, with no talk about congestion avoidance in the network, I feel they miss out exploring the problems that could arise due to the aggressive retransmission strategy adopted by them.
4. Evaluation
The authors evaluate the performance of their package by making remote calls between 2 Dorado machines connected by Ethernet. One of the key takeaways from their evaluation was that bulk data transfers are not very efficiently done by RPCs. I believe that the authors could have carried out a more systematic performance evaluation. From the results presented, one cannot know what is the main cause of overhead in RPCs. It seems that the transmission delay isn’t the main source of overhead, which is quite surprising. It would have been ideal to measure the amount of time spent in each of the 5 pieces. Another aspect missing from their evaluation was that they did not compare their specialized transport protocol with the existing protocols. A comparison would have verified the claims made by the authors with respect to their proposed solution. Lastly, it would have also made sense to try other alternatives to Grapevine and evaluate the performance of the system.
5. Confusion
It seems like the authors advocated for an aggressive retransmission strategy. However, wouldn’t this be a cause of concern since it could lead to congestion in networks?

Summary
This paper talks about the design and implementation of a simple, easy-to-use and efficient RPC mechanism for communication between application programs across a network.

Problem
At the time this paper was published, RPC as a communication mechanism on a distributed network was known to the researchers. But, there was almost no full-scale practical implementation of a RPC system that would allow someone to easily write a distributed application. So, the primary problem that the authors wanted to solve was to reduce this barrier to writing distributed application, by abstracting much of the nitty-gritty details. And to make their solution acceptable, the authors also wanted to ensure that their proposed RPC mechanism would be efficient and secure.

Contributions
According to me, the following are the novel contributions of this paper:
(1) The idea of exported & imported interfaces and the use of auto-generated stubs that abstract away the inner implementation details of network communication. This allows a remote procedure call to provide similar semantics like a local procedure call.
(2) The binding mechanism, coupled with the concept of types and instances, that allows a caller to easily discover and invoke remote procedures on a callee.
(3) A novel packet-level transport protocol that is tailored for RPC. Wherever possible, the authors have optimized the communication protocol to avoid sending unnecessary acknowledgement packets, when certain conclusions can be directly inferred by occurrence of specific events. For example, there is no connection establishment protocol, no communication overhead in maintaining idle connections and subsequent packets are used for implicit acknowledgement of previous packets.
(4) Use of process swaps instead of process creation and a stock of idle server processes to transparently handle multiple callers (clients).

Evaluation
Even though the ideas discussed in the paper are quite novel, simple and powerful, I felt that the evaluation presented by the authors is not so strong. The authors have just reported the time it takes to execute a remote procedure call between two Dorados connected on a lightly loaded network. This is then just compared against the time it would take, if it were a local procedure call. But, there is no adequate comparison between their proposed RPC mechanism with other contemporary communication systems to substantiate their claim that their proposed solution is more efficient.
The authors claim that their own protocol is what dictates much of the performance of their proposed solution. But, the authors are inconclusive in justifying that their custom packet-level transport would perform still better than any other general purpose transport protocols for “complicated calls”. Again, the authors have claimed that process swaps and maintaining a pool of server processes gives the much needed efficiency in handling multiple client calls at once. But, no evaluation is presented for this case.
Additionally, their evaluation numbers are for the communication that only occurs in a single Ethernet network. At least, an evaluation on a distributed internetwork would have given more insights as to how much internetwork transmission latency varies and affects the overall performance of an RPC call.

Confusion
In the paper, the authors have expressed their skepticism to replace their packet protocol with something more general purpose that could adapt to both bulk data transfer as well as RPC. I am curious as to how TCP/IP, which was being developed around the same time, might have affected research in this direction.

1. Summary
The authors use Dorado machine to implement a clean, simple, efficient and generic semantics in the form of Remote Procedure Call (RPC) for communication across distributed system in the Cedar project. The article discusses design, implementation and evaluation of RPC mechanism to make it easily adoptable and secure. They suggest some optimizations on top of the existing work on RPC to achieve performance gain, scalability and low cost of setting up the communication.

2. Problem
For computation across systems: having powerful semantics of a procedure call in case of systems or communication failures, handling address-containing data structures in the absence of shared memory, remote call integration, binding mechanism and protocol of transfer of data and control was vital. There was a need to provide data integrity and security. This did not exist then and the authors attempted to solve this building an RPC package.

3. Contributions
RPC package having type and instance for each procedure accessible via User machine, Server machine with local tables maintaining procedure indices, Grapevine database containing individual/group RNames provides access controls on export of particular interface - they all comprise of the network components. An RPC flow that tries to replicate a local procedure call, involves: User program->User-stub->RPCRuntime(User)->RPCRuntime(Server)->Server-stub->Server procedure for an activity to accept the request.
The packet level communication provider - RPCRuntime was responsible for providing reliable and efficient transmission of message across systems, passing the arguments and results between the callee and caller and enforcing network protection and security by the use of unique identifiers (that are well crafted for detecting server crashes since they are used with each calls) for the procedures that were exported. Lupine made stubs using Mesa interface modules that helped provide details of the procedures supported, code unmarshalling and marshalling. This is equivalent to having an interface header file between two processors working in different power domains that specify the exact format of arguments accepted and results obtained. Primary optimizations were implicit acknowledgement of previous packets, minimizing the cost of connection maintenance, avoid cost for establishing and terminating connections, reduction in number of process switches, reduction in turn around time by bypass the network layers when on the same network. They hoped that only the difficulties of building distributed systems- timing, independent failure of components and coexistence of independent execution environments - will need to be resolved after these optimizations.

4. Evaluations
Two Dorado machines were connected via ethernet and the best and median time were calculated for various combinations of workloads with simple data structures and varying argument lengths. Profiling the exception handling in each stub would have provided more insight to the efficiency of the mechanism. They claimed RPC was not implemented for bulk data transfers but it would have been beneficial if a different IP protocol on the same workload could be compared against each other for the same network topology. There are many instances wherein the authors have claimed to have done experiments to find differences in factors but they weren't specified clearly.
In my opinion, the evaluation had a huge gap in the complex design discussion and the simple implementation on lightly loaded network. There was no measurement of the execution time overhead of the encryption mechanism, the internal components such as the stub routines and the RPCRuntime implementation. It would have been satisfactory if there were more nodes and higher attach rate of the server. We could then understand how the multiple requests were being handled and what was the impact on latency.

5. Questions
dispatcherHint has been used as part of the call from user to server but there is no explanation of that. Also, the unique identifier which is monotonically increasing via the 32-bit counter has an allowance of burst rate being higher than 1request/second. Im not sure how this is supported/what exactly this implies as part of the system design.

Summary:
This paper explains RPC based distributed communication. The primary goals are:
i) Make distributed computation easy/simple and effecient
ii) Secure
iii) Have powerful semantics a

Problem :
The authors wanted to make RPC as simple as doing a local procedure call. The idea is, the complexity of semantics should not deter application programmers to do distributed computation. They propose a complete design and implementation of RPC based communication along with added features of security and simplicity.

Contribution :
Primary contribution in my opinion :
i) RPCRuntime annd the stub methods take care of the semantics of network communication and the programer can thus do inter-node communication using local procedure call like syntax.
ii) A transport-level protocol which focusses on 1. RPC latency , instead of the throughput maximization focus in bulk transport protocols 2. Server scalability 3. Stateless nature 4. Affordable handshaking.
iii) The RPC implementation enforces security through certain modifications made to the Grapevine authentication protocol which allows only a certain set of users to export interfaces.

Evaluation :

To evaluate the RPC system latency of RPC between 2 machines with varying size of arguments. This test does not highlight the worst case time and a distribution of how each design choice (for example, encryption )impacts latency. More importantly, this evaluation does not incorporate latencies due to network congestion, when the network is highly congested and other noises with multiple clients/servers communicating. The security features have also not been evaluated.
However, given the time frame when it was written (20 yrs back) I think it was a very novel technique which actually got adopted.

Confusion :
What features are still in use/dropped from this protocol today?

1. Summary
This paper discusses about the design and implementation of a Remote Procedure Call (RPC) package that can be used for providing communication between machines in a network during distributed computing. The paper discusses the various design choices the authors make so as to make RPC communication highly efficient.

2. Problem
The main goal of the authors was to make distributed programming easy and the then existing communication mechanisms like message passing or distributed shared memory were major constraining factors that limited the development of distributed computing either because they were inefficient or was difficult to program with. The authors wanted to build a higher level communication mechanism that is simple and easy to use and highly efficient.

3. Contributions
The main contribution of the paper is in the design and implementation of a simple and effective RPC mechanism that resembled very close to a local procedure call. A distributed program developer has to worry about writing the client and server logic while the RPC runtime and the automatically generated client and server stubs deal with low level communication over the network. One of the contributions is how they make RPC for simple calls fast by a number of optimizations: i) they have result of a call serve as an implicit acknowledgement for the actual call and the subsequent call packet serve as an implicit acknowledgement for the result packet ii) they minimize cost of setting up, maintaining, and terminating connection - the receipt of a call from an unknown client serves as connection setup iii) they use process pools to avoid process creation overhead and use process ID on each packet to reduce number of process switches. iv) they modify the network driver, to bypass normal software layer and they don’t make use of the existing transport layer protocol. The server and client maintain minimal state about each other which makes dealing with crashes easier. The server doesn’t keep any information about the importers of its interface and hence doesn’t have to worry about importer crashes. The client maintains a unique identifier of export in its binding so that a server crash will force it to rebind. The server again maintains minimal state of one sequence number per client/process pair and the client has to just maintain a single machine wide counter. They make use Grapevine database for naming and location and also to impose security by restricting imports.

Few design decisions like having only one outstanding request per process and making the communication synchronous doesn’t make it suitable for scenarios like bulk transfers. Having no explicit heartbeats or timeouts might waste server cycles say if a client crashes after a call and the server is doing some heavy computation for the client.

4. Evaluation
They evaluate the time taken for remote procedure calls for different number of arguments in call and result packets and compare it against the time taken for a local procedure call with similar arguments. They also evaluate the throughput of data transfer by making parallel remote calls.
I don’t know if time taken for a local procedure call was the right metric to compare the time taken for a remote call with. It would have been more ideal to compare it with other remote communication mechanisms like message passing or distributed shared memory or a tailor made implementation using sockets. Although they talk about distributed computing, they didn’t evaluate how easy was it to write a distributed program using their RPC package or how effective was the RPC communication in a complex computation involving a cluster of machines performing multiple RPC calls. Time taken for an entire distributed computation as opposed to a single call could have brought out the disadvantages of having only one outstanding request per process and synchronous RPCs. Also, evaluations with respect to having multiple and concurrent clients are missing. It would have also been interesting to see how much performance benefit they achieve by not operating over existing transport layer.

5. Confusion
Exception handling part is not very clear and was confusing.

Summary
The paper discusses the design, implementation and evaluation of a Remote Procedural Call (RPC) based distributed system in the Cedar project. The proposed design was based on the objectives / considerations of making distributed computation easy, providing secure inter-node communication, achieving high RPC communication efficiency and robust implementation through powerful semantics while maintaining simplicity and performance.

Problem
Building distributed applications was difficult / tedious from the application programmer's perspective, as s/he needed to understand complex syntax and semantics of message passing / shared memory mechanisms to achieve inter-node communication. While the approach of letting network nodes interact through Remote Procedural Calls (RPCs) was studied earlier, a full-scale design and implementation of an RPC-based system on a network cluster was required in order to evaluate the design considerations associated with data and control transfer over the network through RPC. Also, security mechanisms for RPC did not exist at that time.

Contribution
The authors built a RPC facility for the Cedar project. An RPC call chain involves this sequence: user program->user-stub->RPCRuntime(user)->RPCRuntime(Server)->server-stub->server procedure. The same chain is reversed for returning the result of an RPC. The programmer can thus perform inter-node communication for a distributed system through the familiar, local-procedure like syntax of an RPC, while the underlying semantics of network communication are left to the stub methods and the RPCRuntime.

The described RPC implementation uses the Grapevine DB and server-local tables to aid in efficient server discovery and binding for a given interface instance and/or type (An interface refers to a set of functionality serviced by a server node (interface exporter) through RPC to the client (interface importer)). Another efficient feature in the design is the pool of ready server processes to dynamically handle client RPC requests without process spawning and initialization overhead. The RPC implementation enforces security through certain modifications made to the Grapevine authentication protocol which allows only a certain set of users to export interfaces.

To achieve high RPC communication efficiency, the authors designed a transport-level protocol specific to RPC efficiency requirements, that focused on 1. RPC latency minimization, instead of the throughput maximization focus in bulk transport protocols 2. Server scalability 3. Stateless nature 4. Inexpensive connection setup and handshaking. The corresponding protocol developed had guarantees of traditional connection oriented protocols without the associated overheads. The authors explain this protocol through its handling of simple calls, complex calls and graceful exception handling.

Evaluation
The authors attempted to evaluate their implementation by using RPC based communication between two Dorado nodes connected as a part of a larger network with light network load. They measure the minimum and median times for complete execution of an RPC chain (from the time the user invokes the local user-stub procedure to the corresponding return from that call) for varying argument counts and varying argument sizes. They also measure the corresponding transmission time and equivalent local procedure call time for these experiments.

I personally found the evaluation to be lacking in many aspects, especially considering the complexity of the design proposed and implemented. A major drawback was that no code profiling was performed to measure the execution time overhead of the internal components such as the stub routines and the RPCRuntime implementation. The encryption facilities were turned off during these experiments. This prevents us from knowing the overhead associated with the encryption mechanism. Another drawback was that worst-case performance was not reported, only the best and median case timings have been mentioned. Security arrangements in RPC, which were considered an important aspect of the design, have not been evaluated at all. The setup was also not evaluated on a full-scale Cedar cluster, which would have provided insight into its performance on a real-life distributed system. It would also have been interesting to evaluate this design on a heavily loaded network and observe its behavior in the wake of effects such as network congestion, queuing, etc.

Questions/Confusion
1. Fig.3 - What is dispactherHint?
2. How do current-day RPC based systems perform server discovery and enforce security?
3. The paper did not discuss how the RPCRuntime is aware of the data representation format on the other node. e.g. Differences in data representation due to varying endianness on the two machines.

1. Summary: To simplify the implementation of distributed computations, the authors present a method of abstracting network communications as language-level procedure calls. Based on the Mesa language's separation of interface and implementation, they construct a code generator, Lupine, which takes regular procedure declarations and converts them into network communications, without affecting the language-level semantics of the procedures.

2. Problem
Correctly implementing distributed computations using low-level networking constructs is a challenging process, requiring care and expertise. However, protocols which deviate significantly from core language semantics increase design effort for developers implementing distributed systems. Conversely, a protocol that is too low-level may be inefficient or difficult to use; for example, networked memory is basically shared memory with even worse paging costs.

3. Contributions
The authors couple a RPC runtime, which handles the low-level pragmatics of network communication with Lupine, a code generator, to allow standard Mesa procedure calls to function across a network. In a design choice that influenced later languages, Mesa separates interface declarations for a module from the code implementing the module. Given the code for a module, Lupine automatically converts the procedures into remote procedure calls by creating caller and callee "stubs" for the client and server, respectively. The client invokes an RPC like any other Mesa procedure, but the stub takes the procedure parameters, and passes them to the RPC runtime, which converts them to the appropriate format and transmits them over the network. The server-side RPC runtime receives the network communication, and passes them to the callee stub, which converts them back into procedure parameters, and the procedure implementation continues as usual. The stubs handle the procedure epilogue in the symmetric fashion. To obtain network addresses of RPC providers, clients can query a distributed database in a manner analogous to DNS. In addition to name resolution, the database also allows queries based on Mesa interfaces, allowing a client to obtain all providers of an interface. To provide reliable communications, the RPC runtime uses a standard monotonic counter for calls, along with a basic acknowledgement protocol. To improve performance, the servers maintain a fixed pool of processes, rather than spawning a new one for each call. In addition, to reduce redundant network protocol costs, they bypass Xerox's standard protocol stack as much as possible, and work directly with the link layer. The RPC system also provides DES encryption and uses an unspecified mechanism to protect against MITM attacks.

4. Evaluation
The authors test increasingly large messages across a uncongested network. Their results indicate that the RPC communications incur millisecond-scale latency, which seems reasonable for a network communication. They also discuss the rate of adoption of the protocol, and it seems that users find the ease of development and the performance of the communications satisfactory for developing varied applications. However, especially given the degree of discussion given to their acknowledgement policies, it is baffling that they don't explore the effects of network congestion on their protocols. Moreover, it's disappointing that they did not provide any metrics or analysis of their security mechanisms.

5. Confusion
What did they do to prevent replay attacks? Without a description of the protocol, I'm skeptical of the correctness of their message integrity scheme.

Summary
This paper provides a design and implementation of a remote procedure calling system. The paper highlights few of it's newly introduced optimizations as compared to the traditional one and gives some insight on it's effectiveness.

Problem
The authors claim that distributed computing wasn't much exploited because of lesser convenient programming environments. The paper thus attempts to improve the remote procedure calling system which in turn would enhance use of distributed computing. The goal is to have simpler and cleaner semantics with good efficiency and security in terms of using remote procedure calls, replicating local procedure call system in all possible ways.

Contributions
- The design presented here tries to make remote procedure calls as simple as using a local procedure call.
- To make this happen, a new library named RPCruntime is introduced which takes care of handling network communication and security. This makes a programmer's life easier.
- A new database system, Grapevine, is introduced to help associating a client machine with remote machines that export a certain procedure.
- The new architecture is free from using shared address spaces. Hence, no additional memory worries for programmers.
- Provides a complete design which provides handshaking mechanism, sending/receiving call arguments/results, security and in some cases even exception handling between the caller and callee machines.

Evaluation
The paper presents a performance table showing times taken for remote procedure calls on two Dorados machines with varying number of arguments and results. This only gives an idea as to how a remote procedure call performs but does not give any idea as to how better this performs than it's counterparts - like using shared memory address spaces. Plus, the testing was done on a local network with just 5-10% of it's capacity being used. Though, it's not very clear on how much network traffic was prevalent at that period of time, but surely the testing could have been better by having multiple machines calling remote procedures on some different multiple machines on the same network. Or, even with two machines, multiple calls could have been made from different user processes. This would have given a real feel of a distributed system where multiple requests are being made to server(s). Plus, the authors mention a lot about optimizations that were introduced into the RPC system, but fail to give any hints on whether the optimizations really boosted the performance or not.

Confusion
Do the current RPC implementations also avoid the networking layers by modifying network drivers ?

1. Summary
This paper designs an RPC package and documents the design decisions along with their reasoning. These decisions relate to semantics provided to the user, binding protocol between the client and server as well the communication protocol redesigned for efficiency in this paradigm. The paper concludes with a performance discussion of the current package.
2. Problem
Although RPC had been discussed in the past no usable packages existed at the time.These were important for easily developing distributed computing applications. Currently the programmers needed to understand message passing or shared memory mechanisms which were a hindrance to system development. An RPC package would abstract this under already understood semantics of simple function calls. Current solutions also did not provide any security for sensitive data which the current RPC package attempts to fix.
3. Contribution
The primary contribution of this paper was identifying all the modules required to build a usable RPC package and how each can be designed and optimized. They used external modules such as lupine for stub generation and grapevine to maintain indexes for all the available services. Using these components they were able to build an efficient network protocol without the extra handshakes and state management used by transport layer protocols. The networking prioritizes latency over throughput by making the connection setup time small but adding extra ACKs for bulk transfers. This is in line with the methodology that most function calls will fit in one packet.The paper also details a binding protocol where the servers registers their interfaces which are then imported by the clients, since only authenticated servers can register their interfaces, it protects the clients from imposter servers. These bindings are then used by the caller to invoke methods on the server with minimum state management at both the server and client (only sequential IDs and process IDs are maintained to ensure that correct sender/receiver communicate). The paper also documents various optimizations (having various server processes standing by to accept client requests) along with the cost they mitigate. Another important contribution of the paper is that it discusses alternative approaches wherever possible allowing the reader to understand the various tradeoffs and also pointing to possible future work. This lets other RPC developers pick and choose optimizations based on their target workloads.
4. Evaluation
The authors primarily test the latency of remote procedure calls between 2 machines. The test varies the size of the arguments and result to see the impact. This test establishes the efficiency of this solution overall but does not highlight the impact of each of their design choices. The evaluation was only conducted over the local network, not analysing the cost where high network latency would force the caller/callee to send ACK requests. This system was not noisy, most distributed computing application would have many clients/servers communicating over the same network with multiple clients per server. The paper mentions various optimizations such as adding the process ID of sender/receiver in each packet to deal with this issue but does not test their impact.
5. Confusion
The paper mentions various additions to their network protocol to deal with various cases (sequence ID, server unique identifier etc) but does not provide a total summary of what the packet looks like. Something similar to a TCP packet structure would clear this out for me.

Summary:
The paper describes the design and implementation of an RPC that was developed for use in the Cedar programming environment using the Xerox research internetwork, with the intention of building mechanisms and semantic constructs that make it easy to use and efficient. The paper also describes how the design addresses common issues in existing RPCs including security, handling of failures and provides a simple evaluation with respect to local RPCs in a controlled environment as well.

Problem:
Existing RPC designs at that time did not have concrete implementations that were semantically easy to use, efficient and provided reliability and integrity which are important for building efficient distributed systems. So this paper provides a design that resolves the main issues in existing designs along with its implementation details, which could be extended further.

Contributions:
The paper aims to provide simple semantics for RPC based communication which resemble existing local function calls. The author also describes the major common issues in existing RPC based designs and provides solutions to the same along with implementation details. The design uses a grapevine database that contains all the binding information for communication and control transfer between the client and the server and is on the critical path. The design provides facilities to export an interface for the servers and import interfaces and bind to specific instances for clients. The end-end implementation details of binding, naming an interface, locating a remote exporter, sending packets to instances and receiving acknowledgements has been neatly explained. It also provides a packet level transport protocol which provides flow control, reliability, security and exception handling facilities for RPCs, which could be extended for bulk transfer as well but with slight inefficiencies. Overall the protocol could be used to extend the RPC based communication mechanism across large distributed systems. It also describes the optimizations that the authors have used such as using process pools to reduce dynamic process creation overhead, sending subsequent packets as acknowledgments, reducing number of process swaps and modifying the network driver to bypass the existing network stack. Overall, I feel the paper has been well written by explaining the motivation and back-story behind most decisions.

Evaluation:
The performance evaluation was done by implementing RPCs over Ethernet between a couple of Dorados. The total time of the RPC is measured for various cases involving different packet sizes on different methods with different arguments. The same procedures are implemented locally and evaluated as well for comparison. Evaluation details for bulk data transfer in parallel is also mentioned. The author should have clearly provided a split up of the total time in terms of time required in the client/user stub and server. The number of machines could have been increased and since the entire experiment was performed in a controlled environment, I sort of feel that the evaluation workloads were not remotely close to real world workloads. The cost of the additional overhead of providing security and flow control over previous implementations have not been provided in the paper, which makes it difficult to compare this implementation with existing implementations, though the additional features over previous implementations are certainly a big win. The author mentions about various optimizations (mentioned in the contribution section) but does not evaluate their performance impact. But overall I think this was a great paper that transformed the research in the area of RPCs and its use in distributed systems, which is clear from its adoption.

Doubts:
Which mechanisms/design principles used in this paper are still in use today? What are the recent techniques/advancements in modern publish/subscribe RPC service frameworks, since most firms have one of their own frameworks to expose services?

1. Summary
This paper proposes using remote procedure calls (RPC) as a way of communication between programs running on different computers. The design of this mechanism strives to be natural and powerful, so that future development and experiment on distributed system will become easier.
2. Problem
When the paper was written, writing programs that communicate through network was very difficult, and much of the ongoing researches on RPC did not go beyond paper design. This paper aims to provide a complete design and implementation of RPC that mimics normal procedure call, which feels most natural to software developers.
3. Contributions
To make RPC call, user should make a procedure call just as normal. The underlying stubs and a RPC Runtime are then responsible for making the remote call, then receive and deliver back the result. In the program structure the stubs package and de-package the parameters to the desired format, and the Runtime transmits packets using special protocols that are optimized for cases of simple and complicated calls, so that reliability of the communication is ensured, and for simple calls servers may also send back result directly to boost performance. The bindings of the RPCs are stored and looked up in a distributed database called Grapevine. The naming is divided up into type, which specifies the abstraction of the server, and instance, which may point to a specific server that can do the job. RPCs can be looked up providing only type, so that the system can look up the instance that can finish the task and communicate with the client most efficiently.
4. Evaluation
They roughly measured the performance of RPC calls on two Dorado computers connected with Ethernet. Their result shows that under light weight load on the network, without doing massive data transfer, the protocol they used for packet transmission has highly optimized performance.
As they admitted, this measurement is clearly far from complete, since it does not cover cases when the network is heavily loaded, and the performance of other portions of the RPC process is not measured. The design they propose is more like a pioneer on providing a viable implementation, which hopefully opens the door for further research and optimization on the same subject.
5. Confusion
The RPC mechanism relies heavily on exception. So how does it adapt to the environments where exception may not be quite available (e.g. runtime of C)?

1.Summary:
This paper is about the design and implementation of Remote Procedure Calls(RPC) in the Xerox research internetwork for making communication between distributed applications efficient. The authors also introduce a new transport protocol for RPC.

2.Problem:
When programmers want to build distributed applications, it is important that the distributed data computations are made easier so that focus can be laid on building the distributed system instead of concentrating on the communication mechanisms. This communication should be efficient, otherwise the distributed setting might not be used effectively. Along with this, the semantics of the protocol should be simple and not requiring much change to the existing programs. For this, the authors use the same idea as local procedure calls.

3.Contributions:
1) Design of semantics of RPC, similar to that of local procedure calls. This ensures that it is of ease for the programmers.
2) Auto generation of client and server stubs. This takes care of packaging and sending procedure calls over the network. This makes the system simple and requires the user to provide only method calls.
3) Having two parts to name of interface namely, type - which is high level abstraction of the interface and instance, which identifies the particular implementation of the interface. This helps caller to invoke specific procedures. Locating an implementor is done through Grapevine database which contains the details on type, interface and the server's network address which exports the interface.
4) Implementation of a simple transport layer protocol for RPC, where the reply from the server itself acts as the acknowledgment for simple calls. Their connection mechanism also reduces the elapsed time between initializing a call and getting results.

4.Evaluations:
The authors depend on Nelson's thesis for evaluation of RPC implementation's performance characteristics. They measure different remote calls between two Dorados connected by Ethernet and show the minimum and median elapsed times along with time taken for local calls, but they have not drawn any conclusion on the same. They also lack the elapsed times of individual segments of a remote procedure call and evaluation of cost reduction in connection management, which are some of the key contributions.

5.Confusion:
How do modern transport layer protocols support RPC?

Summary
The main aim of the article is to simplify the development of Distributed system by implementing a new efficient Remote procedure calls which provides encryption and behave like local function calls within a system.The Paper introduces new concepts of stubs, and designing a separate custom communication protocol and new binding mechanisms.
Problem
During those days Construction of communicating programs to build a distributed systems was difficult and required high expertise in the research community.The existing Communication mechanism which didn’t even have mechanism for protection of data was a major factor constraining further development of distributed computing. So the author proposes a highly efficient secure communication mechanism which is almost as ease as local procedure calls and hopes to remove the unnecessary difficulties in developing distributed systems
Contributions
The Main Contribution of the paper are
-First practical implementation of Remote Procedure call. Even though the concept of remote procedure calls was introduced earlier, this paper was the first implementation of Remote procedure call
- Concept of Stubs :Lupine automatically generation of client and server stubs, which packs and unpacks the arguments and results.
The programmer does not need to build a detailed communicated related code. He only needs to write the user and server code.
-If the user wishes to make a remote procedure call it will actually make a perfectly normal call which invokes the corresponding procedure in user stub. Hence making remote procedure call look like local call
-Separate the binding in into Naming and Locating and appropriate exporter. The Naming was further split type and instance,
and providing the flexibility in binding scheme - a]-The importer may just specify the interface type and The RPC runtime will find instance that accept the binding request which is done efficiently by finding the closest running exporter.The entire binding is taken care by RPCruntime, hence the programmer need not worry.b]IF the instance is a network address we can bypass the interaction with grapevine and bind to the exporter directly
-Packer Level Transportation Protocol:They developed a separate protocol specific to RPC so as to minimize the time between initiating a call and getting the result. The protocol was designed to handle situations when arguments or the results were not able to pack in single packet then use
ACK mechanism. IF the server goes down use probe packets to let know the caller of exception.
-Separate Mechanism to handle exceptions when executing the procedure at the server by sending the exception back to client , so that it may handle
the exception or terminate.
-Use of process i.d in packet for faster communication.
-Security by providing end-to end encryption
Evaluations
The evaluation shows the time take for different number of arguments ranging from 1-10 which increases linearly
Time taken is also shown when there is 1 argument/result whose size is an array ranging from 1-100 words. which also increases linearly
The time taken for transmission, and also the performance when running the server on local machine , resume exception and unwind exception is also shown.There is no detailed evaluation because the paper mentions that comparison with other RPC protocols at that time and other extensive analysis was present in Nelson’s thesis.

Missing evaluations:
The paper talks about there were no existing protocols in RPC which provided the encryption mechanism ,but hey have implemented it, but there is no evaluations of encryption mechanism ,all the tests ran didn’t use encryption.

The Paper has mentioned the performance of interleaving parallel remote calls had good data rate of 2mb per second,but what i find missing is the performance when there are Multiple Clients running on separate machines and there is single server/ multiple servers running to serve a request.

Confusion
In the Current implementation of RPC in distributed network. What are current changes made to the one suggested in the
Do we bypass the normal layer of protocol hierarchy.

1. Summary
This paper describes the implementation of RPC on a Xerox PARC research distributed system (Cedar). Among several topics the authors describe their unique remote binding mechanism, maintaining exception semantics over remote calls and a custom transport protocol for RPC.

2. Problem
At the time of writing of this paper, remote procedure calls (RPC) had garnered interest in the research community however there were few and incomplete practical implementations of the same. From a design perspective the semantics of an RPC should be powerful to allow easy adoption and yet be efficient in their implementation. Security is also an additional dimension that was not well explored in this regard.

3. Contributions
The key design principle used by the authors is —the semantics of remote procedures should be close to that of a local procedure. Essentially, remote procedures are more or less indistinguishable from a local procedure.
1. The RPC system uses auto-generated stub code both at the client and server end. This in turn makes calls to a runtime component that oversees communication for the arguments and return value between the client and server.
Reliable Binding:
2. The system allows multiple servers to implement the same interface, so each service has both a type and an instance name. A distributed database (Grapewine) is used to provide both a list of servers for a particular interface and an entry per service for its network address.
3. The system uses a unique identifier (UID) on every call to check if a server has crashed and the binding is thus no longer valid.
Tranport Protocol
The authors develop a lightweight communication protocol for minimizing latency and keeping minimal state information.
4. The main idea is to retransmit a packet until acknowledged. The protocol also uses the response (return value or a new call packet) as an implicit acknowledgements. The client adds a monotonic sequence number which is used by the server to detect duplicates. For longer running calls the client sends probe messages as well as kind of heartbeat message.
5. A connection is maintained in a table indexed by the caller’s machine address + process id, collectively called an activity. Connections are implicitly created and keep track of the latest sequence number of the recent RPC.
Exception Semantics
Lastly, the RPC package retains the semantics of a regular language exception by sending a special exception packet to the client. The runtime/stub code then invokes the approbate catch statement (handler) on the client.

4. Evaluation
The authors evaluate two aspects viz the RPC runtime latency as well as the best achievable throughput. They measure the RPC run times on two machines connected via an Ethernet connection. We can see how the RPC delay compares to an ideal network delay, particularly it does not scale well if the arguments get larger. It would have been more interesting if they presented an evaluation of the RPC performance on a native internet protocol like TCP/IP. Also, comparisons on practical workloads or with another research system are not presented.

5. Confusion
Is there one runtime process in each machine and multiple worker processes or does each process run an instance of the run time?
I had trouble understanding how the Exception handling is done across the network.

1. Summary
This paper brings into reality the idea of making communication across network as easy as local procedure calls. They built a complete software package and designed a dedicated transport layer protocol to achieve this goal.

2. Problem
Building distributed computing programs is hard while procedure call is a widely accepted concept of transferring data and control. The idea of communicating via remote procedure calls has been there for years but implementations are rare. They want to build a RPC system that is efficient, easy to use and secure.

3. Contributions
They generate user-stub and server-stub automatically with Lupine. The communication details are hidden and programmers can call the stub locally. Lupine also checks for incompatible arguments and results.
The binding between caller and callee is done by a distributed database. A client can select from multiple instances of the same type to get the closest server. Access controls in the database can be used to restrict hosts from providing unqualified or malicious services.
The binding process includes looking up in the database followed by requesting a unique identifier. This design frees the server from maintaining any information regardless of the number of users. The client is able to detect server crashes without any explicit message.
They combine the idea of implicit and explicit acknowledgement. When a lot of traffic goes back and forth, the subsequent packet serves as an implicit acknowledgement. While when the link is free, they use explicit acknowledgement packet which will not cost much. Their protocol achieves its best performance for simple short calls. However, they don’t talk about congestion control and it may perform poorly.
They use a monotonic counter to eliminate duplicates, include a process identifier to dispatch packets, and pre-allocate a process pool to avoid the creation overhead. These are all popular ideas today but I am not sure if they were new at the time of writing.

4. Evaluation
The evaluation part shows elapsed time for different type of packets in a simple setting: two machines connected with a lightly loaded Ethernet. For each type of packet, total time is compared to local call time and expected transmission time. As they mentioned that analysis of other RPC protocols and implementations is presented in another paper, it is hard to tell whether the results are satisfactory or not.
To better evaluate the RPC structure and Lupine, detailed measurements like how many cycles are spent in user-stub, caller-side RPCRuntime, callee-side RPCRuntime and server-stub are necessary. As for understanding the behavior of the protocol, average number of explicit acknowledge packets sent in each case should be helpful.
It may also be useful if they compare the performances under different selections of retransmission timeout.

5. Confusion
What does it mean by “There is no assembly language for Dorados”?

1. Summary
This paper presents the early works done in the full-scale implementation of the RPCs. It describes the RPC mechanism, facilities for binding RPC clients, transport level communication protocol and performance measurements.
2. Problem
The main aim of the authors was to make distributed computation easy, which were hurdled by the existing communication mechanisms. They wanted to develop the implementation of a secure RPC that was relatively transparent to the programmer in order for it to be indistinguishable from a local procedure call.
3. Contribution
This paper presents some novel ideas in RPC that are still being used today. The RPC package was developed using the Cedar programming language running on Mesa OS on Dorado hardware. There are five pieces involved in a remote call: user, user-stub, RPCRuntime, server-stub and server. The stubs are automatically generated by “Lupine” during compile time. This relieves the programmer from needing to build communication-related code.
For binding, the naming and the location of the interface are the important factors. The type and the instance are the parts of the interface that help to identify the particular implementation. The Grapevine distributed database keyed by the Grapevine RName is used to keep track of the connect-site (network address of the server). The paper also describes the mechanisms by which binding takes place and how the authorisation of the service is done.
The packet-level transport protocol implemented is identical to the semantics of local procedure calls. In case of simple calls, retransmission of packet occurs until an acknowledgment is received. The result of a call and further call packets are used as a sufficient acknowledgement. Each call by the caller contains a unique identifier in order to avoid processing duplicate packets. In complicated calls, acknowledgment is expected for the packets sent. Probes are sent out by the caller and if no response is obtained after a certain threshold, then an exception on communication failure is raised. Large contents are transmitted through multiple sequentially marked packets, where only the last packet requires acknowledgment. The exceptions are propagated back to the caller for proper handling. The server callee maintains a pool of available server processes thereby saving the cost of process creation. The packets contain ids of calling and serving processes to avoid context switch. The RPC mechanism also includes encryption mechanisms for security.
4. Evaluation
The system was evaluated using the measurements made for remote calls between two Dorados connected by an Ethernet. No encryption facilities were used. The elapsed times and transmissions times for different message argument sizes were used to determine performance. Although other protocols perform better in one direction transmission due to transmission of fewer packets, RPC performs much better in parallel remote calls from multiple processes. The entire RPC runtime package was implemented in 2200 lines of source code displaying its ease of implementation. The RPC mechanism was implemented in the Xerox internetwork and displays a high convenience of use. However, all the aspects of the goal of the system were not properly evaluated as the system was not implemented for full-scale use. The cost of intermediate operations like importing and exporting an interface was not taken into considerations. Nevertheless, this paper presents with very important concepts that are very similar to the contemporary COM infrastructure.
5. Confusion
1) How is the shared address space problem handled?
2) Remote forking was discouraged in the paper. Why?

1. Summary
This paper presents the first practical implementation of RPC done at Xerox PARC. The authors discuss the motivation for implementing RPC, the system design, key design choices, and the implementation details of Lupine, and share their learnings and evaluation.

2. Problem
Their primary objective in developing an RPC system was to encourage the development of distributed applications by making communication almost as easy as local procedure calls, which were/are a well-known and well-understood mechanism for data and control transfer. They believed investing in RPC to be a good choice as it provides clean and simple semantics, efficiency, familiarity and generality. In the process of implementing the RPC package, they found that several aspects were inadequately studied/understood.

3. Contributions
The first practical RPC library's design and implementation.
Objectives:
Ease of use, Efficiency, powerful Semantics, and Security.
Design choices areas:
Call semantics, Binding, Data and control transfer protocols, Security, and Integration with current and future systems. Support for lack of shared address space was also a notable design choice.
Structure:
On client machine :- User/Caller. User Stub - marshalling. RPCRuntime (communications package).
On server machine :- RPCRuntime. Server Stub - unmarshalling. Server - procedure.
Stubs are automatically generated. RPCRuntime is part of the Cedar distribution.
Binding:
Importers bind with exporters using the Grapevine Distributed Database for discovery.
Transport Protocol:
Call packets, result packets. Call identifiers, conversation identifiers, complicated calls - sequence numbers and ACKs. Normal protocol layers bypassed.
Security:
Grapevine - Key distribution centre for authentication. Encryption is done.

4. Evaluation
A conscious but debatable decision was taken to not implement a time-out mechanism. The reasoning behind this was that abort mechanisms were present in languages used, and to keep RPC in line with local procedure call semantics.
Measurements were taken on existing transport protocols before the decision was taken to develop a custom transport protocol.
The authors have performed timing / benchmarking of RPCs, compared with local procedure calls. Comparing these two is obviously not a focus, so I believe the purpose of the data was to prove that RPCs are efficient and practical.
A point to note is that encryption was not used in the benchmarking, which could make a sizeable difference.
Also, the overhead of setting up the importers and exporters and interaction with the Grapevine database is not discussed.

5. Confusion
Call identifier / process identifier - overlapping information?

1. Summary
This paper presents the design and implementation of Remote Procedure Calls (RPC), an idea which the authors believe will be the first step in making distributed computing easy to use and well established. The authors discuss the challenges faced, the design choices they made, and various facilities and optimizations in their RPC mechanism with the main aims of efficiency, ease of programming, powerful semantics and secure communication.
2. Problem
RPC seems to be the natural choice for use in distributed computing and has been a research topic for a long time. However, a practical implementation of RPC didn’t exist. The authors believed that the lack of user friendly communication mechanisms restricted the capability to construct distributed applications to a specific set of experts. Thus, the main motivation for this work was to develop an efficient RPC mechanism with a powerful interface that would closely mimic the semantics of traditional procedure call (within a single process) so as to encourage the usage of RPC by programmers. Another major issue with existing mechanisms was insecure communication between nodes, which the authors wanted to solve by leveraging the recent progress in the field of network security.
3. Contributions
The biggest contribution of this work, as highlighted above, is that they developed an RPC implementation that would make it worth the programmer’s while to invest time and effort into developing distributed applications. Unlike previous research oriented implementations, their implementation was actually used in a live project, Cedar.
They modularised the implementation using user-stubs, server-stubs and RPC runtime packages that allowed the client and server to communicate via interfaces. Perhaps the most impressive feature of the design was the use of Grapevine Database to decouple the client-side and user-side implementations. For example, when the server does an export, it does not make any change on the client side structures. The authors developed robust communication protocols using various identifiers, addressing schemes etc. to allow fast, reliable (multiple interface instances) , highly flexible (e.g. address the server directly or using Grapevine database) and secure (facility of two-way authentication) communication. They did well to reduce the set up time with their novel binding mechanism instead of traditional connection establishment techniques. Another major feature was the RPC specific transport layer protocol to support two types of calls - while the simple calls were designed for superfast, short, frequent RPCs, complicated calls handled the infrequent, long RPCs well - even withstanding packet loss and crash or re-boot of client/server. The authors also did extensive work in exception handling to ensure behaviour similar to local calls and assist debugging. A bunch of other optimizations were also incorporated to reduce the RPC overheads - using idle processes on server to handle RPC calls, bypassing traditional network stack whenever possible, implicit acknowledgment etc.
4. Evaluation
The idea and implementation presented are quite impressive. As mentioned, they leveraged the previous work of one of the authors in this implementation and relied heavily on the results in that prior work. The results presented in this paper are quite minimal; they just showed the RPC times, and compared them with local calls and theoretically calculated transmission times. However, I am sure readers would be interested in much more. A quantitative analysis of the gains achieved by using RPC specific transport protocol compared to traditional bulk-transfer based protocols would give the right context; I believe this is covered extensively in Nelson’s Thesis. An interesting experiment would be to study the load (number of clients) that a server could sustain as that would help in setting high-level targets for further improvements. The authors discussed how the implementation supports secure communication; experiments to measure the associated overheads have not been conducted. The authors should also run several other experiments - measuring the speedup achieved by using idle processes on the server instead of creating new processes, comparing the cost of simple calls with complicated calls, comparing RPC overheads over local network and internet. These small sets of experiments would help breakdown the gains achieved from different optimizations and channelize efforts for future optimizations.
5. Confusion
How does the implementation support two-way authentication? Why does client need to know the names of all instances explicitly?

Summary:
The paper describes the implementation of a RPC runtime library that primarily aims to make distributed computing easy while maintaining the library lightweight, efficient and secure.

Problem:
The paper was written at a time where there was lots of research on RPC mechanisms. However, none of them addressed the practical problems that arise during implementation. This paper describes the implementation of RPC in a known programming environment across systems on the internet.

Contributions:
The RPC runtime library preserves semantics that apply for a local procedure call. For instance, the library does not explicitly enforce the notion of a time-out. As a result, the caller and callee code would work seamlessly together if they were on a single machine. This sort of abstraction makes it easy for application programmers to reap the benefits of distributed computing without spending time/effort. However, it must be mentioned that the RPC library doesn’t support shared address spaces and hence the use of pointer references in the arguments.
Except while exporting and importing interfaces, the runtime library and its inner details are abstracted from the user application code. This is implemented using stubs on both the client and the server side. They interact with the Grapevine database to access interface types and instances, packs/unpacks data and interact with the RPC runtime library that in turn sends the packets over the network.
RPC runtime library uses a custom packet level protocol for flow-control and reliable delivery of packets. The paper uses a scheme where the caller packet or result packet is itself taken as an acknowledgement for the last sent packet. This again assumes a local procedure call semantic that the caller process blocks on the procedure call. This was chosen over the traditional protocols as the latter was designed for bulk data transfers and the overheads of setup/maintenance/teardown would prove to be detrimental to the performance. This makes the library lightweight as not a lot of state is to be maintained for an ongoing connection.
The implementation also provides for exception handling in the caller process. The callee sends out an exception packet whenever an exception is raised. The caller process executes a catch phrase for that exception, if any, and either resumes the call in the callee or aborts it. This allows fault handling to be done entirely on the client machine without any changes to the server code.
The paper also talks about the use of idle processes in both the client and the server to maximize machine utilization time. In such cases, interrupt handlers are used to wake up the appropriate client/server process.
Evaluation:
The paper has evaluated the library with a number of different types of procedures that vary in argument number and size. The time between when a function call is initiated and when it ends, the transmission time is evaluated for these procedures. It has also been compared with the local call time. All this demonstrates was the overheads of the runtime library. The paper has not evaluated the claim that it is lightweight. On paper it does seem so. However, the performance improvement over using a standard packet level protocol could have been shown to strengthen the point. The paper has also not evaluated the memory requirements of the library when a lot of distributed activity takes place in the machine, especially on the server side. Overall, the evaluation does not entirely reflect the advantages that the RPC library promised.

Confusion:
Details of Two-way handshake and the security implementation.

summary~
In this article, the authors presented an implementation of remote procedure calls that is aiming to make the remote procedure calls more efficient, safer and easier to use.

problem~
By the time the paper was written, the idea of RPC has been already around for many years, many examination of the design possibilities has been done, but there are not many full-scale implementations has been done. Existing tools for building communicating programs are difficult to use and have the issues like security and efficiency.

contributions~
One of the major contribution of this work is to remove the unnecessary difficulties in the development of distributed computing. That goal is achieved by sticking to the principle that the semantic of RPC should emulate the semantic of local procedure call. The efforts of emulating the semantic of local procedure call can be found at many levels of the implantation. At the top level, user-stub and server-stub together with RPCRuntime take care of argument packing and result unpacking and data transferring. At the lower level the design decision of timeout mechanism and exception handling also consider the goal as emulate the semantic of the local procedure call.
The design of the interface for binding operation introduce the concept of type and instance, I think this is interesting because this makes the framework more flexible, so it can do things like load balancing.
Another contribution is that they also a packet-level transport protocol. Even though it is possible to achieve their goal of emulate the semantic of local procedure call without designing a specialized packet-level protocol, but their performance are not satisfying. They identified the assumptions that no long holds true for RPC in the bulk data transfer protocol, and made correspond change to the protocol. One of a interesting example is that they realized the overhead of acknowledgment is large when the execution time is short, so they made the design decision that combine the data packet with acknowledgements for short duration procedure.

evaluation~
The authors mentioned that extensive analysis of several RPC protocols and implementations has already been done in the previous work, so not many evaluation was done in here. They measured the elapsed times for many RPC calls, and compare the result to local call, which effectively demonstrates the improvement of RPC efficiency through the newly designed packet-level transport protocol. But there was no evaluation on the scalability of their implemented even though they mentioned some mechanism they come up with to improve the scalability like maintaining a stock of idle server processes.

confusion~
how the server determines a certain procedure call is going to have short execution time and overloading the data-packet and acknowledgement.

1. Summary
This paper talks about the design and implementation of RPC. It looks like an extension of one of the author's (nelson) thesis. It talks about some of the main decisions made in the design of RPC structure, binding and transport protocol (and the reasons behind it like trying to make it similar to local calls).

2. Problem
One of the main problems mentioned in the paper was the lack of development of new distributed application. The main aim was to make distributed computation easy with a modified communication mechanism (which was an important factor in people disinclination towards distributed computing), create an efficient RPC implementation with powerful semantics and to make communication secure (reliability and integrity) (This was not a main focus of this paper).

3. Contributions

One of the main aim of the paper was to make the design simple and they decided to make a lot of their design decision based on how local procedure calls are implemented. I think this is one of the main reasons why RPCs became popular. In their system, the coder only has to write the user and server programs, the stubs are automatically generated (with stubs taking responsibility of packing & unpacking data and RPCRuntime taking responsibility of locating and sending). This also makes writes RPC programs simple. One of the things which I found interesting was the use of Grapevine database to provide binding (service/procedure location). Having a separate database for binding also made the system more flexible and secure (access control). They introduced their own communication/ transport protocol which provided a huge performance improvement compared to traditional transport protocols for small messages. When the messages became large (bulk) then they had a higher overhead, but this overhead can be significantly reduced by multiplexing data transfer across processors. They reduced the overhead of process creation by reusing already created idle processes. The paper also briefly talks about RPC's implementation of mesa language's exception handling and few security aspects of the system. I liked most of their features and the only thing I would disagree on was to avoid use of shared memory and to send large data in form of multiple packets. I think distributed systems today do deal with huge amount of data and I don't think their design is feasible when data is in sizes of mega, giga , tera - bytes

4. Evaluation
The evaluation was a little underwhelming in my opinion. Instead of showing the minimum rpc, medium rpc, local elapsed and transmission, it would have been better if they could have shown the time overhead caused by individual elements (server stub, server RPCRuntime, client stub, client RPCRuntime etc) of the RPC structure. From the values mentioned in the paper it looks like RPC creates a huge overhead compared to local procedure calls even after ignoring the transmission time. It would have been nice to see exactly what were the main reasons behind this. Also I feel they should have compared RPC's performance on their RPC specific transport protocol with the normal transport protocol.

5. Confusion
Were the run-time overheads of grapevine functions (RPCRuntime's interaction with Grapevine) included in the RPC's performance values?
I did not understand why they need a conversation identifier? Wasn't the sequence number enough? How does it provide security?

1. Summary
This paper summarizes the design decisions made during the building of package for remote procedure call (RPC) for the Cedar Project. The authors tried to extend the basic procedure call facility to communicate within a process to communicate between processes on a network. They discuss issues related to binding, transmission protocol, exception handling etc.
2. Problem
The RPC package was built to make distributed programming easier. The authors share their experience of trying to understand different aspect of RPC like issues such as failure handling, addressing of arguments, control and data transfer and methods to provide robust solutions while at the same time ensuring that the mechanism is efficient and secure.
3. Contribution
The biggest contribution of the paper was to discuss the various ideas that were looked into building a RPC calls. The authors even discussed the alternatives looked into which were later on rejected. Such a description gives a peek into the complexity and trade offs for a RPC call and can help stimulate further research into this field. The author’s decided to stick with the procedure call semantic for remote procedure call. This was with the idea of improving adoptability of such a call. They used RPC runtime and stubs to take care of the communication, reliability and security. This helped in keeping the user level interface very simple. They use grapevine system to take care of binding and support exception recovery by sending an exception packet to the caller instead of a result packet. Finally, the use of a very lightweight connection mechanism helped to optimize the elapsed time between the procedure call and the return.
4. Evaluation
The authors present performance results for their RPC implementation using two Dorado machines connected via ethernet. They report the latency for several types of remote calls, and compare it to the latency of a similar local call. A more detailed analysis is provided in the PhD thesis of of one of the authors.
5. Questions
1. How the does the RPC call handle the case of deadlock or crash without the use of timeouts. What if result packet is never sent by the callee, does the caller get stuck?
2. How exactly are RPC used? Could we go through their importance in the class?

1. Summary
The paper describes the construction of package providing RPC facility in light of authors’ particular aims and environment maintaining simplicity, efficiency and generality. Subsequently, authors also delineate binding mechanisms between the interfaces and their RPC specific transport protocol; types of calls and identifiers needed to establish communication, handling of communication-level and procedure-level failures, optimization of tasks and other unused alternatives.
2. Problem
Designer of RPC facility face issues like failure and address containing arguments handling, how to integrate remote calls into existing interfaces, how to ensure binding and suitable protocols for data/control transfer and how to provide integrity and security in an open network communication. Authors have described their solutions and alternatives in the paper.
3. Contributions
Authors of the paper ensured generality by choosing the same semantics for procedure calls in communication since they were the major control and data transfer mechanism in existing interfaces which led to an invent of RPC specific protocol. They were able to achieve reliability/availability by maintaining Grapevine distributed database (hinting DNS) containing binding information like network address of the exporting machine. It also provides protection in the form of selective users who will be able to export a particular interface. Servers were stateless, in which case they do not need to perform extra tasks after the client crashes. Simple calls only consisted of caller’s call packet containing identifier and procedure info and callee’s result packet containing the same identifier and results thus providing a lightweight connection protocol for building futuristic large distributed systems. Overhead of having extra buffering and control flow strategies were eliminated by treating packet having large arguments as independent smaller packets. Another property of Mesa language; exception handling is also handled in executing a procedure. And simplifies implementation by communicating only those exception that were exported thus also providing protection and debugging assistance. Process creation and swaps are avoided by maintaining a Producer-Consumer strategic processes which could handle multiple incoming packets on the server.
4. Evaluation
Authors performed their measurements with remote calls between 2 Dorados running Cedar connected by an Ethernet, in which they did not used encryption facilities which then earlier mentioned to be using in Grapevine database. Evaluation of their RPC facility seem reasonable provided the use cases they had to implement in Cedar project at that time. But then authors only evaluated performance between user invoking already exported procedure to its return and simply assumed the cost of binding an interface to be dominated by Grapevine server. From table, by interleaving multiple remote calls in multiple server processes in parallel, it lead to increase in data transfer rate. It seems like semantics that they implied in RPC facility became popular for its widespread use with clients finding them convenient. It would have been a good statistical overview had authors also implemented alternative, more complex strategies and compared with their current simplistic approach.
5. Confusion
How is conversation identifier useful in failure of caller?

1. Summary
This paper discusses about the details of RPC, the required sequence of steps while making a RPC call and the associated networking techniques to provide efficient, simple and yet powerful semantics. They then prove that it actually eases the programming in distributed environments as more people in Cedar project started using it.

2. Problem
Earlier theoretical studies about RPC were done but no real life solution existed. Also, existing communication using shared memory and message passing had existed or otherwise the semantics and syntax were difficult to use, thereby making it tedious for developers in distributed computing community. Also, none of the existing solutions were secure, even passwords were transmitted as clear text messages.

3. Contributions
The authors created RPCRuntime module in RPC protocol which helped in caller/callee communication using explicit import and export of procedures. These procedures were published through servers using interfaces which were regularly updated. The RPCRuntime module used Grapevine’s indexing mechanism to list interface types and instances and the associated network address. By enabling selective servers to provide export capability through grapevine’s authentication protocol, they were able to achieve security. Clients bind to an interface to obtain access to a remote machine which has exported this interface. This avoided the requirement of either hard-coding or broadcasting based discovery protocols in clients.
They further achieve network optimization by creating a list of outstanding processes and matching the request of new processes by associating a call identifier. This seems a reasonable choice since the overhead of creating a new process and garbage collection overheads would be too high otherwise. Their focus on latency minimization by avoiding costly steps of existing protocols (handshaking, explicit setup and teardown) was much thoughtful since those rules need not apply. By associating sequence numbers, identifier of the active process and explicit ACK, they were able to handle networking challenges. Multiplexing bulk data in smaller packets across processes helped them achieve bandwidth without requiring buffer management and explicit congestion control. To sum it up, authors were able to prove most of the claims and provide an easy paradigm, as we know that RPC form an integral component of various distributed File Systems such as NFS V2.

4. Evaluation
The authors provide a detailed time mechanisms using simple loopback calls instead of standard benchmark. They did not discuss the overhead of encryption mechanism. Neither they tried to see if Transmission time + Propagation Time (which can be negligible) + Queuing delay (again negligible) + Time to run locally was equal to elapsed time for round trip observed. This would have given some sense to cross relate the numbers. Also, cost of RPC calls on same machine was too high as was reported in LRPC paper. They do talk about the efficiency achieved in transmitting bulk data of 2Mbps in a 3Mbps link which confirms that multiplexing was a reasonable choice.

5. Confusion
I am still not sure that the authors though claim that the connection was stateless, there were no timeouts but they did bookkeeping to store the client information, and on what policy/threshold did they decide to resend packets if there were no timeouts. Also, why was grapevine used as a dependency for indexing and security?

Summary
The paper provides a package for providing remote procedure call facility for transfer of control and data over a communication network. The structure of the RPC model and the design rationale are discussed in details.
Motivation
The authors identified that despite having large communication networks and powerful computers, distributed computing was still a difficult task. The existing communication mechanism was a major bottleneck. Hence they were motivated to develop a new secure communication model of remote procedure calls that would be highly efficient with powerful semantics .
Contribution
1.The paper provides the first full scale implementation of a RPC which ushered in the way for building large networks supporting distributed applications.
2.The semantics of the remote procedure call has been kept as close as possible to a local procedure thereby removing the need of any changes in the client program to handle remote calls. This principle strongly influence many design decisions, such as not having a time-out mechanism.
3.The Xerox RPC implementation automatically generates the user and the server stubs thereby releasing the programmer of the burden of writing detailed communication-level code.
4.One of the most attractive characteristics of the paper is the simplicity of design consisting only of a user stub, RPC communication package and a server stub. Another feature is that the importer can specify only the type of the interface and not its instance; here the decision about the interface instance is made dynamically, thereby providing flexibility.
5.The light weight packet level transport protocol used removes elaborate connection set up and termination overheads(like in a typical handshake protocol). Moreover simple uses of unique IDs handle the problems of duplicate calls, exporter crash or restart etc.
6.Compilation and binding is separated with the actual procedure call mechanisms delegated to the user stub.
7. A graceful exception handling mechanism of sending an exception packet to the caller instead of the result packet is also provided.
Evaluation
Performance evaluation was done by implementing remote procedure calls between two Dorados connected by an ethernet. The measured parameter is the total time duration of the RPC and the experiment is carried out on different procedures with varying number and length of arguments. Measurements for the two different cases of exception handling in a procedure call namely, caller resumption and unwinding of next procedure activation in the caller stack, are also presented. The time durations for corresponding local procedure calls is also provided for comparative analysis. Additionally bulk data transfer rate of 2MB/s via parallel RPC from multiple processes is also observed. I feel that instead of a total time of the RPC, a phase wise breakup like time spent in user stub, time spent in server stub etc would have lead to better understanding of the overheads. Measurement of the memory footprint of maintaining the RPC data structures for the interface modules and the distributed database Grapevine, would have been useful too. Also it would have been better had the tests been run on a heavily loaded network and if the measurements were done across multiple machines instead of just two. Nevertheless I feel it is somewhat unfair to be too critical of the evaluation section of the paper as the authors clearly mention that an extensive analysis of several RPC protocols and implementations, including an examination of the contributing factors to the performance differences has been provided in a previous paper.
However, I don't like the way authors just assume that some reasonable optimizations, like special purpose network microcode, specialized packet for simple calls etc, would not provide significant performance improvement over the existing model, without backing them up with some valid experiments or explanation.
Confusion
What is the purpose of having a separate process identifier when the activity (machine identifier,process) of the caller identifier can act as one?
What is the rationale behind having a separation of type and instances for the procedure calls?

1. Summary
The paper describes a paradigm that provides remote procedure call facility to transfer and control data across a distributed communication network, and all this with clean and simple semantics. The paper designs an efficient binding mechanism, transport level communication protocol, security and exception handling features.
2. Problem
Enabling distributed computation across machines connected through Ethernet is attractive but is difficult because of the inherent challenges of timing, addressing, fault tolerance, security. Also required for this message passing is an efficient communication protocol, clean and self-containing semantics and data integrity. Remote fork has design issues with data/argument passing and shared memory is slow and requires complex remote addressing schemes. Thus, it is essential to provide an easy and efficient way to handle the heterogeneous end-to-end computations.
3. Contributions
In this work, the authors devise seminal design ideas that strives towards simplicity, usability as well as efficiency. RPCRuntime and stubs handle communication, making users free from implementation details. They follow universal Mesa interfaces to specify function names, arguments and return types that gives the callee and caller sufficient and compatible data to work with. A unique identifier based binding mechanism to attach enables simple and quick discovery and participation. They employ a distributed database(Grapevine) acting as a name service provider as well as for verification. Instead of using a standard bulky communication protocol, this paper goes with a basic and relevant protocol: a reply implicitly means it is an ACK => no extra ACK passing, piggyback request and response, identify failures and idle connection through probes, duplicate detection using sequence numbers, handle complicated calls(multiple packets) by explicitly ACKing every non-terminating packet before sending next packet, thereby avoiding flow-control mechanisms, or multiplex data between separate processes. All these design ideas were seminal towards building distributed systems.
4. Evaluation
This paradigm aims at providing easy, clean and efficient distributed computation. So intuitively evaluation should address the goals by showing the usability of the RPC package, its performance through latency/throughput, fault tolerance and scalability. This work does not provide extensive measurements. It only compares latency of remote calls between two Dorado machines connected by an Ethernet to prove the performance gains relative to a local-only implementation. For larger transfers, they mention that interleaving parallel remote calls from multiple processes gives significant gain.
But in order to provide a wholesome effectiveness of their design, they should have provided the simplicity of using an RPC package than DSM or remote fork, how it detects and recovers from failures, the amount of message passing(data+control packets) in the network, effect of addition of more clients requesting a particular service and additionally compare with existing distributed computation designs(if there were any during that time).
5. Comments/Confusion
How does the server estimate the exact time-out in order drop an idle connection/detect failure? Did not follow the binding scheme on reboots.

1. Summary: This paper presents the first ever practical implementation of Remote Procedural Calls, a concept widely used for distributed computing today. The authors explain the design decisions, motivations, and optimizations for their implementation of RPC.
2. Problem: The idea of RPC, and computing over a network, had been present for some time. But the complexities associated with the usage of communication between programs, made the programmers reluctant to modify their programming model. The authors aimed to keep their RPC implementation transparent and general, so it can be adopted easily and widely. At the same time, they wanted it to be efficient enough, so that communication is not the most expensive part of the program. If so, people would avoid it once again. They also had to deal with the problems of security and reliability, which are ensured in local procedure calls by the OS.
3. Contribution: One of the key features that led to the wide adoption of RPCs is their close resemblance to local procedure calls, a concept widely used and understood. This is an excellent starting point to have, while implementing something new. They also made a pretty general implementation, upon which future work could be done. For example: They avoid using shared memory for communication. This would have been a pretty strict assumption. Infact, protocols like LRPC use it as an optimization over RPC. They also go ahead and bypass the network stack to make their implementation fast. Had they used protocols like TCPs, they would have spent a lot of time in ACKs just to establish the communication! They also borrowed from Nelson’s thesis and used stubs, a concept still used today, even in OSs to support features like dynamic loading. One other feature I liked was their use of a central Grapevine database to store exported interfaces, thus freeing the burden on server’s memory if there were a lot of clients. They also think ahead, and provide extreme flexibility in their RPC call: a client can either specify both the interface name and instance, or just the name (in which case the best possible server would be bound to it), or even the server’s net address, if need be. Additionally, they implement security via Grapevine’s access lists and caller ids. These caller ids also provide the benefit of identifying a particular call, so it can be identified, and not re-executed, in case it is re-transmitted. I also liked their graceful exception handling by sending exception packets. The concept of probe packets in the absence of of a time-out feature is also noteworthy. In hindsight, their design decisions proved good enough for the system to still be in use today, although a bit updated!
4. Evaluation: They compare the performance results of RPCs with local calls for functions with arguments and return values varying from 1 to 10 in number. Although RPCs are evidently slower, their aim was not to compete with local calls for latency. They do this for ease of use. It would be unfair to judge their evaluations since they mention some evaluations are in Nelson’s thesis, and future papers. Though I would like to see the results for memory usage in the central Grapevine server, since that might become large with increasing number of servers and clients. I would also like to see the results for a heavy traffic network, a rare case those days. The performance results with encryption are also missing, and are important since that would give the final end-to-end performance measure. Also, with their light connection-establishment protocol, it would be interesting to see the actual performance benefit because of it, compared to other transport protocols. I would also like to see the stage-wise latency measurements (for eg. time spent in stubs), which would give a better idea of where to optimize further!

5. Confusion: The authors say they have some facility to watch a process, and abort it if it is in deadlock etc. What was that feature? How is RPC implemented today? Do they still use probes? It seems like this could generate huge traffic. What happens on Grapewine server failure? Is it also distributed?

1. Summary
The paper revisits the idea of remote procedure calls (RPC) and optimizes the design parameters for ease of use, efficiency and security. It elaborates the design and points to future avenues (eg, RPC protocol optimization) which would help in scaling the system for wider deployment.

2. Problem
At the time of writing this paper, RPC implementations were rare and the existing designs did not address communication failures, ease of use with high level languages, choice of network protocols and data integrity and security. The author’s design aims to solve these problems.

3. Contribution
Major contribution of the paper is their RPC design and its implementation into an existing network of computers.
(i) RPC structure: The proposed design breaks RPC into 5 entities namely, user, user stub, RPCRuntime module, server stub and server code. Programmers write distributed applications on the user and server part of the design and RPC function call is no more than a simple function call to the kernel. Stubs are responsible for converting them into packets and handle them to RPCRuntime. RPCRuntime is responsible for handling the internode communication and ensures efficient delivery.
(ii) The paper explains various naming conventions done to improve the efficiency of binding an importer to the exporter. The grapevine database maintains exporter instances details along with a sequence number which the importer can query. The importer has the option of requesting one particular node or the database can assign one if no preference is specified. Duplicate sequence number helps in detecting server crashes and thus helps in fault detection. The grapevine database also encrypts the communication with importer and also restricts the set of user who can export interface to the database and thus ensures data integrity and security.
(iii) At the communication level, the paper elaborates how it does simple single packet communication and multiple packet complex function call execution which shows the scalability of the design. The design emulates Mesa’s exception handling mechanism and distinguishes exception from communication failures and avoids loading network traffic. Also, paper claims that is results indicates that optimizing communication protocol for RPC would yield 10 times speedup.

4.Evaluation
The evaluation of the design presented in the paper is bare minimum. It just tabulates RTT latencies for different packet sizes and message counts. Also it shows the time for situation that leads to exceptions. The authors have added various features to the RPC like encrypted data packets and fault tolerant network protocol and knowing their overheads on the overall execution time would been interesting to know. Also network traffic affects the performance of RPC calls and the paper does not talk about design’s ability to handle such plausible extreme conditions. Also, it does not talk about Grapevine’s ability to handle large number of request or how does it scale with large number of nodes in the network (Usual point to talk about when there is a centralized server.)

5. Doubts
How impactful was this work on the future designs of RPC?
The monotonicity of the sequence counter is used in fault detection. What happens in case of an overflow?
How scalable is this design?

Summary
This paper describes the design and implmentation of RPC package having simple and clean semantics that will make the building of distributed applications easier. The paper discusses the major decisions made on the RPC design, binding mechanism, communication protocol and the optimizations adapted.

Problem
Even though RPC had been conceived many years back, a full scale implementation of the RPC was missing. Additionally, while building applications that use RPC, the designers face problems like figuring out a proper semantics to handle failures, how and who does the binding, what communication protocols are better suited and how to provide data integrity and security in an open communication network. Such dilemma ended up making the system complex and divert the attention of the designer from the application logic and worry about the internals of RPC support. So, a need to have a clean and simple semantics for RPC arise that can make distributed development easy while ensuring security too.

Contribution
There are two major contributions of this paper. One is to isolate the communication protocols from the application logic. This is done by RPCRuntime whose primary responsibility is to handle binding, transmit/receive packets to/from callee/caller and fault handling. RPCRuntime can also handle encryption based security for calls and results so that eavesdropping, modification, replay and creation of calls can be detected.

Secondly, the designer have to only decide the interface and user/server code and not worry about the data conversion or how the remote procedure calls are made. The stubs are automatically generated that handles the packing/unpacking of the arguments and helps in realizing the semantics of remote procedure call to be as close as possible to local procedure calls.

The package is also available with exception handling where exceptions are transmitted to the caller instead of the result. The RPCRuntime on the caller side responds to these exception packet appropriately based on how the catch phrase is defined.

Evaluation
As the paper is not about RPC vs. the rest of the world, I dont expect any comparison of RPC with other communication mechanism. Security related evaluation is also not expected as this paper is not about security. SecureRPC paper should deal with that.

The authors evaluate their design on variable size of the arguments and result by measuring the elapsed time for 12000 calls on each procedure. The evaluation shows that as the data becomes larger, the transmisson costs becomes more prominent in the total elapsed time. The authors accept that RPC is not good for transferring large amount of data.

Even though RPC design is in the initial stages, I would like to see how much time is taken for each step whenever RPC is invoked. That would help in clearly understanding the costly operations and is there a room for improvement as the authors have talked about couple of optimizations. Looking at the performance results, if we sum the (client + server) implementation time of the procedure mentioned in local-only column and the transmission time, they constitute about 10-20% of the total elapsed time. Rest of the time is spent inside the stubs and RPCRuntime. This number looks significant and can worsen whenever thousands of RPC calls are issued on the server. This numbers therefore raise an issue of how scalable RPC is when thousands of clients connect to the server?

Confusion
I am wondering if addition of Grapevine is really necessary or not. It can be a single point of failure leading to 100% downtime. How would a decentralized design look like compared to the current design.

1. Summary
This paper describes the design and implementation of an Remote Procedure Call (RPC) facility. The paper also discusses the design decisions, binding mechanisms, transport level communication protocol and performance results.

2. Problem
Existing RPC facilities were cumbersome to use and lacked the necessary bindings and semantics. Many of them were not secure and communication failures were hard to handle. The authors aim to implement a facility which makes RPC's as easy as local procedure calls. They also wanted to improve security and communication efficiency to make distributed computation effective.

3. Contributions
The primary contributions are:
- Use of stubs and RPC runtime to handle communication and improve security. This abstraction also improves the usability for programmers and hides all the implementation details
- Use of subsequent packets to implicitly ack previous packet minimises the time taken to obtain results
- Use of unique identifier schemes allows calls to be made only on procedures that have been explicitly exported through the RPC mechanism improves security.
- Maintaining a pool of idle processes at callee reduces the cost of process creation
- Using grapevine database and unique identifier binding to track exported procedure interfaces
- Use of Lupine to generate stubs based on interfaces
- RPC doesn't require connection handshaking which is expensive.

4. Evaluation
The authors built their system using the Mesa programming language on Dorado machines connected via Ethernet. The authors compare latency measurements of their RPC package with a local procedure call and present the performance results. The authors additionally mention that interleaving RPCs from multiple processes would lead to an optimised byte stream implementation. However, this evaluation isn't nearly sufficient to supplement all the design and implementation choices.

5. Confusion
How to distinguish between exceptions that occurred on the callee to that from the communication network ?
Why are probe packets sent every 5 minutes ??
How to detect faulty callee when RPC runtime on callee transmits the ack ?

1. summary

This paper is about the design and implementation of remote procedure calls in the Cedar programming environment to simplify distributed computation and the ease of using RPCs. This was achieved by implementing stubs using RPC runtime and the lupine program, using the Grapevine distributed database for RPC binding and by binding an importer and exporter to interfaces.

2. Problem
The existing method of constructing communicating programs was complex which made distributed computation a task that could be taken up only by researchers with substantial experience. Additionally , there was a desire to make RPC mechanisms more efficient thereby improving the adoption rate of RPC by developers. Lastly , since the previously implemented protocols did not take security into consideration there was demand for developing a protocol that did take security into consideration.

3. Contributions

The RPC design is based on the concept of stubs introduced by Nelson in his thesis. There are five components to any RPC call : the user , the user stub, the server , the server stub and the RPC runtime.The RPC runtime is present on caller and callee machine. The user makes a call by making a call with same semantics as a local call.The stub marshalls and un-marshalls the messages at both the user and server side.These stubs are generated by the Lupine program.The generation is done using Mesa interface modules.These modules greatly simplify the process of developing user and server programs. The RPC runtime performs the transmission, acknowledgement monitoring and encryption.

The importer of an interface is bound to an exporter of the interface.Following which calls made by the importer invoke the exporter's procedures.The name of an interface includes a type and instance.Type represents the interface the caller expects from the callee. The instance defines which exact implementation of the interface is required. The Grapevine database is used for RPC binding. The RPC runtime maintains a table on the exporter which maintains along with interface name , procedure and server stub, a 32-bit unique value that acts as an identifier for the export.

A RPC packet transport level communication involves both simple and complicated calls. The caller will re-transmit the message if the does not receive a acknowledgement from the receiver thus compensating for any packet loss.When messages are re-transmitted , they are modified to request for an acknowledgement. Once the acknowledgement has been received it additionally sends probe messages until it receives the response. This handles the problem of the callee crashing. Lastly , if the arguments do not fit in one packet they are sent through multiple packets.

4. Evaluation
The implementation is evaluated between two Dorados connected by Ethernet with low load.They measured the time from when a procedure call is made to when the response is received . These measurements have been done for multiple procedure arguments and for local and RPC procedure calls. While they have provided the mean , median and transmission time for an RPC and the time for a local call, they have not measured the time for the individual steps in the RPC process. Clearly the time taken by an RPC procedure call is much more than that by a local call, they could have empirically shown which step/steps of the RPC call is causing the latency problem.
5. Confusion
It was tough to understand the timeline and prior work done when this paper was published and to clearly distinguish new contributions from existing work.

1. Summary
In this paper, the authors talk about their implementation of RPC and the design choices that had to be made when making a real, working RPC. The authors also provide some optimizations and leave the door open for future areas of research, such as added security layer.
2. Problem
Before this paper, RPC was mainly talked about theoretically, but no full implementations were out. In the past, many different ways of designing a RPC system were discussed, but to actually deciding on design choices and reasoning about them to make a real system was never done.
3. Contributions
As a result, the authors decided to make a real RPC system and explain the design choices they made and why those choices were made. Their main goal was to make an RPC system that makes distributed computation easy, so that the real issues of distributed systems become the main focus.
The system includes user program, user-stub, RPCRuntime on user side, RPCRuntime on server side, server-stub, and server program. The user program can use the auto-generated user-stub to call a procedure on the server side, and the user-stub communicates this information to the RPCRuntime, which handles all the communications to the RPCRuntime on server machine. The system also includes a database to find server machine’s address based on the type and name, similar to a DNS server.
The RPCRuntime implements it own transport layer protocol to avoid heaviness of standard transport protocols. The authors describe an acknowledgement protocol to transfer packets between machines. However, their protocol sends and awaits an acknowledgement sequentially, which works okay on local networks but would be very inefficient on larger networks. The authors acknowledge (haha) the fact that a standard transport protocol might work better for bigger networks, and a dynamic switch between protocols is a possibility.
The authors also explain that they use signals to notify programs about exceptions/errors that happened while trying to do a remote call. In addition, since fork is expensive, the server machine keeps a pool of idle processes around and uses a process from this pool when a request comes.
4. Evaluation
The authors run calls with different number of arguments and data sizes and compare the results to a local procedure call. This shows that much of the latency is really due to the network and communication. As a result, RPC should be a focus of research to make the system much faster to remove some of the significant latency. They do not compare to any previous systems because no previous systems existed then, which is reasonable. It would have been interesting to see how the system performed under heavy network use, with high possibility of packet drops.
5. Confusion
What transport protocol do modern RPCs use?

1. Summary
The article describes the Remote Procedure Call (RPC) mechanism developed by the authors. It gives a detailed view of binding and transport mechanism explaining various design decisions and optimizations done from the previous works to develop an efficient mechanism which can scale well as the number of clients grow.

2. Problem
The existing communication mechanisms were not very well understood outside a select group of experts and it was a major hurdle to the development of distributed systems. Due to this full scale RPC implementations were rarer than the research papers. RPC is a very natural extension of a procedure call which is easily understood by the programmers, and the authors believed that if they abstracted out the complexity of communication and make RPC as simple as a local procedure calls, more people would be encouraged to build and experiment with distributed systems to take advantage of the numerous powerful communication networks and computers.

3. Contributions
The authors' primary goal was to make distributed systems' development easier and proliferate them further into open networks. This called for secure communication for transferring data for RPC and this paper is one of the first works on RPC to talk about security. The guiding principle for the design was to make RPC as close as possible to a local procedure call from the point of view of programmers, so they made design choices like having no time-out mechanism for RPC call as long as the Server processing the call is alive and can be contacted. The server which was exporting the RPC interface did not maintain any client state making the mechanism very scalable, the unique identifier scheme implicitly broke the binding if the server crashed and it allowed the client access to the procedures which are explicitly exported by the server enforcing some access control. Apart from this, the use of Grapevine database which provided access control lists for updates allowed only registered servers to provide services which was again a very good mechanism to prevent man in the middle attacks. Another good convention introduced by the design was to break the interface name into 2 parts: type and instance. This allowed for clients the flexibility to provide only the service type and the binding mechanism would find a suitable server to connect, this is very useful for ensuring a low service downtime because if a server to which the client binds crashes and does not recover then the client can try to bind to another server which offers the same service.
The design of communication protocol allowed overloading data packets as acknowledgements if the RPC call duration was less than the transmission interval minimizing the elapsed time between the initiation of a call and getting back the results. Another contribution I feel worth noting is the propagation of an exception in the server to the client, this can help the client programs to be more robust if they have exception handling code. The design also adopted the mechanism of starting several server processes which can handle RPC requests, this was a good design decision considering process creation is costlier than moving idle processes to the run-queue.

4. Evaluation
The authors claim that Nelson's thesis from which they take a lot of idea has extensive analysis of various RPC protocols and implementations. So they have done minimum performance evaluation with a default configuration and no encryption. Some results which I would like to have seen are - how the increasing number of RPC handlers in server affects how the system scales with respect to the number of clients that can connect to a single server and how the latency and throughput of the number of RPC handled varies according to the Maximum Transmission Unit(MTU) size of the communication protocol. Another interesting benchmark would have been seeing the latency and throughput of the system when it is handling complicated data structures like trees and graphs as RPC arguments or results.

5. Confusion
If a service provider is written in Mesa then is it possible to write a client in any other language like C or SmallTalk? Was the stub generator intelligent enough to develop language agnostic code?

1. Summary
While RPC has previously been discussed on paper, Birrell and Nelson are the first to make a real implementation. They discuss the goals of RPC and break down its structure on both client-server and process levels. They also create a packet-level transport protocol. An experiment is conducted testing RPC versus local-only calls.

2. Problem
The authors propose a mechanism for transferring control and data across communication networks as opposed to just locally. This idea has been around for a while but rarely done in practice. There are several issues associated with it, including failure handling, address-handling, data control and security.

3. Contributions
The authors seek to adhere to one core principle: the semantics of RPC should be as similar to local calls as possible. To facilitate this, they use auto-generated stubs to translate between the client and the server. Essentially, the stubs are responsible for packing and unpacking argumnets and results, which means that the programmer doesn't have to care about tailoring their code for their specific process. The exception is that programmers can't use arguments or results that rely on shared address space, because RPC explicitly avoids that mechanic.
The process works as follows: there is an importer and an exporter interface that have to be bound together. The exporter calls the procedure ExportInterface that calls the central database (Grapevine), which then records the information about this interface in a table. An importer then calls its corresponding procedure, ImportInterface, which asks the database for the network address that can serve as the connect-site of the importer. If there is a corresponding exporter, this call succeeds, otherwise, it fails. If no specific instance is specified by the importer, then Grapevine will provide the names of all exporters of that type, and the importer will bind to one of those instead.
To facilitate communication, they created their own protocol. This protocol is based off PUP byte streams. At its simplest, a call packet is sent from the caller to the callee containing data and arguments. The callee then returns a result packet containing the results. Caller and callee try to use the same process ID throughout. The caller retransmits until an ack is received, mostly in the form of the result packet. If a call packet is too big, it will be split up into packets that have to be individually acked, resulting in alternate transmission between caller and callee. Each call has its own sequence number ID, and these do not have to be sequential. If a callee takes too long, a caller may send a probe packet to see if there was a communication failure. This protocol seems rather awkward from a modern point of view, with the “alternate transmission” style standing out. Even though each data packet has its own individual sequence number, their protocol doesn't support single acks for multiple packets. The sequence number is used only to weed out duplicates. In addition, they make no mention of what happens if the results are too big to be sent in a single packet.

4. Evaluation
Their system is built on the Cedar programming environment, which emphasizes “uniform, highly interactive” user interfaces. They test their interface by running a series of RPCs on their system and recording minimum, median times as well as transmission times for both RPC and local calls. It's evident that as the data becomes larger and larger, this form of RPC quickly becomes very unwieldy with massive transmission times. For instance, a 100-word array procedure requires 1219 microsecs as opposed to just 98 on local. They acknowledge this, and they also state that RPC is in its early stages and needs more work to be done. In addition, security is not involved in the testing at all, despite their statement that security is one of their main concerns in RPC. They effectively outsource this to Grapevine instead of having it inherent in the protocol.

5. Confusion
Why in the world would they purposefuly constrain the rate of calls on their ExportInterface to an average rate of less than one per second? That seems woefully slow. Also, TCP had come out a year prior in 1983, but they don't mention it at all even though TCP has improvements that could make the protocol less unwieldy. Any reason why?

1. Summary
RPC uses network interface as a message communication method. The communication is established between a server and clients with Grapevine which tells which interface is available and what specific type is currently being used. A client calls a RPC like a local procedure call, and a stub combines or decodes all the information including destination and input parameter into or from packets.

2. Problem
The remote procedure call (RPC) has been widely studied while it has several difficulties: how to cope with the possibility of machine and communication failures, and how to recognize the sender and receiver, and how to provide data integrity and security, and suitable protocol for transfer of data and control.

3. Contribution
Main contribution, in my opinion, would be to build RPC for actual use because most of the details are already implemented or addressed in another paper. It addresses how to bind a server with a client and how to communicate between server and client explicitly.
RPC uses conversation identifier to recover from crash or restart. It’s not easy to understand how it recovers binding and communication.
RPC uses handshaking method for communication between client and server. After calling the procedure call to server, if there is no acknowledgement from server, the client periodically sends probe packet to monitor whether server is currently working or not. In addition, idle server process, remaining in idle even if there is no job, handles incoming packet instead of process creation to improve the performance of RPC. Furthermore, the processID in the packet is used to bypass the packet directly to the process without additional handling, otherwise Ethernet interrupt handler send the packet to idle server.

4. Evaluation
Evaluation is conducted with various packet size. The performance, speed of transaction per unit, is improved as the size of packet increases. It seems like they have conducted point-to-point communication experiment. They might need to conduct more evaluations such as many traffic from many systems, and different jobs concurrently, and need to compare the RPC with other protocols. Furthermore, the paper said that all the evaluations are done already in previous work therefore they don’t need to do it again. By the way, I think they should evaluate their work again because they add some protocols into previous work.

5. Question
1. How to generate user and server stubs automatically?
2. If a server crashes or restarts, how does the server re-bind broken bindings?