A Criticism of Moving beyond endtoend path information

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

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

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

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.

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

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

Four Causes and how Why. High 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

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

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

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 Why. High supposed to determine the reasons for overhead? • Lack of evidence to prove cause of inflation in Reverse Paths.

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