Subject: [alto] Some comments from IETF meeting & hallway talks

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Nov 2008 14:33:48 -0600

The Comcast experience suggests something critical:  Uploading on the  
local loop is not decreased (nor would you expect it to be,  
localization reduces traffic across the ISP boundary, not within the  
ISP boundary, but at least it doesn't INCREASE the uplink).

This is especially bad for cable companies, as the cost of adding  
local uplink bandwidth is extreme, and may be bad for other transport  
media.

Its also bad for performance:  if ALL users are on asymmetric links,  
the P2P system becomes limited by upload, not download.  Thus if you  
want users to get more performance than their uplink, you need to free- 
ride off of either completed users or other users (eg, dorm students)  
where bandwidth is symmetric.  Even with PERFECT locality, you end up  
with N-1 copies on the last-mile uplinks, and N copies on the last- 
mile downlinks.

Yet it suggests that cache + localization is a huge win, as bandwidth  
from a cache is nearly free (eliminating the uplink costs from the  
Intra-ISP traffic, and eliminating the uplink bandwidth as a  
performance limiter), while localization is a huge win on the ISP  
border.  Yet if the cache goes away, the system still works.

Thus I believe any alto service MUST support the following primitive/ 
notion:

"CACHE application version {file handler/tracker data}"

Which the ALTO service operator may then used to notify an application- 
specific cache in their network, and which clients are strongly  
encouraged to use (because it greatly increases their performance, but  
it doesn't make them more trackable in the open-world P2P).

Such P2P caches can be remarkably simple to build, as they are  
effectively normal clients that only allow connectivity from within  
the ISP, as long as they are notified about client participation: they  
have a huge win in reducing ISP costs, and simultaneously increasing  
user performance by getting the user's uplink out of the equation.

As I've mentioned before, for discovering an ALTO server, I believe  
DNS is the solution:

EG, Query alto.alto.org

If the ISP doesn't have an Alto information service, it does a normal  
lookup.  If the ISP does, the ISP's recursive resolver is configured  
to redirect to the local ALTO server.

This only breaks for those using 3rd party DNS services, and that can  
be fixed by having a "redirect" operation which the centralized  
alto.alto.org server uses to redirect to the ISP's server.

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto