On Oct 14, 2008, at 1:07 PM, Ye WANG wrote:

On Tue, Oct 14, 2008 at 10:55 AM, Nicholas Weaver <[EMAIL PROTECTED] > wrote:

On Oct 14, 2008, at 7:40 AM, Lars Eggert wrote:

FYI, there's at least one more proposal in this space: the Ono stuff from Northwestern (http://www.aqualab.cs.northwestern.edu/projects/Ono.html ). There was a paper at SIGCOMM this year, and their system has the interesting feature that it simply freeloads of Akamai's DNS entries in order to determine who's close to whom. No "ALTO boxes" needed.

Basically, this is freeloading on the akamai DNS infrastructure to create a "topology oracle": which nodes are close in terms of network topology as a common proxy for bandwidth.

It doesn't need "ALTO boxes" only because someone else has colleced that information, and that there is a separation between the query replying infrastructure (through DNS) and the measurement infrastructure.

However, it does bring up a good point: DNS games allow the ability to divorce the measurement infrastructure from the reporting infrastructure, and to create a reporting infrastructure that can always work both with and without ISP cooperation.

This is a very good comment on the architecture on "ALTO box". Just to clarify on a risk of building an Internet infrastructure based on a hack of
using the Akamai DNS infrastructure to create a "topology oracle".
You may already know it, but some others may not. So I would like to
point it out.

Akamai DNS redirection considers not only topology, but also Akamai's own server state, and Akamai's own redirection policy. To illustrate this, consider a simple example where Akamai temporarily (e.g., during maintenance, or misconfiguration, or under attack, or whatever reason) redirects users from distant geographic locations to the same set of servers. This may result in these users being deemed "close together" when in fact they are not.

This is not limited to Akamai. DNS redirection typically considers not
only topology, but also the state and policy of whoever controls it.


To be fair, I don't think anyone was recommending Ono, merely noting it was one that has been proposed and so should be included in the list. While a cute systems hack that might make something work better today, it's pretty clearly not a good interoperable and long-term solution.

Phil
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to