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

Re: Google wants to be your Internet

  • From: Stephen Sprunk
  • Date: Sun Jan 21 00:39:05 2007

Thus spake "Jeremy Chadwick" <[email protected]> 
Chances are that other torrent client authors are going to see
[BitThief] as "major defiance" and start implementing things like
filtering what client can connect to who based on the client name/ID
string (ex. uTorrent, Azureus, MainLine), which as we all know, is
going to last maybe 3 weeks.

BitComet has virtually dropped off the face of the 'net since the authors decided to not honor the "private" flag. Even public trackers _that do not serve private torrents_ frequently block it out of community solidarity. Note that the blocking hasn't been incorporated into clients, because it's largely unnecessary.

This in turn will solicit the BitThief authors implementing a feature
that allows the client to either spoof its client name or use randomly-
generated ones. Rinse lather repeat, until everyone is fighting rather
than cooperating.

Will the BT protocol be reformed to address this? 50/50 chance.

There are lots of smart folks working on improving the tit-for-tat mechanism, and I bet the algorithm (but _not_ the protocol) implemented in popular clients will be tuned to adjust for freeloaders over time. However, the vast majority of people are going to use clients that implement things as intended because (a) it's simpler, and (b) it performs better. Freeloading does work, but it takes several times as long to download files even with the existing, easily-exploited mechanisms.

Note that all it takes to turn any standard client into a BitThief is tuning a few of the easily-accessible parameters (e.g. max connections, connection rate, and upload rate). As many folks have found out with various P2P clients over the years, doing so really hurts you in practice, but you can freeload anything you want if you have patience. This is not particularly novel research; it just quantifies common knowledge.

The result of these items already been shown: BT encryption.  I
personally know of 3 individuals who have their client to use en-
cryption only (disabling non-encrypted connection support).  For
security?  Nope -- solely because their ISP uses a rate limiting
device.

Bram Cohen's official statement is that using encryption to get
around this "is silly" because "not many ISPs are implementing
such devices" (maybe not *right now*, Bram, but in the next year
or two, they likely will):

http://bramcohen.livejournal.com/29886.html

Bram is delusional; few ISPs these days _don't_ implement rate-limiting for BT traffic. And, in response, nearly every client implements encryption to get around it. The root problem is ISPs aren't trying to solve the problem the right way -- they're seeing BT taking up huge amounts of BW and are trying to stop that, instead of trying to divert that traffic so that it costs them less to deliver.

( My ISP doesn't limit BT, but I've talked with their tech support folks and the response was that if I use "excessive" bandwidth they'll rate-limit my entire port regardless of protocol. They gave me a ballpark of what "excessive" means to them, I set my client below that level, and I've never had a problem. This works better for me since all my non-BT traffic isn't competing for limited port bandwidth, and it works better for them since my BT traffic is unencrypted and easy to de-prioritize -- but they don't limit it per se, just mark it to be dropped first during congestion, which is fair. Everyone wins. )

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