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
