CS 736 - Spring 2007 - Paper Discussion

Summary:

The paper describes Remote procedural calls (RPC) which are used for making procedure calls over the network. The application programmer can continue to use the same semantics for a procedure call that another machine on the network executes.

Problem:

No standardized mechanism existed for simplifying distributed programming. The performance of the mechanism should not bias the application programmer to avoid using the network. Simplicity while keeping performance is desirable.

Contributions:

RPC seems to be the first mechanism of the time which provided some standardization for a distributed programming model. The preservation of semantics from a procedure call to a remote procedure call simplifies the job of an application programmer.

Abstraction of the network from the programmer while providing security is desirable. Also the naming and location method for instances provides a transparent service while adding to the security of the model.

Controlling the number of process per request is also clever way to improve performance.

Flaws:

RPCs aren't used for distributed programming as pervasively as the authors would have envisaged due to better design choices available to the current distributed application programmer.
The RPC environment was envisaged to provide procedural call semantics to work over the LAN. Procedure calls may or may not suffice for general enough for all kinds of distributed applications (The authors do mention this). Although in 1984 it may have been hard to imagine the Internet, high speed WANs and co-existence of heterogenous networks, what naming and location service might be best suited.

UDP like communication is thought of, even then the network communication had room for improvement. This again happened over time and as the architecture is designed such that the network layer can be changed anytime.

Relevance:
RPCs were adapted in places only where the problem could be solved over the ethernet where low latencies and low congestion was present, as the procedure call semantics had the basic programmer assumption about speed.
Web services architectures have emerged which are similar in essence to RPCs.

Performance:
The paper's focus was on performance - They kept in mind that RPCs were always in an order of magnitude of a procedure call happening locally. The number of processes forked were controlled. Some fancier network level tricks could have been done for further optimization. Naming and location are time consuming. Better choices on the part of the application programmer may improve performance.

Summary
This paper presents a remote procedure call system which allows robust
and fast remote procedure calls across a network.

Problem
The primary problem that this work is trying to solve is the problem
of making distributed computing easier to program. Prior to the use or
remote procedure calls it was necessary for application programmers to
deal with details of the network protocol involve as well as how to
architect the flow of data.

Contribution
The main contribution that I see in this paper is the ability to use
remote procedure calls in a manner similar to local procedure calls.
Meaning that the programmer does not have to worry about the network
protocol or about synchronization issues. This is very powerful
because the application programmer can write distributed systems in a
similar fashion to regular applications.

Flaws
In general the concepts presented in this paper were solid. My only
criticisms ire that this programming model may be inappropriate for
some applications, and that they do not compare the performance of
this model to other methods for creating distributed applications.

Performance
This paper was not as much about performance as it was about making
creation of distributed systems easier for programmers.

Summary:
The paper talks about design an implementation decisions for Remote Procedure Calls (which was not a concept introduced in this paper).

Problem:
One of the most difficult tasks in developing distributed computing applications using RPC was the getting the communications part right (networking details, protocols, differnt programming languages doing communication differently, etc). In other words, more effort was spent on the non-core part of the application (i.e. communication - or sending the control/data across to another machine), than the core part (the application itself). The idea of the paper was to come up with an RPC implementation that makes distributed computation easier, so the developers can focus on getting the appplication right without worrying about the communication part.

Contributions:
- Automatic generation stubs from well-defined interface modules. I believe this is a novel idea, though use of stubs by itself is not novel.
- A look-up service to locate an implementation of a given interface. THe service also provides a way to do load-balancing, by allowing queries such as 'give me all implementations of this interface'
- Simulating the RPC exactly the way LPC works - no timeouts (other than communication/host failures), possibility of collocating caller and callee on the same machine/process without requiring any change on either side.
- Using same mechanism for different languages. The RPCRuntime was implemented for different languanges; theoretically allowing a client written in one language to talk to a server(implementor) written in another language (for e.g. helps UI development in one language and backed in another).

Flaws:
- One of the major flaws in the implementation was waiting for ACK for each packet sent. This results in high inefficiency, especially over networks with long RTT. It simplifies implementation of RPC (with no buffers to manage, less consolidation to do), but severely impacts performance.
- Seems like the option of running RPC on other transport protocols were not considered much. With the give implementation, the RPC will end up doing most of the transport work (congestion management, retransmission, etc). This kind of goes against their own philosophy a little bit (they wanted to relieve application programmers from doing communication, but they dont reuse for their transport part)
- The evaluation was not much. It was done in a skewed setup - disabled encryption, 5-10% of network load, not measured on long-haul network, etcc.

Relevance:
I think many of the concepts are extremely relevant today. The idea of abstracting RPC the same way as LPC allows application developers to focus on what the application itself. This is an idea used by CORBA as well (defining Interface, automatic generation of stubs, etc). The name lookup based on interface only and interface/implementation, technique used by CORBA now, also allows complete location transparency - one of the major enablers for loadsharing and fault-tolerance.

Summary:
Birrell and Nelson provide an overview of their design and implementation of RPC. The paper provides pretty decent explanations of their design decisions, such as opting for "clean and simple semantics", considerations for efficient communication over a network, program structuring conducive to RPC, and provisions for data protection.

Problem:
Distributed computing is hard. Who knew?? Anyway, as the authors themselves say: "the primary purpose of our RPC project was to make distributed computation easy." The systems at the time were apparently quite complex, so in order to increase researcher utilization, a simple and efficient method for distributed computing needed to be created.

Contributions:
I believe the "biggest" contribution of this paper was the idea that RPC semantics should be as much like a local procedure call as possible. This idea likely originates from the decision that procedure calls as the paradigm for control and data transfers (as opposed to something like message passing). Otherwise the authors would have focused on reducing the complexity of whatever else is capable of controlling and data transmission. At any rate, the authors make some bold decisions in their attempt to create simple procedure calling; they eliminate emulation of shared address space between hosts, and they eliminate the concept of a timeout.

The concern for efficient and secure networking was also an important contribution. Using Grapevine seems to be a pretty big win, as it provides for very easy host lookups. The addition of a customized transport protocol seems a bit extreme, but common sense suggests that abandoning the overhead of typical (TCP?) protocols would result in a pretty decent improvement in execution time.

Flaws:
It seems as though the authors result to neat hacks to improve performance (like bypassing software layers!). This suggests that RPC might not be terribly efficiently on its own merits.

I'm not entirely convinced that their stateless server idea was good, as we can see that the authors resorted to a lot of tricks to increase efficiency including the use of subsequent packets for implicit ACKs of previous packets. This implies that the server has some sort of state.

Since the authors apparently had a working RPC implementation, it is a bit strange that they didn't include more information about performance. I would be particularly interested in seeing how RPC with complicated procedure calls performs against an RPC implementation that uses TCP.

Relevance / Performance:
Well, the absence of any meaningful performance data makes it difficult to assess the performance of this RPC implementation, but the relevance of the paper is easy to grasp. By creating a relatively simple and (hopefully)efficient way to execute procedures remotely, the authors have reduced the barrier of entry to distributed computing immensely. The authors also display an admirable concern for security and exception handling.

Summary
Proposed here is a mechanism for remote execution of procedures on different machines connected together by a network. The work is based on and extends the mechanism of local procedure calls already in existence.

Problems Addressed
The authors propose a remote procedure call facility that behaves, to the user, very similar to the current local procedure call mechanism. Thus most of the problems addressed here deal with the additional challenges of implementing the procedure call mechanism in a distributed fashion. The RPC package was designed to have simple semantics, while being efficient and able to handle failures of either the caller or the callee machine. Data security and integrity were also important aspects of the work since it is based on the assumption that the interacting machines are talking over a potentially insecure network.

Contributions
The RPC mechanism is built around the use of user and server stubs on the respective machines interacting with the user and server in a similar manner as local procedure calls. The job of the programmer, who is writing a specific procedure call, is made easier by allowing the programmer to specify the desired interface which is used to then automatically generate the code that does the actual manipulation of the data before and after it is sent out onto the network. The system utilizes a type of name server to translate a request into a machine address. This allows for flexibility and also allows for multiple machines to accept the same type of RPC , the specific call goes to the closest server. A nice optimization proposed for short calls to improve efficiency was that no acknowledgment of a sent call was required if the call returns before the callee expects an acknowledgment.

Flaw
I thought it may have been nice to see some data to compare available packet-level transport mechanisms before deciding to build a new one. Though it seems like the proposed protocol is very efficient for use with RPC it may have been nice to see the difference to make the point of redesign stronger.

Performance
The two main elements of performance that were addressed most strongly here I would say are predictability and efficiency. By making the system perform very similarly to the local procedure call mechanism people already familiar with that mechanism would have no difficulty also using the RPC mechanism. By presenting a new packet level protocol, optimized for the task, the utilization of both the callee and caller machines in addition to the physical network resource were a concern and it can be seen the authors were thinking about efficiency.

Summary :
This paper describes a key concepts and an outline of the Remote Procedure Call (RPC) which enables a user or a program to invoke another program on different computer using via network communication with simple interface.

Problem :
At the time this paper was proposed, it was difficult to implement distributed computing environment or programs that interact with each other via network, because the existing communication mechanism was complicated. More simple, efficient, powerful, and high speed RPC was needed to encourage programming for distributed computing environment.

Contributions :
Local call “like” RPC
The authors propose a RPC which is “as close as possible” to local call by providing simple, powerful API and efficient and speedy communication mechanism and architecture. Getting rid of time-out mechanism is one of an example for making the API simple instead of making a fancy interface customized for network. These simple interface also encourages programmers writing a program for a distributed computing environment.

Scalable Naming
It was really interesting that they were using database system to bind both sender and receiver sides’ interface. This enables to control the rights to invoke the RPC and also this solution should provide more scalability on managing the company network since we could just add entries to one place for all nodes and it is efficient mechanism.

Reliability and Efficiency
ACK mechanism which the sender could chose to require or not require the ACK from receiver makes the communication reliable and still efficient. Also, using a secure communication protocol could protect the node (server?) from some malicious nodes which sends many packets to us.

Flaws :
Even though the main topic is to introduce the concept of RPC, since they have implemented the package of RPC it might be better if they have more quantified evaluation which shows the advantage of RPC than some communications via network. Also, overhead of RPC is still a little large. If it is in current network infrastructure, the percentage of overhead will increase.

Performance and Relevance :
This paper makes the first big step for starting distributed computing into a not so big step. I was impressed that they were concerning about the security on OS alert…
Because the network is getting faster, storage is getting larger, people starts to share resource or use a rich server and RPC will be very important to use those remote resources efficiently.

Summary:
The paper describes the Xerox PARC implementation of RPCs, which is a method by which inter-computer communication can be made to mostly look like simple procedure calls by wrapping the communication parts.

Description of Problem:
Existing communication mechanisms were clunky and hard to use, and the authors wanted to encourage the use of RPCs by making it easier.

Contribution:
A reasonable-sounding implementation of RPCs. There are a number of possibly important optimizations, such as:
* Having the protocol support implicit ACKs in the form of results or another call in order to reduce network traffic
* Support for pretty high-level language features such as exceptions
* A protocol that provided end-to-end security if desired, something that was new at the time

Flaws:
I don't like how they didn't measure performance with encryption on. That could have made a substantial dent in their RPC implementation. (Though as processor speed increased since then, the proportion of that dent in relation to the communication overhead would I'm pretty sure be rather less than it was then.)

The authors also say they intended RPC to become the dominant protocol. I have two issues with this. First, I'm not convinced that small workloads would be the dominating nature of communication, and thus a protocol designed to allow light-weight transmissions of small datagrams wouldn't be ideal. Second, they say that their optimization of removing layers of the network stack was somewhat of a cheat because it's making it a special case. But they then go on to say that it is a special case because they expect it to become dominant -- but if it's dominant, I think it's a stretch to say it's a special case. And it's not clear from their description whether it becoming dominant would make this optimization less effective in the same way as creating "ten special cases" would make it less effective.

Performance:
The goal of the paper was to improved the ability of programmers to scale-out by making it easier to make programs that communicate. I also think in some sense this might have been a way to try to increase utilization across their network. However, in order to do this effectively, they also had to be concerned in particular with the latency of requests and the amount of network traffic they would create.

Summary

In this paper the authors propose a remote procedure call paradigm for communication across network between programs written in high-level language. The authors’ main goals are to provide mechanisms which make distributed computation easy and RPC communication highly efficient and secure.

Problem Description

The authors claim that the existing remote communication mechanisms are overly complex and are a major factor constraining development of distributed computing. In order to solve this problem, the authors are proposing RPC mechanisms that are easy to use, are efficient, and secure so that distributed computation becomes easy.

Contributions

A summary of contributions of this paper are as follows.
1. The authors provide an abstraction between the network hardware and mechanisms for remote procedure calls. As a result, the programmers do not have to worry about the complexity involved in transmitting and receiving packets over the network, lengths of the packets, synchronization protocols, etc. Due to this abstraction, the programmers can treat a remote procedure call just like a local function call.
2. The authors propose using Grapevine distributed database of RPC binding. This can make the RPC execute quite efficiently. Without the database, the callee’s address has to be hard-coded in the caller code which can add unnecessary constraints.
3. Even though the authors do not go into details but they propose using encryption based security for transmitting data between caller and callee. Security is quite important in distributed environment as data being transferred via an RPC call can be hacked over the network.

Flaws

Some of the flaws in this paper are as follows.
1. RPC has an inherent communication overhead. When ever a procedure call is made, data has to be transferred from caller to callee and the results are to be communicated in the opposite direction. Thus, the authors’ initial claim that distributed computations are constrained by complex remote communication mechanisms is some what flawed. Distribute computations are also constrained by the communication overhead involved. Thus, it is also quite important to make the RPC mechanisms quite efficient.
2. The authors’ evaluation of their design is quite weak. The primary goal of the paper is to make RPC easy to implement but they do not compare how easy it is to implement a distributed computation using their approach as compared to some other approach. Secondly, the authors also do not compare the performance of their RPC model with other existing distributed communication models. It would have been interesting to see how much overhead is incurred by using the RPC model as compared to other models in which the developers have to implement the detailed communication related code.

Performance
The authors’ main goal is to make distributed programming easy. Using the RPC model might not improve the performance of an application as compared to using some other distributed computation model but it can definitely reduce the time to develop the application. In order to achieve this goal the authors present an abstraction between the distributed application and the underlying communication details.

Paper Review: Implementing Remote Procedure Calls [Birrell & Nelson]

Summary:

This paper presents remote procedure calls (RPC). An implementation of
RPC permits programs, running on different machines, to communicate
across a network to invoke each others functions - a form of distributed
computing.

Problem:

The problem addressed is how best to enable, or perhaps retrofit,
distributed computing into programs that typically just make function
calls executed on the local host.

Contributions:

RPC has a lookup service used to find and bind RPC callers and callees.
This is forward-looking in that it provides a level of indirection
between services/servers and port/machine identities on the Internet.

RPC, as implemented here, offers a coherent two-level structure on both
the caller and callee sides, so called "stubs". This enables the
programs to call what appear to be normal (local) functions, but then
the arguments get translated into a form amenable for sharing across the
network (i.e. network-order, portable formats).

The primary contribution I see to RPC is in the relative ease to
retrofit into existing applications, since its APIs, as much as
possible, look like "normal" calls. For instance, a coworker of mine
recently used it to replace a function call that writes data to a local
file with an RPC call that send that data to a daemon that cached it
elsewhere.

Flaws:

The lookup service by which RPC clients and servers rendesvous, while
coherent, has not proven to be a particularly attractive design.
Instead the DNS has primarily been chosen instead, accompanied by custom
application protocols that could use RPC, but don't, such as NTP,
Dynamic-DNS, and instant messaging. RPC is rarely used in new
networking applications, and other, newer, self-describing formats have
been chosen for portable data representation.

The RPC design is not as general, to fit all applications, as stream and
datagram sockets APIs. For instance, one couldn't nicely implement HTTP
atop RPC; HTTP benefits from stream response delivery so that it can
begin processing a response before receiving it in its entirety.

Performance Impact and Relevance:

The impact of RPC is not so much in improving operating system
performance as it is providing a new software structure that can, nearly
transparently, make calls to remote programs that might either perform
unique or processing intensive services. Other implementation details
have since been changed; SunRPC, as we now use it, uses UDP for
transport. The most heavily-used RPC-based application is probably NFS.
It hasn't been utilized for pervasive distributed computing as
presumably envisioned.

Summary
The paper describes the components and network protocol of a well performing remote procedure call architecture.

Problem
The authors wanted to be able to make remote procedure calls across a network with a quick and simple interface to facilitate distributed computing.

Contributions
The process of making a remote procedure call was abstracted to behave very similar to a local procedure call. The paper presented three layers of abstraction: application, stub, and RPCRuntime components. The user code calls a stub automatically created by Lupine. The stub handles packing and unpacking messages and hands off data to the RPCRuntime, which manages network transmissions.

A central grapevine database manages matching callers with callees and restricts those who can export a service. The Grapevine allows for three levels of destination specification when conducting a RPC: general call type, specific call instance, specific network address. This allows callers to be dynamically matched with suppliers.

The paper also presented a number of implementation details and a network protocol used to increase performance of RPCs. The transport protocol is highly tuned for small packet transmissions, ex. ACKing every packet. An idle process pool is used on the server in order to avoid process creation and teardown delays. Subsequent requests are directed towards the same process using the process identifier. Allowing one less ACK in the common case.

Flaws
I would have liked to have seen more of a justification for the binding location mechanism. Possibly due to my lack of distributed programming experience, I do not see why three levels of specification are needed. I would imagine that both the client and server applications would be written by the same author (the 100 fold increase in execution overhead makes small remote calculations impractical). I can imagine many cases where a static IP (specified at either compile time or on startup) is all that will be needed to locate the exporter. If both the client and server are written by the same person it seems a more efficient resource locator could be created in the case it is needed. I’m not convinced the benefits of a general purpose resource locator outweigh the overhead imposed.

Performance
The paper is attempting to improve scale-out by easily allowing remote procedure calls over the network. Which allows the application author to leverage more machines easily.