Google wants to be your Internet

Sun Jan 21 05:13:37 UTC 2007

Thus spake "Jeremy Chadwick" <nanog at jdc.parodius.com>
> 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 