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

Sun Jan 21 23:01:40 UTC 2007

> 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. 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.

When I investigated bit torrent clients a couple of years ago, the 
tracker would only send you a small subset of it's peers at random, so 
as a client you often weren't told about the peer that was right beside 
you.  Trackers could in theory send you peers that were close to you (eg 
send you anyone thats in the same /24, a few from the same /16, a few 
more from the same /8 and a handful from other places.  But the tracker 
has no idea which areas you get good speeds to, and generally wants to 
be as simple as possible.

Also in most unixes you can query the tcp stack to ask for it's current 
estimate of the rtt on a TCP connection with:

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/tcp.h>
#include <stdio.h>

int fd;
struct tcp_info tcpinfo;
socklen_t len = sizeof(tcpinfo);

if (getsockopt(fd,SOL_TCP,TCP_INFO,&tcpinfo,&len)!=-1) {
   printf("estimated rtt: %.04f (seconds)", tcpinfo.tcpi_rtt/1000000.0);
}

Due to rate limiting you can often find you'll get very similar 
performance to a reasonably large subset of your peers, so using tcp's 
rtt estimate as a tie breaker might provide a reasonable cost savings to 
the ISP (although the end user probably won't notice the difference)