1. A Criticism of: “Moving beyond end-to-end path information to optimize CDN performance” Gautam Bhawsar Alok Rakkhit

2. Data From two 24-hour periods in May 2008 and August 2008 –But were the periods really representative? Claim improvements in this time are result of their system –Ignoring many other factors

3. Pruning the dataset Start with 173k prefixes, but end up using only 52% of them! Remove 21k prefixes for physically impossible RTT Remove 42k for unreliable geolocation data –Those remaining still have as little as 83% confidence for country 67% for prefix

4. Cause of queuing delay? As referred in the paper, they assume cause of queuing delay to be access links. Perhaps, Queuing delays are proportional to size of buffer at the router and depends on the congestion.

5. How big is the problem really? “More than 20% of prefixes experience minimum RTTs that are more than 50ms greater than the minimum RTT measured to other prefixes in the same region.” Is 50ms really significant? Considering the low confidence for prefix location, is that even unusual?

6. The exception to the rule “A new node in Japan was added to the Google CDN. While this decreased the minimum round trip times (RTTs) for clients in that region, the worst-case RTTs remained unchanged.” Only the worst case? –Presumably, the average RTT increased –Data will always have outliers

7. Four Causes and how WhyHigh doesn’t fix them Lack of peering –Outside AS must form new connections Limited Bandwidth –ISP is only entity that can control this Routing Misconfiguration –ISP is responsible for dealing with this Traffic Engineering –Yet again, ISP must fix this

8. Example Cases In two of the cases the problem was lack of bandwidth on ISPs link(s) –One of which was “resolved” by the ISP upgrading its capacity The other two were due to lack of linkage to new nodes

9. The real problem All problems are found to be worse for new nodes Instead of hunting down prefixes, work on getting nearby ISPs to route traffic to their new nodes

10. Unanswered questions Many questions still remain open on the cause for poor latencies we observe from clients to nearby nodes, e.g., “where are packets being queued to result in the congestion overhead we observe?“ Never mention what improvement there was, except for one node Wasn’t WhyHigh supposed to determine the reasons for overhead? Lack of evidence to prove cause of inflation in Reverse Paths.

11. Conclusion Data may not be reliable Problem may not even be that significant Problems are not solved, nor are the problems solvable by the CDN provider