The paper argues about the placement of functions at higher level instead of providing them at low levels in a distributed system. The argument is supported by a detailed example of file transfer between two machines. Things that can go wrong during the transfer range from file corruption due to error in copying or buffering, hardware processor or memory transient error, loss or corruption of data in packets etc. One might think of addressing these problems at the lower level by providing duplicate copies, timeout and retries at each step. Even though the lower layers may provide correction mechanism but still the end system will have to perform end-to-end check for corruption during file reading or copying and host crashing. Thus, having the lower layer provide checks proves to be redundant and more of an overhead.
The argument is also supported by giving other examples like delivery guarantees, secure transmission of data, duplicate message suppression, FIFO message delivery, transaction management and encryption. End-to-end argument does not work in case of applications that require reliable delivery of message. In this case it is better to have checks for reliability at the lower layer than provide it at the application layer. Application layer checks will require retransmission of the complete message thus proving to be more expensive.
The end-to-end argument varies as per the requirement of the applications. It lays a good ground for layered architectures and is one of the main design principles used for Transport Control Protocol. Although the argument proposed in the paper is against the general notion of trying to put everything at the lower layer, but the supporting points given for the argument are relevant and make sense.
I feel that even though the argument and examples in the paper are relevant but providing everything at the higher layer may prove to be a drawback. This can raise security concerns. Programs at the application layer can be tampered with and may not run as expected. This is one of the issues that TCP faces. TCP Congestion Control with a Misbehaving Receiver paper by Savage et al. talks about how clients can misbehave and what should be done to address these problems.
The paper should be kept in the syllabus because it puts forward the issues one should think about before making a design decision. It also helps a person in understanding the decision made behind the TCP/IP protocol layered architecture. I also liked the paper presentation. The argument proposed by the author is supported by giving examples.
The argument is also supported by giving other examples like delivery guarantees, secure transmission of data, duplicate message suppression, FIFO message delivery, transaction management and encryption. End-to-end argument does not work in case of applications that require reliable delivery of message. In this case it is better to have checks for reliability at the lower layer than provide it at the application layer. Application layer checks will require retransmission of the complete message thus proving to be more expensive.
The end-to-end argument varies as per the requirement of the applications. It lays a good ground for layered architectures and is one of the main design principles used for Transport Control Protocol. Although the argument proposed in the paper is against the general notion of trying to put everything at the lower layer, but the supporting points given for the argument are relevant and make sense.
I feel that even though the argument and examples in the paper are relevant but providing everything at the higher layer may prove to be a drawback. This can raise security concerns. Programs at the application layer can be tampered with and may not run as expected. This is one of the issues that TCP faces. TCP Congestion Control with a Misbehaving Receiver paper by Savage et al. talks about how clients can misbehave and what should be done to address these problems.
The paper should be kept in the syllabus because it puts forward the issues one should think about before making a design decision. It also helps a person in understanding the decision made behind the TCP/IP protocol layered architecture. I also liked the paper presentation. The argument proposed by the author is supported by giving examples.
No comments:
Post a Comment