Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

["Michael J. Freedman" <[e-mail]>]

Nicholas Weaver wrote:
> Ono is leveraging off Akamai's DNS information:  You do a few queries to 
> akamai'ed (and other CDN'ed) domains, and use the results as a 
> coordinate space.
> 
> The question is the simpler coordinate: "who's MY resolver and who else 
> uses it".

CoralCDN did something very similar to this at first.  In fact, in 
addition to inserting a <DNS resolver, serverid> entry in the Coral DHT, 
it also tracerouted the resolver (of our proxy servers).  If the 
resulting last-hop IP addresses were a "relatively good match" for the 
resolver, we would store these "network topology" hints in our DHT as 
well.  (This conditional check was to avoid cases when "last 
traceroute-able hops" were quite distant from the destination, 
especially given the fact that many hosts and routers don't actually 
reply to traceroute probes these days.)

The goal of this was to perform topological clustering of our peers, 
much as you suggest:  When a client would perform a DNS request, we 
would synchronously traceroute the client's DNS resolver (we built a 
very fast tool that would return in ~2 network RTTs), do a DHT lookup on 
these the resolver and its last hops, and use any returned information 
in our selection of "nearby" CoralCDN web proxies.

Unfortunately, it didn't really work.  I can't cite the precise numbers 
off-hand, but we were seeing hit rates in the low single-digits.  Thus, 
the delay clients were experiencing for all this network hackery was 
totally out-of-proportion to its benefit.  (And when this hackery would 
occasionally take more than two seconds, the client's DNS resolver would 
happily reissue DNS requests to other Coral DNS servers, losing all the 
previous work already done.)

In short, we stopped using this technique after CoralCDN was deployed 
for a few months.  In fact, the experience of needing to return accurate 
responses very quickly led us to design and build another system, OASIS, 
that tries to build stable network maps that other services can use as a 
peer-selection oracle.

Now, one should be careful in trying to extend these lessons to the P2P 
file-sharing setting, as CoralCDN focused on web content, thus had much 
tighter latency requirements than a lot of file-sharing applications. 
Second, our use of a decentralized DHT, especially deployed on flaky 
PlanetLab servers, made meta-data loss more prevalent than one might 
find in cluster storage.  Third, and perhaps most importantly, the
"CoralCDN proxies" we were mapping clients to were largely deployed on 
university networks, while our client population was well-distributed 
over the entire Internet:  at the time, 100,000s-1M distinct clients IP 
addresses (and 10,000s of distinct DNS resolvers) per day.

On the flip side, I wouldn't completely discount these results.  Many of 
the very peers that contribute large amounts of upstream bandwidth on 
P2P systems are *also* on university networks (both because of their 
high upstream capacity and their lack of NATing compared to home users).

As an aside, ALTO seems to have many similar goals as the IETF 
SONAR/HOPs work in the mid-to-late 90s, although perhaps with more focus 
on ISP buy-in.  Thoughts?

Regards,
--mike


References:

   CoralCDN, http://www.coralcdn.org/
   NSDI 2004 paper: http://www.coralcdn.org/docs/coral-nsdi04.pdf

   OASIS, http://oasis.coralcdn.org/
   NSDI 2006 paper: http://www.coralcdn.org/docs/oasis-nsdi06.pdf


> On Oct 21, 2008, at 2:05 PM, Vijay K. Gurbani wrote:
> 
>> Nicholas Weaver wrote:
>>> Hey, stupid thought...
>>> Could you do proximity based on "who's your DNS resolver"?  Do a few 
>>> name lookups: one to register YOU as using YOUR DNS resolver to the 
>>> remote coordinator, and one to get "who are other peers using the 
>>> same resolver"?
>>> An ugly, UGLY hack, but it might be interesting to think about.
>>> Has anyone done this already?
>>
>> Doesn't Ono [1] do that?  Or am I missing something?  CDNs also
>> use DNS redirects to redirect clients to nearest servers.
>>
>> [1] David R. Choffnes and Fabián E. Bustamante. Taming the Torrent:
>>    A practical approach to reducing cross-ISP traffic in P2P
>>    systems, Proc. of ACM SIGCOMM 2008, August 2008.
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi