Bittorrent Implements Cache Discovery Protocol

An anonymous reader writes "CacheLogic and BitTorrent introduce an open-source Cache Discovery Protocol (CDP) that allows ISP's to cache and seed Bittorrent traffic. Currently, Bittorrent traffic is suffering from bandwidth throttling ISP's that claim that Bittorrent traffic is cluttering their pipes. This motivated the developers of the most popular Bittorrent clients implement protocol encryption to protect bittorrent users from being slowed down by their ISP's. However, Bram Cohen, the founder of Bittorrent doubted that encryption was the solution, and found (together with CacheLogic) a more ISP friendly alternative."

Comments

i wanna go fast

[MrSquirrel]

We have the technology -- we can make him stronger, faster, better! ...now, if only there were some more seeders.

Re:i wanna go fast

[arivanov]

More likely fast in terms of "lawyers homing fast".

Anyway, the problem is elsewhere. It all boils down to Telco thinking combined with incompetence. ISPs have degenerated to the point of being either telco resellers or telco wannabies and they are no longer capable of solving a trivial problem through network design and product definition. So they try a silver bullet (CacheLogic) or a big stick (fare share, bandwidth throttle and "kick the hogs" policies) instead.

Once upon a time around 10+ years ago it was commonplace to charge people for traffic and to have multiple charge categories with local traffic free or nearly free. That was in the days before the big telcos became interested in the Internet. When the big telcos became interested in the Internet the first thing they pushed for was to increase port density and bandwidth on access concentrators and routers. In order to do this the vendors killed the bandwidth accounting features. Best example - Cisco Netflow stopped working in 1999-2000 with the release of CEF (can give plenty of other examples actually).

As a result of the normal equipment upgrade cycle 10 years later there are very few devices out there capable (and tested in real deployments) of bandwidth accounting on the edge. Even if there were, as a result of the "people upgrade cycle" there are even less people in ISP business development and engineering capable of defining, developing and rolling out a bandwidth accounting based product.

If the charging was based on bandwidth accounting and local traffic was free (or seriously discounted) the "bandwidth hogs" problem would go away right away. So will most of the "Joe Idiot" problems related to people not cleaning their zombie machines (when these start costing them money they will be cleaned right away). People will again start running local network services for community purposes. For example I used to run centralised network backup for some friends but I stopped as eats the monthly "fair use" quota allocated to me by the ISP in less than a week. And so on.

The only people who will actually suffer from the reintroduction of bandwidth and differentiated charging will be c***sucking freeloaders of the Nichlaus Zenstrom "it is my right to steal your bandwidth for my service" variety. And CacheLogic (the economical drive to buy their device will go away). Frankly, good bye and good riddance.

Off the cuff thought

[Arimus]

Just read this and wonder what the legal position for ISP's will be with regards to caching non-legal P2P files (warez, music files etc)?

With the files being on my PC and served from my PC I'm the responsible party... if the ISP then is caching that data to make it more available (speed/latency/load reduction etc) then the ISP could be deemed to being a party to an illegal act...

Re:Off the cuff thought

[zhouray]

I assumed you didn't read the article. It says "only for commercially licensed content".

Re:Off the cuff thought

[muftak]

On the cache the files are stored as file chunks, with only a reference to the file hash value, not the filename. So the ISP has no idea what is in the cache, so it is the same as the file being passed through their network.

Re:Off the cuff thought

[Andy Dodd]

It looks like (from TFA), there will be restrictions in place that only allow caching of non-copyrighted, legal content.

It goes a LONG way towards legitimizing BitTorrent in case anyone tries to sue Bram, but contains no real-world benefits.

If ISPs want to reduce bandwidth overuse by seeders... Just IMPLEMENT MULTICAST ALREADY!

Yes, I realize multicast has historically presented major problems in scalability at the backbone router level, but with modern processing power and memory economics, it shouldn't be that difficult to implement now, and in the end presents far more benefits (massive reduction in bandwidth usage) than its disadvantages (backbone routers need some pretty hefty amounts of memory to track all of the multicast groups.)

Even "limited" multicast solutions like xcast (explicit multicast - basically instead of sending to a "multicast group" an IP datagram is given multiple destinations) would result in MASSIVE reductions in bandwidth usage by P2P applications like BitTorrent.

Due to the nature of BitTorrent and how it is used in general, caching is just an extremely hackish and limited way of implementing a shitty form of multicast... If the backbone supported multicast, there wouldn't be any need for caching of torrents.

Re:Off the cuff thought

[Sark666]

When bittorrent 4.2 was released, there was already mention of this, and I thought ya right the isps will help with torrents, but supposedly isp caching (even copyright material) is allowed under the dmca.

http://www.slyck.com/news.php?story=1231

http://www4.law.cornell.edu/uscode/html/uscode17/u sc_sec_17_00000512----000-.html

" If a file shows up on the network frequently, the cache stores that file so that its seeded in the network rather than by peers. ISPs appreciate this because their access networks are terribly congested with P2P traffic. Caches are legal and covered explicitly in the DMCA"

Re:Off the cuff thought

[mzs]

And who doles-out the multicast group addresses? I think the problem is harder than you think at first glance.

Re:Off the cuff thought

[Spezzer]

Some people in networking research believe that the problem with Multicast (and even QoS) has nothing to do with scalability, but more with economics. Although in this case, ISPs would reduce traffic going through their network by enabling multicast, there is no popular method of accounting for internal traffic when multicast is enabled on all routers. For most ISPs this is unacceptable, since large customers are billed based on the amount of traffic sent. Since there's no economic model developed for multicast-traffic, ISPs would rather throttle back BitTorrent than enable multicast. Someone please correct me if I'm mistaken on any of these points.

Most networking researchers seem to believe multicast is technologically feasible and helpful, which is why a lot of Internet architecture research seems to provide methods for multicast, even though hardly anybody uses it today.

Possible legal problems

[woodhouse]

Given that a lot of torrents are copyrighted content, are ISPs really going to want to do this? The moment they start caching these files on their servers, they become a huge target for lawsuits.

Re:Possible legal problems

[Bogtha]

Given that a lot of torrents are copyrighted content, are ISPs really going to want to do this? The moment they start caching these files on their servers, they become a huge target for lawsuits.

They already do it with HTTP proxies and Usenet servers without getting sued. So long as they are simply complying with a content-neutral communications protocol - which is basically the whole point of an ISP, I don't see how they could be held accountable. Their business is to transport bits in a particular fashion. It's not up to them to decide which bits are "good" bits and which bits are "naughty" bits.

Pipes?

[norminator]

Currently, Bittorrent traffic is suffering from bandwidth throttling ISP's that claim that Bittorrent traffic is cluttering their pipes.

You mean tubes.

No, ISP's won't get in trouble.

[saleenS281]

It's no different than them hosting usenet servers. When contacted by copyright holders they are required to remove the infringing material(s). As long as they aren't actively monitoring what they're caching, they aren't required by law to do anything about it. +1 for legal precedence before lobbyists took over our government (at least the telecom portion).

Why don't they use multicasting?

[mi]

The sender can multicast the file in a loop. The recipients will get the pieces starting from whenever they started "listening" on the ongoing multicast, and then get the earlier parts, when the sender finishes and starts over again.

This is far more efficient, than for the sender to push the same data to each client in parallel.