Reviewer: Chakchai So-In
Date: 1-25-2007
How would you rate this paper, relative to others we have read? top 50%, but not top 25%
How would you rate your knowledge of the topic of this paper? familiar, but not expert
What problem or issue does the paper address? Why is it important?
I believe the main issue here is finding the way to address the global naming for objects and making a middleware called DOT to serve as a transfer mechanism for all applications. To make use of the multiple sources, this service might have to run on top of BitTorent like.
What are the main contributions of the paper and why are they important?
The main contributions here are that first to propose the idea of separating the application control from the data transfer function (BULK data transfer application), second to design the transfer service architecture, and to do the comparison of the design with the existing application.
How significant are these contributions relative to previous work?
Give detailed comments justifying your view of the paper.
As they claim, DOT-based cache benefit directly since it serves for all application. A kind of content delivery network can apply this technique for example Akamai. This is obvious that by caching, the user will benefit but I am not sure if it has to be done at the user node rather than at the gateway (application proxy) because with this service, all nodes have to be modified. Another advantage is the multi-path transfer issue. In this case, I believe the performance comparison between a standard transport protocol such as SCTP should be evaluated. One that confuses me is about the mobility issue if it’s like NFS/AFS? What makes this service better than that? As they claim, it might be the same concept since theirs are like Internet Backplane Protocol (IBP)/ Blocks Extensible Exchange Protocol (BEEP). Also, multi-path function can be used toward the service plugin to support the surviving transient disconnection and mobility; however, the assumption there is at least one connection alive is still exist. In the paper, there is not much information on how this is done or how the traffic will be distributed (load balancing). It seems that the authors emphasize on the potable storage which I believe it’s just one of the several media that this service interface supports. The way the storage move (hand off) might not have a lot of overhead. From performance evaluation perspective, what they did is to compare their modification for the application to the existing application such as wget and scp. In term of overhead, it’s worse especially in fast network since they claim it’s because the hashing computation cost, which is computed before the data sent. For multi-path, as they claim it seems it’s working well but I am not sure if this simple set up can be represented the real world (this service is good at WAN) and if there is any needs for infrastructure modification. For portable storage performance, around 10 seconds to initialize the USB setup and might be some re-computation the authors do not mention. For Postfix case study, I wonder why they don’t compare DOT body and SMTP only body, and also DO compare the system with the application proxy. Actually, I don’t know much about Robin figure print technique; however, would it be possible to compare just Rabin fingure print technique without DOT? By saving the bytes sent which is obvious by caching, there is no detail on computational header. Moreover, for this case study, the only benefit seems to be from caching since just one application, so I wonder if the performance is better than the SMTP proxy.