Reviews - HotNets VI Submission

Preface

The raw reviews are provided for the benefit of the reader to place the work into context. As one may guess, two definite rejects and a weak reject does not an acceptance make. You may also find our detailed response to the review here.

Review

Greetings,

We are writing about your paper

Title

Reducing CDNs to ABC: Scalability and Centralization Can Play Nice Together Paper site: http://hotnets.ucsd.edu/hotnets6/paper.php?paperId=48

submitted to HotNets? VI. We regret to inform you that we were not able to accept your paper. We received 124 submissions this year, and accepted only 22. As a result, we were unable to take a number of worthwhile papers.

The full program will be available on-line close to the time of the conference, at:

http://www.acm.org/sigs/sigcomm/HotNets-VI/

Please find appended feedback from the reviewers, which we hope proves helpful in your further pursuit of the work you submitted. We want to thank you for submitting your paper, and hope you will consider submitting to HotNets? in the future.

- Stefan & Vern

======================================================================= HotNets? VI Review #48A Updated Wednesday 19 Sep 2007 11:50:18pm PDT

---

Paper #48: Reducing CDNs to ABC: Scalability and Centralization Can Play Nice Together

---

Overall merit: 1. Reject

= Summarize most valuable contributions =

Challenges conventional wisdom with regarding to scalability being at odds with centralization. Their approach to content distribution is to keep the content at a centralized server but use edge boxes that interact with the servers to efficiently distribute the content.

= Summarize most significant problems =

First, I found the paper so hard to read that I often really couldn't tell just how various mechanisms work. From what I could tell, however, it appears that quite a bit of the scalability gain is simply the use of compression to reduce content repeated to multiple recipients (along with some extra hacks whose correctness/utility is not established). This has problems, as I frame below.

In addition, the paper doesn't offer any empirical evidence regarding the degree to which compression opportunities will arise (other than "Recent examinations of the university tap" without any details).

= Comments for author =

"private user goodness" and "what immerses the user" in the first paragraph are both confusing phrases.

Please provide a citation for YouTube? finding centralization a necessity.

For on-line games, centralization is driven not only by security/quality controls, but (arguably much more so) by interactivity, which can't be achieved in a loosely coupled distributed manner.

"scurrilous" is a pretty strong word, and likely not really what the authors wish to convey about their postulation.

In 2, the sentence "For the purposes of simplicity" appears twice.

Caching on a per-packet basis seems to not be a great granularity, since the same content can easily be packetized along different boundaries (e.g., due to slightly different length HTTP headers).

In the discussion of Stealth Multicast, which nodes are the multicast receivers? How do they decide to join the group?

More generally, the scheme appears to require a zillion bilateral configurations between ISPs and servers. How can that scale management-wise? How can an ISP possibly arrange deals with all of the servers with which its customers might engage?

Why in figure 3 were the 3WHS, HTTP request, and connection closure ignored?

TCP Vegas is not a "more aggressive algorithm".

"Rather than tying replicated contact to explicit agreements" - businesses generally want explicit agreements in matters concerning their resource allocations.

======================================================================= HotNets? VI Review #48B Updated Saturday 22 Sep 2007 10:35:55pm PDT

---

Paper #48: Reducing CDNs to ABC: Scalability and Centralization Can Play Nice Together

---

Overall merit: 1. Reject

= Summarize most valuable contributions =

This paper revisits the notion of transparent middleboxes to improve the scalability of content delivery. The authors introduce the "ScaleBox", which performs transparent packet caching, transparent multicast, and transparent prefetching, as long as there is one ScaleBox near the content provider, and multiple ScaleBoxes located at the ISPs near the clients.

= Summarize most significant problems =

The techniques used is the ScaleBox are not terribly novel, and the details of how they make things work are not terribly clear. There is also something about the writing style of this paper that really rubbed me the wrong way. For example: "ScaleBox offers something of an anomaly in the network world, scalability and performance despite centralized serving akin to the colloquial phrase of having one's cake and eating it too."

= Comments for author =

You need explain how "tail streaming" is either different than or the same as stream merging, a well-known technique developed for streaming media. See "Minimizing Bandwidth Requirements for On-Demand Data Delivery" by Derek Eager, Mary Vernon, and John Zahorjan in IEEE Transactions on Knowlege and Data Engineering, 2001.

======================================================================= HotNets? VI Review #48C Updated Sunday 23 Sep 2007 2:57:21am PDT

---

Paper #48: Reducing CDNs to ABC: Scalability and Centralization Can Play Nice Together

---

Overall merit: 2. Weak reject

= Summarize most valuable contributions =

This paper proposes to have a two-layered design for content delivery. In the first layer, local ISPs deploy application-agnostic, packet data-level caching in coordination with content providers. In the second-layer, end users fetch content from the local caches using some form of multicast.

= Summarize most significant problems =

While the core ideas appear interesting, the paper does a poor job of defining the architecture it is proposing clearly, arguing and quantifying what the benefits are, and explaining what incentives there are for ISPs and content providers to deploy this architecture.

The paper is also very poorly written which makes it hard to understand what is being proposed.

The whole motivation of offering centralized content distribution (in the introduction) is confusing and is irrelevant to the archtiecture being proposed.

= Comments for author =

The largest problem I had with this paper was the writing often obscured the ideas being presented. While the ideas presented might be be good the presentation did not convince me of that.

I would try to more systematically define the parts of you architecture and the gains that are obtained from different components. Also I would like to see a more concrete comparison between the three approaches talked about in the paper (Centralized, CDN, ScaleBox) and what the tradeoffs between each are under different situations.

At times I felt like you were making more philosophical arguments rather than technical ones. While this may be fitting for a workshop such as HotNets? , I feel like your bold statements need to be better grounded in a technical basis.

I would go through your paper and make sure that all terms you use are clearly defined. You mention the term centralized distribution in the third paragraph of the introduction. I have no idea what you mean by this and this left me confused for a while. I decided that you meant centralized at one site, but distributed over multiple machines. Another example is the introduction of the term "mice" packets, maybe this is a common term I'm not familiar with but I was confuse by this as well.

In the body of the paper I felt like you were bringing up ideas and then immediately moving on to the details of the implementation. If you could explain each of the components at a high level and then have subsection that discuss them in more depth this might make it more clear to me what exactly you are doing. For example the text under heading 2 could have been expanded and some of the other details later in the paper omitted. I would suggest having subsections for "Goals", "Components", "Packet Caching", and "Stealth Multicast". I would spend much more time on these sections as they are the basis of your idea. You spend a huge amount of space discussing TCP fairness in 2.1, which I felt while important, was tangential to your main point.

Some of the 2.4 points should be discussed earlier. For example, I was asking the question "Isn't this merely a camouflaged CDN?" very early in the paper. If you could anticipate this earlier and head it off. Perhaps in the first part of 2 or in the introduction. Again as I said earlier, perhaps a section comparing the architecture of CDNs, Centralized and ScaleBox could be added which would make this point crystal clear.