1. An Architecture for Internet Data Transfer Offence by: Aaron Ballew Sagar Vemuri

2. Stated Problems Inappropriate for real-time communication – telnet, teleconferencing DOT uses batch transfer technique – Imposes latency for time-critical apps Does not work well for communication which is primary “control data” – Instant messaging

3. Fundamental Motivation For a generic service, DOT already carves out a subset of application traffic (won’t work for x,y,z…). Then even for file transfers, it only works well for large transfers that can amortize the overhead of hashing, handshaking, control, etc. For such a specific audience, how is this generic?

4. Handshaking “DOT begins transferring data only after both sending and receiving apps are ready.” – What if one of them is not ready? Overhead of hashes, long negotiation/handshake. Can’t handshake over portable storage, and the authors are big supporters of portable storage. If one hashing algorithm is supported by the sender but not by the receiver – How is hashing accomplished?

5. Security Increases security risk by having all the data at one place Privacy issues – Inspecting application data Doesn’t work if encryption is required Currently, data transfer depends on the application protocol implementation But in DOT, the data transfer is application independent – Hence much easier to gain access to all the data

6. Cache Issues Newer data might overwrite the cached data at the receiver end before the receiver reads it No mention about the requirement for the size of cache In case of session break, GTC caches. How to time-out if it doesn’t reconnect? Who says this data can just be retained in cache?

7. Hints Hints about where to find data. Why doesn’t sender just tell where to find data? How does sender know where to find data?

8. Deployment How are dynamically generated objects transferred? Need to modify all the existing applications to support DOT, i.e. make application requests look like RPCs. No mention of deployment anywhere Is incremental deployment possible? Requires that new applications be written to use this.

9. Incentive to use If generic service chooses TCP anyway, why not just use TCP? Isn’t this just adding a new layer to the OSI/TCP/IP model? Is there any enforcement to use this? Why would anyone use it when they could just purpose-build and optimize for their app? They say it promotes innovation, but why would industry implement this?

10. Multipath For multipath, why 10 requests per sub-plugin? How to choose and balance on paths? How to deal with out of order data? How to reallocate when a sub-path fails? They give one sentence. What if there is more than one hop in each sub- path? How is GTC supposed to balance w/o any feedback info? Leave this to routing.

11. Evaluation Evaluation purposely ignores small transfers, knowing that the system performs worse under that case (4kB vs. 40kB). Eval focuses only on means. Need to know more about the statistics, namely the variance. Mean of 10 trials, mean of 255MB, etc. Assuming linear performance scale. 10 trials is a small sample set. Says DOT saves 20% of msg bytes, where is this from? Graph shows 14%.

12. Conclusion Not generic enough. Too many major problems identified (by the authors) and not addressed. No incentive to use it. Significance of improvements are unimpressive.