North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Perry Lorier
  • Date: Sun Jan 21 18:09:38 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)