1. Postcards from the Edge – Offense Presented by: Sam McIngvale Rob Kotz

2. General Premise  Why Cache-N-Forward?  The authors argue that advances in wireless technology will render the current Internet architecture useless.  How?  What makes new mobile devices ‘unstable’?  TCP has been effective thus far…why change?

3. General Premise v2.0  What are the benefits of Cache-N- Forward?  How will changing the current architecture fix the ‘unstability’?  Will there be an increase in speed?  Will there be an increase in throughput?  What will be different?  Why should I want to change?

4. General Premise v3.0  Paper argues the need to ‘push complexity into the network and make the end-to-end transport protocol simpler.’  This conjecture contradicts the fundamental principle the original Internet was built-on.  Keeping the network simple has gotten us this far…why change?  The authors offer no reasoning to support where this conjecture comes from.

5. General Premise v4.0  Is Cache-N-Forward a new architecture?  All that is happening is the file is getting moved somewhere closer to the requesting end-user.  Then the end-user receives the file via a ‘TCP-like’ protocol.  Should we implement a new architecture that only improves large file-transfer?  Real-time applications are increasing and user- experience (QoS) is a major concern.

6. Overhead  How much overhead will Cache-n- Forwarding introduce into the Internet?  We don’t know because the authors don’t tell us.  Reading/Writing files to disk at each hop will dramatically slow-down the rate of transmission.  Disk I/O is already the limiting factor for many operations.

7. Overhead v2.0  For a single mobile-device (end-user) to request a file, the following steps must take place:  The receiver contacts a file name resolution service to resolve the location of the requested file.  The receiver looks-up the host in DNS.  The receiver sends a query to the sender.  The sender contacts a name resolution service that resolves the name of the mobile host to a set of PO nodes.  The sender forwards the file to one or more PO’s.  PO’s hold the file until contacted by end-user to arrange delivery.  Finally, there is delivery of the file via direct-transmission (TCP?).  I would much rather just take my file directly.

8. Overhead v3.0  This architecture is not appropriate for real-time applications.  Definitely does not solve any issues with QoS – a major concern for future architectures.  All we get is a guarantee of delivery (already present with TCP) but we sacrifice extreme transfer times.

9. Current State of Proposal  The authors recognize several key questions that still remain with their architecture.  How should routing be integrated with caching?  How do we implement congestion control?  What are the storage needs of a CNF node?  What are the necessary post office descriptors?  How do we specify routing tables?  How should cache-based multicast be implemented?  Why I am I writing this paper?  What is the Internet?

10. Current State of Proposal v2.0  This is an Internet Architecture proposal.  You CANNOT leave important issues such as routing tables and congestion control up in the air.  We would like to argue specific (low- level) design and implementation issues, but the design is so high-level there is nothing to argue about.

11. Current State of Proposal v3.0  The Wireless Revolution the authors are hoping to address is happening right now.  By the time their architecture is anywhere near a state that can be deployed, this issue will have been solved or addressed (if it needs to be).

12. Evaluation?  Instead of offering concrete results to support their conjectures we are presented with the difficulties of testing such an architecture  There are no concrete results to support the validation of this new architecture  It’s ok though…we have an Impact Statement and Intellectual Merit…

13. Deployment?  The authors offer no plan for deployment.  They are proposing a major ($$$$) overhaul of the Internet – for this to ever happen there must be:  1) Concrete results to justify the change.  2) Some plan to completely change the current infrastructure.  Neither of these issues are addresses.

14. Conclusion  Does not feel like a science paper.  The authors make wild claims with absolutely no backing evidence.  There is no evaluation of their proposed architecture.  Seems this paper is more of a preliminary outline of a project yet to be completed.