Sunday, August 31, 2008

End-to-End Arguments, Saltzer, Reed, & Clark

This paper discusses the end-to-end argument, namely that functionality should be handled by applications rather than being pushed into lower levels of communication systems. It discusses the trade-offs associated with handling functions in low-level subsystems v.s. placing the functions closer to the applications level and presents various real scenarios, from encryption to duplicate message suppression to reliable data transmission, that provide support for the end-to-end argument.

One of the main arguments for the end-to-end strategy is that some operations, such as checksumming with file transmission, must be done at the applications level regardless, so adding that functionality to the communication system is redundant and at times costly in terms of delay. If a function is added to the low-level system, even applications that don't require said function will get it anyway, which can cause problems for applications like real-time speech transmission whose success depends on low delay in message delivery.

The issue is, of course, not completely cut-and-dried. Situations in which data reliability rather than minimized delay is important seem to go against the end-to-end argument; for example, in the case of reliable data transmission, without the communication system performing any checks, the transmission time for a file grows exponentially with the length of the file due to retries of sending and checksumming.

Clearly there must be some happy medium chosen to accomodate different application types. This paper sets the stage for the TCP/IP model to jump in and save the day. The separated internet and transport layers seem to provide a clean solution to address the needs of different applications.

The arguments presented seem to be a common theme in networking and architecture, that is, how much functionality to encapsulate from the applications/users and how much to let the applications handle themselves. The paper does a good job of acknowledging that both end-to-end and lower-level implementations work better for different sets of tasks and that the trick is to find a good balance between the two strategies; in this case, that "good balance" came from finding the right layering split.

Friday, August 29, 2008

Success!

In the very near future, this blog will contain summaries/criticisms of computer networking papers. If I get so ambitious, I might just stick the systems papers' ones up here, too. We'll see.