End-to-end arguments in system design April 2, 2009

(i) Point of the paper

The paper presents a philosophy for designing systems. It seems to me that this was a very influential paper in molding the existing thought in 1980’s. The paper argues that:

1. Application knows best: The application sitting at the topmost layer in the systems hierarchy can decide how important a given functionality or correctness is to itself. Lower layers (below the application) can, at best, come to some general conclusions about the application requirements. This could potentially add overhead to those applications that deviate from the general behavior. Example: Audio/Video transmission can afford to lose some packets, but rather want minimum delay guarantees. Implementing correctness mechanisms at layer 2 will not allow such an application to exploit its unique relaxation.
2. Avoid redoing work at multiple layers: If a particular functionality has to be implemented at a higher level anyway, there is no need for it to be implemented at the lower layers as well if the goal is to ensure correctness. Example: Since packet acknowledgments cannot be avoided end-to-end, having acknowledgments for each frame hop-to-hop at layer 2 adds nothing but overhead.
3. Decide on layering: The authors do not reject the idea of implementing a functionality at a lower layer if it means improvement in performance. Demarcating the boundaries between the layers is a critically important task. They recommend that the designer should do a careful analysis of the performance gain achieved by a lower layer functionality in trade-off with the cost of implementing it at that layer. Example: If it turns out that the bit-level error is high in the network, it makes sense to have error-checking and retransmission of frames at layer 2; this would reduce the end-to-end retransmission traffic.

(ii) Most glaring problem

Perhaps the most glaring problem I see in this work is the following: I feel the authors have not shown enough appreciation for the importance of performance gain achieved by implementing a function at a lower layer. While it is certainly true that end-to-end implementation would leverage the knowledge of the application requirements, it would fail to exploit the the trust the application places on the lower layers. Let me illustrate this with the paper example of the careful file transfer.

The paper says that after the file block is written to the disk at the destination, it is reloaded into memory, its checksum is calculated and sent across the network to the sender. The sender confirms the checksum, and the transaction gets committed. Now, if the application were to trust the disk writes to happen without bit errors, this unnessary reloading the file into memory and commit protocols could be avoided. It turns out that TCP (a level below the application layer) does exactly this today. The sender computes the checksum and sends with the packet, which is compared at the receiver end. This avoids the performance loss associated with end-to-end argument by placing trust on the local disk writes.

Another example I can think of is a network firewall, which is implemented at layer 3 in practice for performance, though technically it should be placed at layer 7.

(iii) Scope for future research

As the authors point out, the success of any end-to-end implementation lies in identification of the ends. Layering should be done carefully in order to achieve correctness and performance, at a reasonable tradeoff. We need to keep in mind that microkernels did not become popular because of performance loss associated with implementing common functionalities at the upper user level. The OSes like Unix and Windows are popular because they put functions into the kernel level. This shows the need for us to design systems which allow for lightweight applications to be built easily.

End-to-end Arguments in System Design April 2, 2009

Three most important things:

1. Low-level mechanisms may not be worth the cost of providing those mechanisms at such a low/common level because of the overhead that may be incurred by systems that may not require such protection (for example).

2. Proposes that guaranteeing correctness of a system needs only protection and correctness checking at the end points of that system.  Any mechanism that tries to provide this guarantee over smaller or lower-level parts of a system will not succeed in doing so (because of the sheer number of lower-level portions of that system that a particular individual may not have control over or access to).

3. All is not lost for lower-level correctness checking, as it may be useful in reducing the number of times an end-to-end check may fail.  A trade-off exists between the amount of performance gained via corrected errors and the amount of time/bandwidth lost to the scheme itself.

Most glaring problem with this paper:

The paper itself did not provide any quantitative insight as to how end-to-end reliability checking (or any end-to-end model, for that matter) performed versus that of a lower-level reliability scheme.  All of the scenarios provided were strictly single situations and not entirely related to the general case (which the authors were arguing for).  Also, to point out another problem, the writing style of the authors was very colloquial for that of a research paper, which made the paper much more verbose than it needed to be.

Future Directions:

One good research direction would be to evaluate the trade-offs present in an end-to-end scheme over that of a lower-level  scheme (for any of the arguments listed, including that of networking).  The authors might evaluate a set of programs/systems that would represent a “status quo” for the time period (for instance, just as SPEC does for the Architecture world) with each scheme implemented comparing performance, overall reliability, etc.

Another reasonable research direction would involve exploring if there exists a scheme that provides end-to-end system coverage (or as close as possible to that notion) without requiring each application programmer or system designer to build in some sort of scheme.  In other words, the authors could explore methods in which to make this idea more scalable.

End-to-end arguments in system design April 2, 2009

This paper presents the end-to-end arguments as a  guideline to address the problem of functions placement among modules in a distributed system.

Deciding where to locate a function, such as i.e. a checksum computation to guarantee a reliable data transfer between two computers, can indeed be a hard task. In the paper the authors presents several examples where the end-to-end arguments has proved its usefulness. They do that by showing how different approaches that could have been taken to address the same problem would have led to not equally good solutions. In some example the difference between the two solutions was only in terms of performance, in others more in terms of complexity, cost and effectiveness.

The basic principle behind of the end-to-end argument is that if a function needs the knowledge from the application in order to accomplish correctly its own task, then the function should be implemented at the end point of the communication. Adding it in the middle of the communication can also be useful, but only for redundancy or as a complementary feature.

Besides for presenting the end-to-end argument, this paper is also very interesting for the discussion about the “engineering tradeoff” analysis that a software designer has to face when he or she must decide where to locate a function. The same function can be better implemented in different locations -on the end point or in the communication- depending on what kind of applications the function is supposed to serve. That is why, accordingly to the authors, the end-to-end argument is not an absolute rule but rather a design guideline. The validity of such guideline is not constrained only to networks though. Indeed, the end-to-end argument can be applied and has already been  applied to several other fields, such as the operating systems with the Multics.

The paper concludes by indicating the layered communication protocols as another case where the end-to-end argument could give a interesting contribution.

End-to-end Arguments in System Design April 2, 2009

The paper presents a philosophy for placement of functionality among different modules in a distributed system. It is a very interesting systems paper where the authors present a design principle and offer no actual quantitative evaluation of the design in the paper. This can however be attributed to the fact that the principle itself is very open ended and can be applied to a wide spectrum of actual system designs.

An important contribution of the paper is identifying and separating two important considerations while designing a system – correctness and performance. The philosophy that the authors propose is that the correctness of the entire system or the reliability of the service offered by the whole system can best be enforced by the uppermost layer in the system hierarchy. In most cases, the uppermost layer in the hierarchy has to necessarily enforce certain checks to validate the correctness of the system even if lower layers in the hierarchy enforce and offer some reliability guarantees of their own. These checks performed by the uppermost layer can always detect and fix problems with the lower layers, so any correctness guarantees by lower layers is just redundancy of functionality. Functionality might only have to be moved to lower layers in the hierarchy to improve performance. The authors explain the principle with an in depth analysis of the data communication example and also state few other examples in brief.

The authors claim in the abstract that the paper presents a design principle to guide placement of functions in the distributed system. However most of the paper is related to the correctness aspect and not the performance aspect. So while they describe one half of the trade-off between correctness and performance, they do not have a deep analysis of the other half. With regard to the correctness aspect, the authors mention that one needs to enumerate the threats to the correctness of the system and figure out where to enforce the correctness constraints. In the data communication example, the authors quote that the guarantee of reliable data communication in the communication subsystem only reduces the frequency of retries by the file transfer application. While it is true in this case, this argument only holds if the solution to each threat is the same or the correctness check that has to necessarily be enforced by the uppermost layer has to necessarily validate correctness of each threat. Put another way, the uppermost layer has to validate certain conditions through mutually exclusive checks to validate the correctness of the system. It might be possible for a lower layer subsystem to validate some of these mutually exclusive conditions and then the uppermost layer does not have to validate them at all.

From the performance aspect, the choice of where to place which reliability constraints and the level of reliability required off different layers also depends on the relative probabilities of different threats to correctness. But the required optimal level of reliability from the lower layer depends on the application at the higher layer and it would be nice if this can be parametrizable. If the higher layer can tell the lower layer the level of reliability it requires, that would expose more functionality to the higher layers. This will allow higher layers to avoid the cost of high reliability from the lower layer when they do not require it. Sometimes even if certain functionality is not required by an application, the lower layer might have to enforce it, in order to offer guarantees to other applications that share the lower layer as is the case with congestion control in the network. With mutually distrusting applications sharing the network, the network might have to restrain all users to offer certain guarantees to everyone. While congestion control is  implemented through TCP at the end points, only the network actually experiences and can exactly identify congestion, and it might be the case that the network knows best how to deal with it. Another classic case where the end-to-end principle is violated is in any form of caching to improve performance. In those cases, the performance benefits of caching far outweigh the cost of violating the end-to-end principle. So overall, performance is often too important an aspect in modern systems and functionality would often have to be pushed to lower layers.

One interesting line of throught related to the paper would have been to question the actual existence of certain lower layers in the system. If the correctness can only be guaranteed by the uppermost layer in the system, that could actually suggest removal of certain layers. While certain lower layers are required for the correctness or reliability of a different kind as illustrated in the low lovel encryption for military security, in other systems, it might be possible to completely remove certain layers. Apart from correctness and performance, the interaction between different users of the lower level service is also an important aspect that decides what service needs to be offered by the lower level.

From a research perspective, the paper highlights that choosing proper system boundaries and interfaces is a very important activity and can impact both correctness and performance of the system. Due to the simplicity of implementation and flexibility at the higher layers, new innovative ideas often originate in the higher layers and move to the lower layers for performance reasons.

End-to-end arguments in system design April 2, 2009

Most of the protocols have layered structures. This paper supports the end-to-end argument, which advocates for the methodology of placing functions at the application level. It has been shown that placing a function at low level may be redundant because even though they help to achieve to get the final goal they are not the end points. Hence guarantees provided by them are not sufficient. This has been discussed in paper in the example of file transfer application. Though lower level reliability checks ensure the successful transmission of data. It does not specify whether application has completed the steps which are expected after receiving the data. This happens because there are many more steps except the data transmission and guarantees for these steps can be provided only by the application level function implementation. Another example provide by the author is the fact that if lower level guarantees the reliability and application level programmer depends on that then it might not be sufficient as shown is the case of checksum provided by the packets. Here small error made the application unusable due to absence of application level checks. Another example to this is the case of “Request for Next Message” of the ARPANET. This is useful to know the congestion of the network but not useful in knowing whether end request was completed or not for any application running on the ARPANET.

Another argument is based on the fact that placing a function at lower level does not help because in many cases lower levels are shared by much application. And tailoring lower levels to one application might not be useful to other applications. This argument has been supported in the paper by giving the example of the voice packet transmission. Though the packet transmission is same in both cases application needs are different. If we incorporate heavy reliability requirements in the packets then it will not serve the end-to-end purpose of the packet based voice communication. Where requirement is low latency and occasional packet drop can be tolerated. If end-to-end argument is implemented on application level then it will be applicable for both the cases. If it is implemented at application level then it will not have the latency increase for packet based voice application and still reliability can be achieved for disk storage based voice where user does not have choice to ask for resending the data.

Some of the functionality is easy to be controlled at application level e.g. double message suppression, which falls to same end-to-end policy because it is easy to recognize the generation or receiving.

Paper discusses that functions provided at lower level vs. end-to-end should be seen as an engineering tradeoffs based on the performance rather than the correctness.

End-To-End Arguments in System Design April 2, 2009

The three most important contributions are as follows:

1. Low level functionality is about performance tradeoffs verses correctness. If correctness is attempted at a low level, some checks will have to be redundant due to the check being necessary at the end points.
2. Functionality at a low level forces everyone to pay the cost. If there are correctness checks built in at a low level, every user has to have the check, regardless if they need it or not.
3. Don’t put the intelligence in the network, put it in the nodes.

The most glaring problem with the paper:

The end-to-end argument does not take into consideration network management. Sometimes it is advantageous to have intelligence put into the network. For example, lets say that an ISP, or other administrative domain such as a corporation, wants to prevent its users from using a third party service. The ISP can not modify the third party to prevent them from providing the service, instead it must use the network to filter incoming/outgoing packets for that service.

Future research implications:

Nodes become more complex, and therefore more expensive. The end-to-end argument favors a predominantly packet based network, as opposed to a circuit switching network. In some ways, this also makes it easier to deploy new modifications to network applications. It is much easier to provide an update that users must download, verses trying to convince ISPs to modify their network for your application.

End-To-End Arguments in system Design – Review April 2, 2009

This paper tries to put forward end-to-end argument in system design. It stresses on the fact that there is a tension between placing the functionalities in the lower level of the system versus providing them in the application layer. The paper illustrates this tussle using communication subsystem and a file transfer application as an example which tries to send a file from one computer to another on a network using the communication subsystem and the issues involved with the reliable transfer, both at the application level and the communication system level. One important aspect mentioned in this context is that keeping the functionality in the application keeps the cost of all the reliable transfer checks to the application layer itself and the lower level system still remains same to all the applications. But, the flipside to the approach is that there can be a performance hit when the transactions scale for the application (in this case, it is increasing file size) as there can be many more retries of the same process and it may blow the performance. To counter that, some reliable transfer mechanism can be provided in the communication subsystem itself. But, this also can lead to two drawbacks which are important highlights of the paper. One of the drawbacks is that all the applications have to pay for the functionality if even they do not need it. The other drawback is that pushing the functionality to the lower levels hides a lot of application specific information and the job efficiency suffers. The other important aspect of the paper is that the argument of end-to-end system design is actually specific to every application and therefore, there has to synergy in what goes under the layers and what is exposed in the application. One of the drawbacks of the paper is the system design where target may not be of importance and the host only need to needs to broadcast the information to the targets. Here, reliability may not be an issue and the end-to-end argument may not be of much significance. The pointer provided provided for future work is to keep the end-to-end arguments in mind while pushing the functionalities in the communication subsystem layers.

End-to-end Arguments in System Design April 2, 2009

In this paper, the authors argue that no amount of cleverness, redundancy, error detection, etc. at a low level of the system can obviate the need to provide end-to-end protections at the application level. The crux of their argument is that the potential sources of data corruption and loss include sources which are fundamentally uncorrectable at the low level. As an example, no amount of network protections can prevent an intermediate host from corrupting data as it passes it from network link to network link. In addition to being insufficient to prevent all errors, low-level protections can actually add overhead which can cause unnecessary performance degradation. In the best case, the low-level functions can serve as a performance optimization to reduce the amount of time before an error is detected, but cannot provide all of the protection necessary.

In my opinion, the biggest problem with this paper is that it ignores the programming overhead imposed at the application level as a result of having to implement everything in an end-to-end manner. While it is true that the application level will always have to provide some kind of error checking and data verification, there is no need to make every program perform some of the tasks which can be performed at a low level. In addition to the programming overhead, there is also a potential performance overhead. If functions are implemented at the hardware level, it is possible to design specialized hardware which can provide the functionality much faster than equivalent application-level software could.

Future research in this field needs to be domain-specific, since the mechanisms for packet-switched networks likely overlap little with those for copying data between two hard disks in a system. As mentioned in the paper, the key for determinining the system’s position on the low-level/end-to-end spectrum is a careful analysis of which functions can be more efficiently and effectively implemented at a low level.

Fundamentally, the concept of this paper is sound. There are virtually no applications in which there does not need to be some end-to-end checking regardless of the underlying implementation. The key is striking a compromise between efficiency, modularity, and effectiveness.

End-to-end Arguments in System Design April 2, 2009

The paper “End-to-end Arguments in System Design” by Saltzer, Reed and Clark presents an argument to consider when deciding on the specific layer (or module, subsystem) in a system to implement a certain function needed by an application. This “end-to-end” argument argues that these functions (or quality properties of an application) cannot be extracted down to a communication subsystem layer, as its specifics may a) differ from application to application and b) the communication subsystem is only one subsystem involved in the process, so application guarantees of certain quality properties can only hold if the application itself performs quality checks on each subsystem involved. However, due to performance needs of an application, it may be feasible to implement these quality checks redundantly on both layers for the parts they’re responsible for, according to the paper. They’re also arguing for exposing those decisions to the application designer, so he does’nt rely on a false sense of a quality property of a subsystem.

The most glaring problem of the paper seems to me the missing guidelines on deciding how to balance performance needs and end-to-end quality requirements, the paper states these trade-offs as being complex and does provide examples of implementation decisions, but no detailed discussions of these decisions or general guidelines for the designer.

Future directions related to this work would include going into specifics for each of the quality properties presented, I suspect the list of these properties to be finite and manageable. Case studies on common application quality requirements could lead to the missing guidelines for application designers and elicit interesting similarities between on first look different properties.

End-to-end Arguments in System Design April 2, 2009

This paper is about tradeoffs between placing functionality at the high layers vs. low layers of the system. It argues that placement of functionality at the end-points often results in more flexibility and better overall performance than doing so at the lower layers. If a certain functionality is implemented at the lower layers, then any application using the system will be affected by performance implications of adding this function to the lower layer. Therefore by making the lower layer slower, there is extra cost imposed on applications that don’t need to use the functionality in question in the lower layer. For example, a voice-call application might not care about voice packets being dropped. If the network layer tries to retransmit these packages, there is additional latency added, and the voice application will suffer from this delay for no reason, because it needs to use the network layer. Additionally applications often need to handle situations in a particular way that the lower layers would not be aware of. Thus, it is redundant to place a functionality at a lower layer when the application needs to re-implement it at the higher layer again.­ Functionality should only be placed at the lower levels for performance or security reasons such as an encryption system that needs to ensure no application can get away with transmitting an unsecured message from the system. In such cases it makes sense to move the functionality to the lower layers.

The paper does not directly address efficiency at different layers. The authors claim that placing functionality at the lower layer might have performance implications to the applications running at the higher levels. However, they do not mention that the lower layers are usually much more efficient than the higher layers, and adding a feature there might not impose much of a performance penalty. Often times many types of functions at the lower layers can be implemented in hardware with little penalty. For example, letting the hardware calculate a checksum as data is read from disk would present no noticeable penalty, while doing the checksum in software would have some latency. In such cases it does not hurt to place functionality at lower layers and let the higher layers decide whether they want to re-implement their own version.

End-to-end system design is inherent in today’s systems. We see applications such as SSH which perform encryption at the software (higher) layer, so that other applications not requiring encryption would not suffer from latency of encryption at a system level. However, with distributed systems, there are many cases today where it makes more sense to place functionality at the lower ends. For example given a network of computers, it is more robust to have a central firewall system that affects them all, rather than relying on each node to have its own firewall. As another example, the authors mention that the RISC architectures favor the end-to-end argument. We see more and more cores on a single chip nowadays. Given multiple cores on a system — each optimized for a certain type of functionality — it might make more sense to have each core be a CISC architectures as opposed to RISC. In this case using a CISC architecture would improve performance while offering the flexibility of a RISC system, because an application would have flexibility in choosing from multiple specialized cores to do its task.

End-to-end Arguments in System Design April 2, 2009

Three important facts brought out by the paper

A lot of communication sub-systems tend to provide several functions aimed at making the system more reliable, secure, error proof, etc. The paper takes a look at the big picture, including both the communication sub-system and the upper application layer, and brings out the fact that a lot of these functions would provide a more complete coverage if present in the upper, application layer.

The paper also mentions how providing the same functionality in both, the communication sub-system and the application layer would only introduce more redundancy into the system without actually helping performance or coverage to a great extend.

In addition, it talks of the trade-offs and the purpose achieved by providing these functions at a lower or upper layer. It takes a look at six major functions relevant to a networked, distributed system: reliability, delivery guarantee, secure data transmission, duplicate message suppression, in order delivery and transaction management. It discusses the major benefit and functionality achieved by providing each of these features at a communication sub-system level or the upper application layer or both. This provides some rather interesting insight into how several of these features perform redundant work given others are already in place and only result in unnecessary wastage of bandwidth and compute time.

Facts it overlooks or doesn’t provide

It presents no concrete experimental results. It provides a lot of reasoning which makes sense. However, there are a lot more trade-offs between providing a functionally in the lower or upper layer and additional aspects to the ones mentioned than that touched upon by the paper. For example, it does not talk of the overhead/time wasted in letting an error get to the application layer before it is detected. It does mention how large files might benefit with per packet error checking and how this can also be accomplished by a “careful file transfer” application. However, it makes no mention of the time taken and computation required to perform this error checking in the application layer as compared to the lower, communication layers. It is possible that performing checks in the lower layers takes up half as much time and if majority of the errors occur in the lower layers, a lot of performance benefit is to be got by providing efficient error checking in the lower layers itself. In the case of end-to-end reliability checking, there is also the overhead of sending a checksum from the client machine to the server machine as part of the last step to compare the original checksum with the final checksum. If the communication sub-system were to detect this error a priori, this overhead can be averted. A clearer and more concrete picture of all these trade-offs working at the same time would be got if actual experimental results were presented and a comparisons made between providing functions at the lower and upper layers.

Future Work

One of the extensions that can be made to the idea presented by this paper is to provide quantitative measures that take into consideration the network type, traffic, protocol etc to determine if a functionality should be provided in the upper or lower layer. A further extension could be to make this a dynamic decision, wherein, depending on the number of packet errors or the QOS provided by the network, a functionality might be realized in the lower or upper layers. For example, if there were more than one or two packet errors in a single file, error checking/reliability could be provided in the lower layer to prevent spending time in receiving the entire file before declaring it to contain an error.

End-to-end arguments in system design. April 2, 2009

This paper discusses the placement of reliability functionality in a layered system.  Placing such functionality at a lower level is advantageous for obvious reasons: the high level applications can reuse this code and assume reliable low level functions.  However, the authors argue that in many scenarios, and end to end check is still required for a particular high level application.  This makes the low level functionality redundant, and not worth the price of overhead and effort.  The authors go through various examples where such rationale is used to ague for placement of reliability checks at higher levels.

There are various disadvantages for placing functionality at a lower level that the authors discuss.  First, it may be impossible to provide 100% reliability at a low level due to lack of higher level information.  For example, in a communication system, even if each packet is ensured to be correct by the system, there may still be errors in buffering or copying that only a higher level application could check.  Second, ensuring a high level of reliability may become expensive and cause overhead for a low level system, such as sending packets multiple times.

On the other hand, there are some disadvantages to placing such reliability functionality at a high level.  The most obvious disadvantage is the potential duplication of code.  The other disadvantage the authors discuss is that if an end-to-end check has a high probability of failure (i.e. if each packet being sent has a high probability of being incorrect), it may be necessary to have both low level and high level checks.  Rather than claiming that functionality should ALWAYS be moved to high layers, the authors simply argue that low level reliable need not be perfect, especially if such perfection is expensive.

Though this paper present a convincing argument and many interesting examples, these decisions are still heavily application dependent.  This is perhaps the weakest part of the paper – the authors simply list some “rules of thumb”.  However, it is not clear whether more precise methodology can be developed.

End-to-end Arguments in System Design April 2, 2009

(i) the three most important things the paper says

The main important aspect of the paper is describing the end-to-end argument as  a design principle. Placing functionality at the lower layers of abstraction may be redundant, incomplete, of little value, or increase cost, compared to providing the functionality at a higher layer or level of abstraction.

Then the paper goes into detail about specific examples such as the file transfer application and makes the point that “it would be too simplistic to conclude that the lower levels should play no part in obtaining reliability”. This leads to talking about performance issues with implementing both functionality at a lower level and a higher level and “using performance to justify placing functions in a low-level subsystem must be done carefully”. It must be designed carefully because “the same or better performance can be achieved at a higher level” due to reduced overhead and application specific knowledge and increased knowledge that the lower layers will not have. But also in some cases, having that functionality at a lower layer will be more efficient if there is low overhead and it is a common subsystem to many applications.

Finally, the paper makes the conclusion that “Thus the end-to-end argument is not an absolute rule, but rather a guideline that helps in application and protocol design analysis; one must use some care to identify the end points to which the argument should be applied.”

(ii) the most glaring problem with the paper

The paper acknowledges that there is still a need for both end-to-end and low level designs depending on the application and future needs. A glaring problem is identifying the end in end-to-end design. This can be specific to the application, properties of the application, any number of other properties and variables. One interesting example the paper mentions is RISC processor architecture as an example of end-to-end system design.

(iii) the future research directions of the work.

There are many future research directions taking this end-to-end argument and applying it to design of operating systems, cryptographic systems, distributed systems, next generation network protocols, real life situations, etc…

End-To-End Arguments In System Design April 2, 2009

(i) One important thing that the paper says is that even when reliability is enforced at the low levels of the system; it does not reduce the effort needed by the application program to ensure reliability. In the case of remote file transfer, reliability measures need to be enforced by the data communication system to provide reliable deliverance of packets over the network and by the application program to prevent threats possible on the application side.

Another important thing the paper claims is that the lower levels of the system do not need to provide perfect reliability. The amount of effort expended to improve network reliability can have a negative impact on application performance. For example, checking to see if a file arrived correctly over the network would increase the time spent transferring the file as the length of the file increases.

The last important thing I would like to note is that the paper claims that the end-to-end argument should be treated as a guideline that helps in application design and not an absolute rule. Depending on the specific application there may or may not be a need to provide low-level reliability procedures.

(ii) The most glaring problem I found in the paper is that the authors assume that the end points (the application programs) are both trustworthy. Yet today there seems to be a lot more people that intend to abuse the Internet. In the case where reliability is enforced in the untrustworthy end points, individual users and the network as a whole could be attacked by malicious users.

(iii) Future research in this area could be to look how the end-to-end argument applies to other areas of the computer operating systems such as file systems. Reliability needs to be ensured when transferring data between disk and memory. Possible threats to the transfer could be a mistake in buffering and copying the data of the file and system crashes.

End-to-end Arguments in System Design April 2, 2009

“End-to-end Arguments in System Design” by J.H. Saltzer, D.P. Reed and D.D. Clark is a research paper that formally address the End-to-end principle as a design principle for different boundaries between functions in a system. Saltzer and company argue that correctness can only be done on a end-to-end basis. In a communication system this means that only the application can tell if the data it receives from the lower level functions are correct. They give an example of this when they talk about the file transfer from computer A to computer B. Many things can go wrong with the transfer like dropped or changed bits in a packet, software errors on buffering and copying, hardware errors on the disk or even system crashes. The only possible way to be fully correct is if the application on computer B checks the data. In this case they described using checksums by having computer B send the check sum of all the data it received to computer A so that computer A can compare the checksum of the data received with the original. If the checksums are different, then computer A will retry from the beginning the file transfer. This approach was dubbed “end-to-end check and retry.”

The end-to-end principle is also very flexible. Saltzer and company state that placing function in a lower level can help performance but getting it right is very difficult. They describe examples where adding functions in a lower level for reliability might increase the performance in some cases and hurt performance in others. This is why the end-to-end principle is flexible since it assumes nothing about the lower level because it will check the data itself. This also shows that if lower levels provide something like reliability checks, it does not need to provide perfect reliability.

This paper is significant to network research because it paved the way for the design of UDP and TCP. Networks today are built off layers that follow the end-to-end principle. The end-to-end principle also has its problems though. Saltzer and company give an example of a real time telephone like application running on a communication system. It most cases we want the application to retry if the data it receives is incorrect but in real time this might not be suitable since we can just ask the other side to say what they said again. If this was not real time but saved on the disk and listened back later, it might be appropriated to retry the data. This example shows that the end-to-end principle cannot satisfy every possible case.

The end-to-end principle is not a new concept and has been used in many cases before this paper like encryption, M.I.T’s CTTS, RISC architecture, etc. What this reminds me of in Operation Systems is the Exokernel. Both state that the lower level suffer from a semantic gap where the lower levels just doesn’t know what the higher levels really want. Since they do not know they should just implement the bare minimum to allow the higher levels to be more flexible even if it require more work on the higher level’s part.

End-to-end Arguments in System Design April 2, 2009

The paper emphasized the necessity of only end to end arguments in networked system design. They have advocated for the use of end to end error control in the application layer rather than burdening the protocol at every layer with the error correcting measures. This poses a tradeoff which must be made, for example, if the errors in the lower layer are rare, incorporating heavy error correction in these layers may have an overall impact on the system performance. On the other hand, if errors are frequent in these layers, correcting them at the higher level by retransmission may be costly and add heavy overhead.  Thus the design has to balance between the two, providing just the amount of control mechanisms that can make major part of errors corrected with minimal cost. Also in many cases, just providing error control at the lower levels is not sufficient since error may occur at intermediate points while copying data to and from buffers. To cope with such threats error correction at the application layer has to provided which makes the need in the lower levels redundant.

Thus in cases where providing control at the highest applications level are necessary anyway, lower level error control is a waste and adds extra overhead. This becomes more evident in cases like secure transmission of data where the lower layers can’t be trusted with the encryption and decryption of data. Between these lower layers, points would exist with clear data which is vulnerable to attacks. Thus the application layer has to take the responsibility of transmitting the data encrypted from the very highest layer. Similarly in case of duplicate suppression, sometimes only the application can identify duplicate messages which is not possible in lower layers due to lack of information. In such case enforcing duplicate suppression at every layer is redundant. Finally some applications might be tolerant to minor errors like media applications where a little loss of data does not cause failures. Even in such cases the error control is better left at the discretion of the application layer.

Although the paper emphasizes on the end to end argument, current network systems are becoming too large and complex to rely only on that. This is due to the fact that errors might become more frequent in each layer and leaving the entire error control at the highest layer will be too costly. Thus sufficient error correction must be provided in each layer which removes most of the faults thus providing a fairly error free transmission with a reasonable cost that is justified. Thus future systems must have error controls at intermediate layers than just end to end which will help minimize the overall communication cost.

End to End Arguments in System Design April 2, 2009

(i) The three most important things the paper says:

1) Even if low level functionality provides mechanisms of reliability, it does not reduce the burden on the application program to provide reliability. This is the key point of the paper and provide the basis of arguing that perhaps providing functionality at lower levels incurs unnecessary overhead.

2) Lower levels need not provide “perfect” reliability. This is the most important conclusion that was drawn, because it distilled the essence of the argument into a concrete example. Furthermore, it challenges the mainstream because it suggests a “lossy” solution in lower levels which is typically reserved for higher level applications.

3) The “End to end” argument requires subtlety of analysis for application requirements. This word of caution is important to note, because even in the paper they discuss how there is still benefits to providing some checks (e.g. transfer of large files, IP phones).

(ii) The most glaring problem with the paper:

The biggest problem with the paper is that it barely covers how the “end to end” argument doesn’t mean the rejection of abstraction. While the “end to end” solution does offer optimizations in terms of overhead. The abstraction argument has many benefit that equally rival the benefits of “end to end”. For example the benefit of greater code reusability for quicker development, less code foot print for embedded devices, or just simply ease of development. The greatest example would be to consider the growth and popularity of UNIX which was primarily due to the abstraction of everything as IO devices.

(iii) The future research directions of the work:

The future research of the work would definitely to be offering low level APIs that provide “various levels” of reliability or features. Therefore it can be adapted to what the calling application needs. This allows us the benefits of abstraction as well as, if the application chooses, uses as much or as little as of the functionality provided by the low level system.

End-to-end Arguments in System Design April 2, 2009

(i) the three most important things the paper says:

1. End-to-end is a design principle which says that in a distributed system, one should consider putting functions such as encryption, duplicate detection, guaranteeing delivery etc. at the “ends” of communication (often the application level) rather than in the middle at a low level (i.e. in the communication subsystem). This is because in many cases, the “ends” need to perform these functions in order to guarantee correctness anyway.
2. In some cases, implementing the functions as low level mechanisms may be beneficial, since they may provide performance gains. However, end-to-end is still needed for correctness.
3. The end-to-end argument can be used to support design in non-communication applications, such as a reliable tape reading/writing subsystem in Multics and replaceable kernel functions in an “open operating system”.

(ii) the most glaring problem with the paper:

Authentication is a significant impediment to end-to-end design. Certification authorities and firewalls provide security to endnodes by providing functionality which interposes between the two ends within the communication network.

(iii) the future research directions of the work:

In many applications it is necessary to apply the end-to-end principle judiciously, rather than abandoning low-level mechanisms completely for end-to-end in every situation. A potential research direction is to determine the applications where end-to-end is insufficient to provide the necessary functionality.

End-to-End Arguments in System Design April 2, 2009

i)

1. This paper argues that communication protocols should try to be minimal. One of the reasons for this is that applications have widely varying needs so by trying to provide a feature in the protocol it may be unnecessary for some applications and redundant for others. Another reason is that applications understand their goals and semantics in a way the underlying protocol can’t. One example the authors gave is duplicate message suppression. A protocol might be able to detect if it is receiving a duplicate packets but it can’t detect if a user was simply impatient and tried sending a message twice because the first send was taking a long time.

2. Another important point brought up by the paper is that putting some functionality into the protocol even though the application must still provide the end to end guarantees can be useful if it increases performance. An example of this was if the protocol attempts to deal with failures in sending packets can greatly reduce the number of times the application has to deal with a failure sending a message which is especially useful when the messages it is sending are large.

3. The third point of the paper was that providing functionality in lower layers means that it cannot detect errors in higher layers. An example given was MIT had a network that used a protocol that used checksums to detect errors in transmitting messages, but one of the gateways had an error where it would intermittently corrupt the data when copying it from the input buffer to the output buffer and this error was not detected by the protocol.

ii) I think the most glaring problem is that it doesn’t address the possibility of having many different protocols, each providing different functionalities, and letting the application choose which to use. While this wouldn’t be a solution to some of the problems they presented such as ensuring the receiver acted on the message sent, it does provide an alternative to their argument that pushing functionality into a protocol introduces unnecessary overhead for some applications.

iii) This paper argued that protocols should be minimalist, but it left open the question of what functionalities can a protocol provide to provide performance enhancements for applications using it.

End-To-End Arguments in System Design April 2, 2009

(i)   The three most important things the paper says:

1. End-to-end design prevents unnecessary redundancy. It does this by encouraging any excess work such as checks should be done at the highest level possible and only there. This means that you don’t have many lower level systems doing similar or even the same check multiple times and states that many times by knowing the specific application there is often a more efficient less general algorithm that can be used.

2. Make lowest levels as specific to their application as possible. By doing this, it allows the users of the low level tools to be guaranteed that they are optimized things that do exactly one thing. You can then combine these small optimized tools to create higher level tools that only do what you need.  The alternative is to have robust solutions that do all kinds of extra checks but these add undesirable overhead and can be extremely inefficient when you are combining tools that end up checking the same thing.

3. The end-to-end paradigm can be applied to much more than just networking. The ideas stressed by end-to-end can be applied to many areas besides communication. The same ideas are at the foundation of the RISC architecture where minimization is key. Using a mindset of modulization where each module does only its specific task can lead to much more efficient solutions other problems encountered in our world.

(ii)  The most glaring problem with the paper:

The paper did not address the possibility of having options for some of the lower level assurances.  When designing a low-level protocol or application it is true that you want to make it do as little as possible so that it may be used reliably in as many cases as possible. Things like adding extra checks and assurances jeopardizes this since some applications get little to no benefit from this checks and it adds overhead. The author does elude so some problems however that a communication system could benefit from having checks done along the way, like placing an early retry protocol in a communication system for a file transfer application. The author does not recommend what should be done to make problems such as this easily dealt with, such as having a configurable communication system and he only briefly glosses over the idea of layering for configurability, but instead leaves many questions unanswered.

(iii) The future research directions of the work:

This paper leaves it open to many to find more applications of end-to-end design.  It would also be worth investigating the reasons why end-to-end design decisions do not adapt well to some areas, and what should be done in those cases. This paper also laid ground work for many ideas that follow.  The ideas loved by Object Oriented programmers which highly support modulization. It also mentions the idea of layering so you only take the layers that are most useful for your application etc.

End-To-End Arguments in System Design April 2, 2009

i) Important:

1. The argument is very convincing. Many supporting examples are given. In general it is better to place functionality at higher rather than lower layers. Common network transaction models support the the argument and the network itself is simplified and optimized.
2. The placement of functions within a system requires careful consideration. Existing systems must be examined and newly anticipated uses must be considered. Insight in to potential problems and expected performance is needed.
3. Application sets cannot be predicted and networks must be general enough to support unanticipated uses.

ii) Problem:

The paper does not mention the then popular OSI networking protocols. The OSI protocols perform reliable link layer transactions using acknowledgments and retransmits. OSI design and deployment should be examined. The reasons for its acceptance and the applications it supports may offer insight into fallacies of the argument.

iii) Future:

The paper is clear that exceptions to the argument exist and performance enhancements are possble if additional functionality is enabled judiciously in lower network layers. Modern networks are able to identify discrete traffic flows and provide differential treatment. Noisy, narrow-band wireless links will provide superior service if the link layer in inteligent enough to apply additional functionality to meritorious traffic flows.

The End-to-End Argument is a theory. Is any proof possible? Perhaps for specific cases; e.g., reliable packet delivery using acknowledgment, timeout, and retransmit can be placed at many places in the network and redundantly in various layers. Simulation of various network configurations may dramatically support or refute the argument.

End-to-end Arguments in System Design April 2, 2009

The authors bring to the surface the question of where to place key functions within design frameworks. The discussion is couched within the context of a network stack. They use several examples to illustrate how implementation of functions in the communication layer may (often) be insufficient for applications. In their examples they suggest that the communication layer may be able to provide guaranteed, once-only, FIFO, uncorrupted, confirmed delivery of individual packets across a network. However, only the end point applications will be able to identify if the intended action was successful. This determination will most likely involve some application specific function that replicates similar functionality added to the communication layer. The question becomes, why add any functions to the lower level layers if the application layer will need to perform its own form of the same functionality?

The authors go on to argue that having some level of functionality in the communication layer will reduce the errors encountered at the application level. Moreover, that most applications except real-time applications, will benefit by having this minimal level of functionality. Indeed, this is probably true for most applications.

It seems however, that most applications expect a common level of functionality from the communication layer. This is most evident by the widespread use of TCP. Of course real-time applications may choose to use UDP for performance reasons. But if the author’s arguments are as strong as they suggest, then I would expect more applications to use UDP. The corresponding TCP functionality would need to be built into the application already, so why bother with redundant functionality in the communication layer?

While the main argument of efficiency is valid, it seems that the larger argument is whether the cost of redundant functionality is acceptable to the application. My limited experience suggests that the benefits of some of the lower layer functions exceeds the cost of the redundant functions (in terms of development time and runtime). Further research into quantifying how much each feature is “worth” for common network applications would be an interesting avenue to pursue.

End-to-end arguments in system design April 2, 2009

The authors argue in favor of end-to-end placement of functions among modules in the wake of layered communication protocols in distributed systems. They argue that functions like error recovery, data encryption, acknowledgement, data ordering and duplicate data suppression should be implemented at the application end rather than at lower level subsystem. The rationale is that the lower level transmission system is common to many applications and implementing the above functions at this level may affect the performance of applications that do not need these functions. The authors argue the placement of these functions at lower levels only when performance is extremely critical.

Each specific function in case of a data communication network is argued for implementation at the application level. The authors say that data transmission error recovery can be done by the user application layer in the form of end-to-end checksum and retry. The alternative of adding redundant data and internal consistency checks in the transmission system will result in bandwidth being hogged for unnecessary transmissions and also increase data vulnerability if the medium itself is unreliable. Therefore the authors insist on making a good engineering tradeoff when choosing among the two function placement strategies for error recovery.

Secondly, the authors apply this argument to delivery acknowledgement and demonstrate the performance efficient use of end-to-end acknowledgement and reduction in the path length of lower-level protocols in the SWALLOW system. The authors then argue that the applications should retain data encryption to tailor their authentication needs, for effective key management and for secure message transfer, which are not possible if implemented at lower levels. Duplicate message suppression similarly should be handled by the applications since the transmission system might fail to suppress duplications originated by the application. Lastly, since messages in a distributed system can be sent from different processes and virtual circuits outside a communication system, ordering these messages can be best handled only by the applications.

The authors then present a holistic view which states that the end-to-end argument of function placement be used only as a guideline for protocol design and not as an absolute rule and call for developer discretion of identifying appropriate end points in a layered protocol. To this end the authors present the counter examples of full-duplex voice packet transmission over a telephone line versus a voice message system which require function placement at application level and transmission system level respectively.

The authors conclude by drawing parallels between other similar arguments proposed historically and applied in the field of systems design viz. Lampson’s Open OS or ‘kernelization’ and Lampson and Reed’s two-phase commit protocols. The paper gives a proponent view of modular functionality across protocol layers in a data communication stack. It introduces the concept of functionality placement at any layer that gives the maximum performance benefit with minimal resource usage. Thus the future work triggered by the paper could be thought of as a high performance layered protocol implementation for data communication systems of the day by only retaining the core essential functions at any layer and pushing the others closer to user application.