Extreme congestion (was Re: inter-domain link recovery)

Sat Aug 18 14:29:43 UTC 2007

>
> We've been pitching the idea to bittorrent tracker authors to include 
> a BGP feed and prioritize peers that are in the same ASN as the user 
> himself, but they're having performance problems already so they're 
> not so keen on adding complexity. If it could be solved better at the 
> client level that might help, but the end user who pays flat rate has 
> little incentive to help the ISP in this case.
>

Many networking stacks have a "TCP_INFO" ioctl that can be used to query 
for more accurate statistics on how the TCP connection is fairing 
(number of retransmits, TCP's current estimate of the RTT (and jitter), 
etc).  I've always pondered if bittorrent clients made use of this to 
better choose which connections to prefer and which ones to avoid.  I'm 
unfortunately unsure if windows has anything similar.

One problem with having clients only getting told about clients that are 
near to them is that the network starts forming "cliques".  Each clique 
works as a separate network and you can end up with silly things like 
one clique being full of seeders, and another clique not even having any 
seeders at all.  Obviously this means that a tracker has to send a 
handful of addresses of clients outside the "clique" network that the 
current client belongs to.

You want to make hosts talk to people that are close to you, you want to 
make sure that hosts don't form cliques, and you want something that a 
tracker can very quickly figure out from information that is easily 
available to people who run trackers.  My thought here was to sort all 
the IP addresses, and send the next 'n' IP addresses after the client IP 
as well as some random ones.  If we assume that IP's are generally 
allocated in contiguous groups then this means that clients should be 
generally at least told about people nearby, and hopefully that these 
hosts aren't too far apart (at least likely to be within a LIR or RIR).  
This should be able to be done in O(log n) which should be fairly efficient.