*J. H. Saltzer, D. P. Reed, and D. D. Clark. 1984.* [*End-to-end arguments in system design*](https://doi.org/10.1145/357401.357402)*. ACM Transactions on Computer Systems 2, 4 (Nov. 1984), 277–288.*

**Key Words** Function, Completeness, Correctness, Application Layer, Platform Layer, Failure, Failure Detection, Failure Mitigation.

In their 1984 paper End-to-End Arguments in System Design, Saltzer, Reed, and Clark present a design principle that helps guide placement of functions among the modules of a distributed system. In his paper, the term *functions* refers to *functionality*, not a particular function definition in a programming language. Similarly, the term *modules* refers to *layers*, not a particular organizational construct in a programming language.

Saltzer, Reed, and Clark assume a layered architectural style. The basic idea of a layered architecture is simple: components are arranged in a layered fashion where components at layer Lₙ can make a downcall to components at layer Lₘ (n < m), generally expecting a response. Exceptionally, components at layer Lₘ can make an upcall to components at layer Lₙ, generally via a previously registered callback.

For this blog post, we limit our discussion to two layers, we will refer to the top layer as the application layer and the lower layer as the platform layer. 

![Application Layer vs Platform Layer](//images.ctfassets.net/0uuz8ydxyd9p/5QtDbuv9rf3ix7K5MKqoIj/c1d40297db9288e711b912b4055e91d0/Application_vs_Platform.png)

## The End-to-End Argument

The End-to-End Argument states that some functions may “completely and correctly be implemented only” on an application level, implementing said functions completely and correctly on a platform level is not possible. This impossibility is rooted in the fact that the application layer has total information, the platform layer may only have partial information － informally, the platform layer lacks context.

However, the End-to-End Argument does not preclude to provide a partial, incomplete implementation of a function or to duplicate a function on a platform level, not for completeness and correctness but strictly as an optimization.

In addition, the paper stresses that the End-to-End Argument is a guideline that helps in application and platform design analysis; however, identifying the endpoints to which the argument should be applied requires subtlety of analysis of application requirements.

## Example

The significance of the End-to-End Argument is most apparent when reasoning about layers and failures: Is a layer able to detect a failure? If a layer is able to detect a failure, what should that layer do? Should the layer mitigate the failure? Should the layer present the failure to the next higher layer?

### Reliable File Transfer

The paper discusses several examples, however this blog posts limits itself to discussing one example: **Reliable File Transfer**.

The object is to move a file from computer A’s storage to computer B’s storage without damage. A popular implementation to transfer a file is to transfer the file in chunks:

- On the sender side, the application layer splits the data into chunks before handing each chunk downwards to the platform layer for transfer.

- On the receiver side, the platform layer receives a chunk before handing the chunk upwards to the application layer for assembly.

![Reliable File Transfer](//images.ctfassets.net/0uuz8ydxyd9p/3iNBZy1q2kWDBLTm827IAb/3b49ea6cca2b464ba3f92ca4227e9e98/Reliable_File_Transfer.png)

So now the question arises, can you implement file transfer completely and correctly by limiting failure detection and failure mitigation to the platform layer or do you need failure detection and failure mitigation (also) on the application layer?

#### Failure Detection and Mitigation

While the platform layer may indeed detect transmission failures of a chunks via checksums on chunks and mitigate failures via retransmissions of chunks, only the application layer may detect assembly failures on files via checksums on files and mitigate failures via retransmission of files.

#### Failure Presentation

While the platform layer may indeed try to mitigate transmission failures via retransmissions, eventually, in order to avoid an infinite loop, the platform level has to present repeated transmission failures to the application level.

In summary, although the platform layer implements partial failure detection and mitigation, ultimately only the application layer is able to implement total failure detection and mitigation － only the application layer may determine if a file transfer was a success, was a failure, and how to handle that failure.

## Conclusion

The End-to-End Argument states that some functions may "completely and correctly be implemented only" on an application level, even though the End-to-End Argument does not preclude partially implementing functions on a platform level as an optimization.

For example, failure detection and mitigation of a file transfer can (and should) happen on an application level and a platform level but only the application layer can ensure completeness and correctness of the transfer.

### Types of Optimization

- **Performance**. If the application layer detects a failure in the transmission of the file, the application layer may mitigate that failure by retransmitting the file. However, if the platform layer detects a failure in the transmission of a chunk, the platform layer may mitigate that failure by retransmitting only the chunk. We may be able to avoid retransmitting the file if retransmission of the chunk is successful.
- **Maturity**. Even though some functions may completely and correctly be implemented only on the application layer, duplicating functionality on the platform layer may aid correctness; some functions are complex and therefore error prone, encapsulating these functions in the platform layer enables us to take advantage of their maturity and “fill in the gap” of these functions in the application layer

Paper Summary, End-to-End Arguments in System Design

Failure, Failure Detection, Failure Mitigation, Failure Tolerance, Failure Mitigation

Paper Summary: End-to-End Arguments in System Design

Principal Engineer

Dominik Tornow

dominik-tornow

Imagine, two bleary-eyed college students scrambling late into the night to finish their last Computer Science project for the semester. The application they are writing takes a large problem and breaks it down into individual sub-problems that can be solved more easily. Unfortunately, there are too many subproblems for a single machine to handle, so the students realize they need to throw more machines into the mix.

Having quickly achieved consensus on the distributed algorithm, they get to work. All they have to do is implement their code and then deploy it on a set of machines. They figure they will be done within a couple of hours. Easy, right?

![temporal-a-students-dream-1](//images.ctfassets.net/0uuz8ydxyd9p/1l3Wo9ZnJgcns3YoSdJilP/4803982db40ac342aa1c51381a2e1f15/temporal-a-students-dream-1.png)

As they start coding, it quickly becomes clear that they have vastly underestimated the requirements. The algorithm works great on a laptop, but when it comes to executing it on a cluster of machines, they start asking themselves the following questions:

1. Which machine is responsible for coordinating (sending/receiving of sub-problems/results) with the other machines?
2. How do the other machines “know” who the coordinator is?
3. What protocol will be used so that the coordinator and workers are able to talk with each other? Do they need to handcraft a custom one?
4. What if the coordinator reboots or fails? Do they have to start solving the entire problem from the beginning again? Who takes over the coordinator role?
5. What if one of the “worker” machines recycles? Who tells the coordinator that it is not getting an answer back and that it needs to re-issue the subproblem?
6. What if work starts to pile up? How can we increase overall throughput by adding more worker machines in a balanced manner?
7. How does one make sure that a worker machine does not get assigned too many items?

![temporal-a-students-dream-2](//images.ctfassets.net/0uuz8ydxyd9p/1KW6yOUFL2G3oVnRZueuID/0316b9fede7992201c430d565a6a35d6/temporal-a-students-dream-2.png)

These questions touch upon a number of key Distributed Systems topics. But this was before cloud computing was the ubiquitous behemoth it is today. For two exhausted college students who were itching to call it quits on the semester, having to think through these problems at the 11th-hour was the absolute last thing they wanted to do.

Needless to say, in desperation, they took a number of shortcuts. They were able to cobble together a flimsy solution that yielded an answer; However, it would have fallen completely flat on its face at even the tiniest of network blips.

At the end of the day, they spent 95%+ of the time focusing on the infrastructure running the algorithm as opposed to the algorithm itself. As they dragged themselves back from that final class, one of them made an offhand remark that it could be an interesting future project to potentially “solve this the right way.”

![temporal-a-students-dream-3](//images.ctfassets.net/0uuz8ydxyd9p/4DeSveBNGqDpmNy8g6X8Nt/3ed59c550504ae91bc7332b578fd3d4f/temporal-a-students-dream-3.png)

If you haven't already figured it out by now, one of those college students was me. And after three months at Temporal, it has now just occurred to me: I am working on the very platform that my naïve college-aged self would have happily traded a week’s worth of cafeteria credits for. It is a platform that would have enabled us to actually complete the project within our hyper-aggressive initial estimate of a “couple of hours.” A Temporal cluster would have literally taken care of all of the questions we had to deal with above.

![temporal-a-students-dream-4](//images.ctfassets.net/0uuz8ydxyd9p/7eBCxvcXkZx8rHOCFn39is/d1aa088f3338c366a9d4155f6fbfc0af/temporal-a-students-dream-4.png)

It’s been over a decade since I’ve stepped back into a Computer Science class, but from a distance, I’ve seen curriculums evolve to keep up with the pace of technology. When I was graduating, they had just started to introduce map-reduce as a concept in our Operating Systems course. Now schools are offering classes on Bitcoin, Cloud Computing, No SQL databases, VR development and so on.

I truly believe that the concepts behind Temporal deserve at least a lecture or two in any standard undergraduate Distributed Systems course. Given how powerful Temporal is, I predict this will be the case in the future.

shubham-dhage-8ZGZlksF8mo-unsplash

Imagine, two bleary-eyed college students scrambling late into the night to finish their last Computer Science project for the semester. 

Paper Summary: End-to-End Arguments in System Design

Temporal - a students dream