Paper review: END-TO-END ARGUMENTS IN SYSTEM DESIGN
Reviewer: Kenneth Chin

1. State the problem the paper is trying to solve. 
This paper attempted to address the common issues that occur when a communication subsystem is designed. Often times, designers are trying to make a communication subsystem to incorporate or handle more features so as to alleviate the workload of the upper applications.

2. State the main contribution of the paper: solve a new problem, propose a new algorithm, or present a new evaluation (analysis). 
Through the awareness of "end-to-end arguments", it is clear that how a communication subsystem is designed in the sense that designer should have a better understanding of what functions or features should the system have.

3. If a new problem, why is the problem important? How do the authors solve the problem? If a new algorithm or new evaluation (analysis), what are the improvements over previous algorithm or evaluation? How do the authors show the improvements? 
Not applicable.

4. Summarize the (at most) 3 key main ideas (each in 1 sentence.)  
a) A communication model is divided into two main parts: a) application, b) data communication.
b) The data communication subsystem should be as generic as possible in the sense that it has all basic common functions adaptable to all kinds of applications.
c) Beware of tradeoffs in terms of performance and the functions/features that a communication subsystem supports. There is no rule of thumb as to how much work each party should have, but is solely determined by the situation adaptively.

5. Critique the main contribution
a) Rate the significance of the paper on a scale of 5 (breakthrough), 4 (significant contribution), 3 (modest contribution), 2 (incremental contribution), 1 (no contribution or negative contribution). Explain your rating in a sentence or two.
Rating: 3. It basically brought out the fact that communication system designers are often trying to pull in as many functions or features as possible. However, some of those proposed functions are duplicates, overdone or unnecessary. This paper gave sufficient examples explaining those misunderstandings.

b) What lessons should system researchers and builders take away from this work. What (if any) questions does this work leave open?
In this paper, the author was using a number of examples to support his idea that some functions should not be responsible by the communication subsystem. However, my view is that it is not always the case that we have to leave most of the functions to the application level especially in the case of highly unreliable network; if faulty packets can be detected, rejected, re-requested well before it arrives the application level, the performance of the network would be increased. Moreover, if some features can be done by speical hardware (e.g. simple encryption/decryption), the performace would be a lot better.