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."

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

[Anonymous Coward]

It says "only for commercially licensed content".

It's distributing commercially licensed content that people get in trouble for. They're not likely to be sued for uploading firefox or other non-commercial content now are they? It's ripping commercial CDs and DVDs that gets people in trouble.

Re:Possible legal problems

[cmeans]

From the article:

...downloads will be accelerated instead of throttled. However, only for commercially licensed content.

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.

Re:Off the cuff thought

[xenocide2]

The thing is, the intention of the law for caching is for otherwise legal copies. As in, graphic images for popular websites like slashdot are allowed to be cached, so long as you obey industry standard refresh requirements. And section E of the conditions pretty much makes it clear that observing copyright is more important than saving bandwidth.

Which is to say, because the internet is incredibly efficient at duplicating binary information, rather than mere transferral, machines involved in improving this process aren't held as infringing on copyright by virtue of simply doing their job storing packets after they've reached their destination. This is similar in intent to the laws that say you're not infringing for having a copy of a program on disk and in memory, or in residual backing store.

Moreover, the cache requires that both of you request a specific material from an identical person. It remains to be seen if a chunk, the small parts of a file that you distribute among peers, qualifies as a material. And even if it did, there's the problem that you likely haven't requested the chunk from the same person. The law simply wasn't written with bittorrent / swarming style p2p in mind, and a literal interpretation would likely fall flat in court.

At any rate, if an ISP choose to seed, say a movie, that would likely cause a ruckus with the owner. I'm no lawyer but it seems plausible that such an action would violate 512 (b) 1 A, which requires someone besides the ISP to offer the data. In otherwords, the ISP can't be the source of copyright violation and get away with it. Not to mention consumer ISPs would rather sell you the movie with their media partners rather than sell you bandwidth and piss those partners off. The short and long of it is that if you're gonna cache bittorrent, you might as well just use something like newsgroups instead.

Re:Only for commercially licensed content

[Anonymous Coward]

You've never seen a legal torrent? Seriously?

Most of the GNU/Linux distributions I've downloaded were via Torrents.

Re:Why not IP Multicast?

[Wesley Felter]

IP multicast creates a routing table entry for each group in every router that the group's packets flow through. If Internet users were allowed to create multicast groups, routers everywhere would run out of memory immediately.

Also, ISPs claim that they don't know how to bill for multicast.

Re:Off the cuff thought

[silas_moeckel]

They are allready allocated. Modern multicast uses a source IP / port, multicast destination address /port tuple(sp?) so realy you can pick any of the piles of multicast addresses to use traffic is split up based upon the tuple that you joined. Lower end gear hasent been as specific as higher end gear in splitting up traffic leasing the OS to remove anything unwanted but modern switches listen in on multicast setup to be more specific but those times are going away as the old gear gets aged out (managed 100bt gear is about the newest stuff that would do this)

Re:Off the cuff thought

[nuintari]

I work for an ISP, and no, you are incorrect. ISP's are not Telco's and are therefore, not covered by common carrier status. You share illegal files, your ISP is just as liable as you are. If the copyright holder files a complaint with the ISP, and the ISP doesn't deal with the issue to the holder's satisfaction, the ISP can be sued as if they were directly responsable.

Doesn't mean it happens, any smart ISP noc shuts anything down as soon as they get a complaint. Frequent offenders might just find themselves being contacted by the copyright holder directly.

As for server's at my core network caching bit torrent, and sending it out all over the place, no thank you. Bandwidth costs money people. I'd rather the customer saturate the hell out of his own connection, encourage to throttle it back a little, than have 10 mbit of zero revenue generating bandwidth flying out over my upstreams.

Oh, and that's CISCO Discovery Protocol, get your own acronym.

Re:Off the cuff thought

[matts-reign]

I'll give you an example how it would be used in a bittorrent style network application:

I am peer 1. I have section 4 of "the file". In current bittorrent, I upload this file to peer 2. However, peers 3, 7, 24, 23, and 15 need that chunk too. With multicast, I can send the file to all of them at once.

Sure, it has to be at the same time. There may be times when a portion of a file is sent to only 1 user. But with significantly large peer swarms, it is useful.

Re:Why not IP Multicast?

[modeless]

What about XCast [irisa.fr]? Seems perfect for groups around the size of a typical torrent, and if the torrent gets too large you can just use multiple XCast groups because the number of groups is unrestricted. Even if you need many groups you'll still save a ton of bandwidth compared to unicast.

Seems to me like the multicast people have been going about it the wrong way all these years, with tons of state inside the network. What happened to the dumb network philosophy? A stateless protocol like XCast is what is needed. I don't know if it can help with the billing problem, but surely the fact that each packet lists all of its destinations can't hurt.

Re:Off the cuff thought

[markom]

Well, there is only one problem with this. Multicast in itself is connectionless and doesn't work with TCP. If I'm not much mistaken, bittorrent is TCP. To make it work with UDP, the whole new mechanism would have to be developed for it to be reliable. There are solutions like "reliable multicast" that has fallback to unicast, but on a large scale, this won't work. Benefits of multicast would be absolutely minimal.