Network end users to pull down 2 gigabytes a day, continuously?

Stephen Sprunk stephen at sprunk.org
Sun Jan 21 18:49:59 UTC 2007


[ Note: please do not send MIME/HTML messages to mailing lists ]

Thus spake Alexander Harrowell
> Good thinking. Where do I sign? Regarding your first point, it's 
> really
> surprising that existing P2P applications don't include topology
> awareness. After all, the underlying TCP already has mechanisms
> to perceive the relative nearness of a network entity - counting hops
> or round-trip latency. Imagine a BT-like client that searches for
> available torrents, and records the round-trip time to each host it
> contacts. These it places in a lookup table and picks the fastest
> responders to initiate the data transfer. Those are likely to be the
> closest, if not in distance then topologically, and the ones with the
> most bandwidth.

The BT algorithm favors peers with the best performance, not peers that 
are close.  You can rail against this all you want, but expecting users 
to do anything other than local optimization is a losing proposition.

The key is tuning the network so that local optimization coincides with 
global optimization.  As I said, I often get 10x the throughput with 
peers in Europe vs. peers in my own city.  You don't like that?  Well, 
rate-limit BT traffic at the ISP border and _don't_ rate-limit within 
the ISP.  (s/ISP/POP/ if desired)  Make the cheap bits fast and a the 
expensive bits slow, and clients will automatically select the cheapest 
path.

> Further, imagine that it caches the search -  so when you next seek
> a file, it checks for it first on the hosts nearest to it in its 
> "routing
> table", stepping down progressively if it's not there. It's a form of
> local-pref.

Experience shows that it's not necessary, though if it has a non-trivial 
positive effect I wouldn't be surprised if it shows up someday.

> It's a nice idea to collect popularity data at the ISP level, because
> the decision on what to load into the local torrent servers could be
> automated.

Note that collecting popularity data could be done at the edges without 
forcing all tracker requests through a transparent proxy.

> Once torrent X reaches a certain trigger level of popularity, the 
> local
> server grabs it and begins serving, and the local-pref function on the
> clients finds it. Meanwhile, we drink coffee.  However, it's a 
> potential
> DOS magnet - after all, P2P is really a botnet with a badge.

I don't see how.  If you detect that N customers are downloading a 
torrent, then having the ISP's peer download that torrent and serve it 
to the customers means you consume 1/N upstream bandwidth.  That's an 
anti-DOS :)

> And the point of a topology-aware P2P client is that it seeks the
> nearest host, so if you constrain it to the ISP local server only, 
> you're
> losing part of the point of P2P for no great saving in 
> peering/transit.

That's why I don't like the idea of transparent proxies for P2P; you can 
get 90% of the effect with 10% of the evilness by setting up sane 
rate-limits.

> As long as they don't interfere with the user's right to choose 
> someone
> else's content, fine.

If you're getting it from an STB, well, there may not be a way for users 
to add 3rd party torrents; how many users will be able to figure out how 
to add the torrent URLs (or know where to find said URLs) even if there 
is an option?  Remember, we're talking about Joe Sixpack here, not 
techies.

You would, however, be able to pick whatever STB you wanted (unless ISPs 
deliberately blocked competitors' services).

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




More information about the NANOG mailing list