============================================================================
REVIEWER #1
============================================================================
---------------------------------------------------------------------------
Reviewer's Scores
---------------------------------------------------------------------------
Originality: 5
Contribution: 5
Technical Correctness: 5
Overall Score: 5
---------------------------------------------------------------------------
Comments
---------------------------------------------------------------------------
The paper describes an innovative ways to derive network proximity with other
nodes using existing CDNs.
The paper is in general pretty well written with a very simple solution for a
very complex problem - which is the key to a novel solution.
Some mention about how many CDN request is needed to appropriately derive the
network positioning will be good to have in the paper. The accuracy will depend
on the long history of requests through CDN network, so with short history of
CDN request I expect the accuracy to be much smaller. Some idea on how the
accuracy reduces with the number of requests through CDN network will be good
to have.
Also it is not clear, can the system use the existing browser and its
request-response to derive this CDN data or for this explicit request need to
be sent through CDN to derive the proximity.
Also the system will perform poorly in the very beginning with very limited
data. Discussion in that respect is required to understand the pros and cons of
the approach.
============================================================================
REVIEWER #2
============================================================================
---------------------------------------------------------------------------
Reviewer's Scores
---------------------------------------------------------------------------
Originality: 4
Contribution: 4
Technical Correctness: 4
Overall Score: 4
---------------------------------------------------------------------------
Comments
---------------------------------------------------------------------------
This paper proposes CRP, a CDN-based Relative Network Positioning scheme, for
measuring relative distances between nodes. This is achieved through
calculating the Cosine similarity based on redirection map, which is associated
with each node and constructed from information provided by the existing CDN
infrastructure. Compared with similar work of the same objectives, the
advantage is that it removes direct probing of the CDN nodes and makes the
positioning operation scalable, by exploiting the dynamic associations of
client nodes with the CDN nodes provided by existing CDN infrastructure. While
the application of the approach is limited to positioning within the CDN
network, the idea is innovative and achieves accuracy similar to existing
approaches but with smaller cost.
============================================================================
REVIEWER #3
============================================================================
---------------------------------------------------------------------------
Reviewer's Scores
---------------------------------------------------------------------------
Originality: 3
Contribution: 2
Technical Correctness: 2
Overall Score: 3
---------------------------------------------------------------------------
Comments
---------------------------------------------------------------------------
This paper presents CRP that can avoid direct probing by taking
advantage from CDN servers. CRP exploits the dynamic association of
nodes with CDN servers to determine the relative positions of nodes by
calculating their virtual distance. Experiments were conducted with
PlanetLab nodes, which shows for RELATIVE positioning, it achieves a
trade-off between the accuracy and the cost.
This is an interesting experimental paper. However, there are several
problems that are not considered/addressed in the paper.
1. CRP completely relies on the private CDN infrastructure. The
implicit assumptions behind CRP are that CDN uses some "effective,
fair" load balancing strategies and CDN nodes are evenly
distributed and CDN servers evenly duplicates the content for a
particular subscribers, etc..
Unfortunately, these are largely not true. For example, the content
duplication is on-demand. If at a time there are a number of requests
from a particular area, many CDN servers in that area could be loaded
with the content copy, while there are much less servers in other
areas. Thus, the "errors" as demonstrated by your experiments will be
frequent. The relative distance calculation will be meaningless. For
another example, CDN servers could also be down.
2. CRP, also implicitly assumes that the nodes are aware of the
underlying CDN support, which is not always possible. Common nodes
do not care about which CDN is serving them, and would not
differentiate whether the services they accessed were supported by
the same CDN company or different ones. Authors did not discuss
this problem at all.
3. CRP, if to avoid active probing traffic, requires the nodes must
have accessed the some services that are supported by the same
CDN. How could you enforce nodes that are not interested in Fox
news to access it without calling this active probing traffic?
4. I am not convinced that the active probing traffic is
a significant problem today. Otherwise, how these CDN companies
determine which server is the best to serve a client?
5. The most interesting part is the experiments conducted. But it is
not clear, for example, how did you leverage Akamai CDN
redirections using yahoo and fox? what is the window size for
closest node selection? why using CDF in figure 6 which compressed
too much error?
6. Last but not the least, CDN, and their service subscribers may
prohibit being taken advantage from. CDN companies may
disappear. CDN servers are constantly up and down. Relying on the
proprietary CDN infrastructure for positioning is dangerous unless
its policies regarding how servers are deployed, how load is
balanced, etc are public.
============================================================================
REVIEWER #4
============================================================================
---------------------------------------------------------------------------
Reviewer's Scores
---------------------------------------------------------------------------
Originality: 2
Contribution: 2
Technical Correctness: 2
Overall Score: 3
---------------------------------------------------------------------------
Comments
---------------------------------------------------------------------------
This was a well written paper. The authors build on their prior work [42] and
use CDN redirection to measure relative network positioning. Their hypothesis
is that if DNS requests to CDN servers from two different clients returned the
same replicas then these nodes must be close together (because, Akamai tended
to use the network latency to return closest server, at least in the case of
Fox [42]). They use the cosine similarity to use the vector of Akamai replica
servers to understand relative position. Some of my concerns with the paper
include:
a) The paper is thorough. However, it could be significantly simplified by not
describing marginally related work. For example, a significant number of
references are for papers that show the importance of relative positioning.
b) The number of active Akamai replicas was small (20 - Section III-B). Also,
certain geographical locations are not well covered (eg. India, Brazil etc.
where the redirected replicas landed in the US (Section V.A)). Most of the
Planetlab nodes tend to reside in Europe and North America. I am not sure where
the DNS servers used in their studies reside. I wonder if the comparison
between their approach and an approach that randomly chose a Planetlab node
would achieve similar latency error as a comparison between their approach and
Meridian (for example, Figure 4). Since the number of active Akamai replicas
was small, their cosine similarity metrics were likely easier to calculate.
However, this reduces the granularity/accuracy of the system. Planetlab nodes
are likely on high speed backbones with very little latency to other parts of
the Internet (as compared to a broadband host).
The graphs are hard to read. For example, Figure 4 is hard to differentiate
between CRP Top1 and Top5. It would be interesting to plot the graphs for a
y-axis range of 0:40 (or a reasonable latency to a random planetlab node (from
a DNS server).