Bittorrent Implements Cache Discovery Protocol 170
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."
i wanna go fast (Score:5, Funny)
Re:i wanna go fast (Score:2)
Re:i wanna go fast (Score:2)
Re:i wanna go fast (Score:4, Insightful)
Re:i wanna go fast (Score:5, Interesting)
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.
Re:i wanna go fast (Score:2)
And hey, the best part of the whole thing is that your ISP just has to drop every other TCP packet in order to charge you double! Half the work for twice the price is a great deal no matter how you slice it!
Off the cuff thought (Score:5, Interesting)
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 (Score:5, Informative)
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:2)
Re:Only for commercially licensed content (Score:2)
Re:Only for commercially licensed content (Score:2)
Re:Only for commercially licensed content (Score:4, Insightful)
It's not GNU/Linux distributions that have caused ISPs to decide to bandwidth throttle bittorrents.
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:5, Insightful)
Sounds just like Freenet.. (Score:2)
It's a shame more ISPs don't run freenet, tor, or i2p nodes. Usenet servers were a good idea, and torrent caching servers are a step in the right direction.
Re:Off the cuff thought (Score:5, Interesting)
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 (Score:5, Insightful)
Re:Off the cuff thought (Score:2)
I'd imagine that ISPs would have to buy small chunks of multicast addresses and then resell them to people. Unfortunatly that will probably kill the idea before it even gets started, since ISPs will no doubt charge and arm and a leg for a Multicast IP and Bittorrent users generally want to avoid drawing too much attention from their ISP. It might make sense if there is just a pool of multicast groups that's managed by a central server for all Bittorrent users, but even that sounds like a non-start
Re:Off the cuff thought (Score:4, Informative)
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:4, Interesting)
In response to the GP, it's not even a matter of implementing multicast. Almost all of the networking hardware out there has it in place, it's just turned off.
The reason? The original implementation is hard for ISPs to charge for. But there is hope. At SIGCOMM 2006, there was a proposal that would be more ISP friendly, with a minimal performance hit. Its called Free Riding Multicast [stanford.edu] and essentially piggybacks off BGP's unicast routes.
Re:Off the cuff thought (Score:2)
But in the end I doubt the feasibility of IP (layer 3) multicast. SSM solves the multicast routing problem, and source/group discovery and advertising can now be easily done manually, but other multicast problems remain: synchronicity (everyboday has to recieve at the same time), least common denominator bandwit
Re:Off the cuff thought (Score:2)
> of non-copyrighted, legal content.
"Non-copyrighted", eh? I suspect that isn't what you really mean. Hint: this article is copyrighted. So is yours.
Re:Off the cuff thought (Score:4, Insightful)
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.
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:3, Informative)
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:Off the cuff thought (Score:2, Informative)
Re:Off the cuff thought (Score:2)
So? While it wouldn't be exactly trivial to create a BitTorrent-like multicast protocol, it'd be fairly straightforward. Hell, if I were to code up a very rough prototype all by myself, I can't see it taking me more than three weeks, and most of that would be protocol design. Once it'd been implemented once, it'd get steamrolled into most of the BitTorrent clients out there in a matter of 3-6 months as an option, just like every other new BT feature. Of course, without a multicast-capable Internet, nobo
Re:Off the cuff thought (Score:2)
Yes, you can make it use multicast. You have any-to-any multicasting (or as it is actually called, bidirectional multicast). What happens if (when!) on of the hosts misses few packets? It needs to recollect them somehow, but... you can't retransmit, because it retransmits to the whole group? How do you solve that on a global scale? Of course, for that client, you reverse to unicast and send to him. With network of few thousand clients, in a matter of few minutes, you'll
Re:Off the cuff thought (Score:2)
It doesn't matter if a couple peers miss a transmission. You don't retransmit to that same group - you instead transmit that piece to the new group that needs it when nessisary, a new group that includes those from the old group that missed it the first time.
The simplest im
Re:Off the cuff thought (Score:5, Interesting)
http://www.slyck.com/news.php?story=1231 [slyck.com]
http://www4.law.cornell.edu/uscode/html/uscode17/
" 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 (Score:3, Informative)
Which is to say, because the internet is incredibly efficient at duplicating binary information, rather than mere transferral, machines involved in improving this
Re:Off the cuff thought (Score:2)
The "legality" of the cache's contents are irrelevant, and you really should just read the part of Section 512 the PP has so kindly linked to [cornell.edu]. You can argue intent until you're blue in the face, but all you're doing is second-guessing, because the law itself -- not its intent -- is what has force.
That said, should the MPAA/RIAA trusts decide to argue about this, their claim will probably be that this is not a cache. They'll say somethin
Re:Off the cuff thought (Score:3, Interesting)
Doesn't matter if ISP-side torrent-cacheing woudl turn every computer into a supercomputer - ISPs won't do it, for a variety of reasons:
1) Legal liability, obviously. Sure, it's probably fine, but not-caching torrents is definitely fine, which is better than probably fine. This is called the "chilling effect".
2) Easier just to not do it. The torrent-cache is one more system to maintain that they'd probably just rather do without. For any software p
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:2)
Re:Off the cuff thought (Score:3, Informative)
Doesn't mean it happens, any smart ISP noc shuts anything down as soon as they get a complaint. Frequent offenders might just find themselve
Possible legal problems (Score:5, Insightful)
Re:Possible legal problems (Score:2)
Re:Possible legal problems (Score:3, Interesting)
On top of that, what torrents are ever so common as to warrant the use of a cache? There are certainly legitimate users of bittorrent, if you can limit the cache to legitimate content. But what torrents would ever be accessed so frequently by individual users on any given network that this would make sense? My e
Re:Possible legal problems (Score:3, Insightful)
How many people download Linux ISOs using BT? If 30 people on one ISP download a new release, and it's using this, the ISP saves about 20-30GB and the users get the full 300KB/s they pay for instead of 2-3KB/s.
Re:Possible legal problems (Score:2)
Re:Possible legal problems (Score:3, Informative)
Re:Possible legal problems (Score:2)
Or rather, content not having it set.
Re:Possible legal problems (Score:5, Informative)
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:Possible legal problems (Score:4, Interesting)
If the system simply facilitiates the protocol blindly, then I don't see how they could be any more to blame for copyright violations than AOL's Web proxies. Sure, gigabytes of copyright violations move through AOL's proxies every day (and get cached to speed up downloads), but they literally don't have the processing power to try to make a distinction. Same goes for the ISPs and BitTorrent (or Gnutella, or any of the other high-bandwidth swarming download technologies).
Re:Possible legal problems (Score:2)
The only works which are not copyrighted are those in the public domain due to the expiration of their term, or those where the copyrights were explicitly waived. In other words, the vast minority of content transferred over BitTorrent.
Re:Possible legal problems (Score:2)
Re:Possible legal problems (Score:2)
Google's caches are full of copyrighted content. Are they a huge target for lawsuits? If not, why not?
Re:Possible legal problems (Score:2)
Re:Possible legal problems (Score:2)
I don't like to see the notion reinforced that "copyright" == "RIAA/MPAA bait."
the next logical question... (Score:3, Insightful)
JPC (Score:3, Interesting)
Azureus already have LAN Peer Finder and JPC (Joltid Peer Cache [azureuswiki.com]). Not sure how this is different from JPC on the practical level:
Looks like by going its own way, the official client will once again create segmentation, just like with DHT.
Pipes? (Score:5, Funny)
You mean tubes.
Re:Pipes? (Score:3, Funny)
Re:Pipes? (Score:3, Funny)
Re:Pipes? (Score:2, Funny)
Re:Pipes? (Score:3, Funny)
Re:Pipes? (Score:2)
No, I'm pretty sure he mean hoses.
Way to pick a new protocol abbreviation (Score:2, Insightful)
http://www.javvin.com/protocolCDP.html [javvin.com]
Re:Way to pick a new protocol abbreviation (Score:3, Funny)
Re:Way to pick a new protocol abbreviation (Score:2, Funny)
TCP (Torrent Cache Protocol)
SMB (Storage Method for Bittorrent)
ATM (Advanced Torrent Method)
BOOTP (Bittorrent Over Other Temporarystorage Protocol)
BGP (Bittorrent Gateway Protocol)
HTTP (Helper Torrent Transfer Protocol)
NTP (Networkfriendly Torrent Protocol)
TDMA (Torrent Data Management Advanced)
TFTP (Torrent File Transfer Protocol)
I'm sure someone will have a few even better suggestions
obligatory (Score:3, Funny)
Re:obligatory (Score:2)
--
Evan
Re:obligatory (Score:2)
Re:obligatory (Score:2)
Between the... (Score:2, Funny)
No, ISP's won't get in trouble. (Score:5, Insightful)
Technical errata (Score:3, Funny)
Jeez, who writes this stuff? Must be clueless because everyone knows the internet uses tubes. Sheesh.
great idea (Score:2)
Re: (Score:2)
Re:Wow! Cached Bittorrents!!!! (Score:2)
No it's not a good time to not say... erm... no... yes, it is a good time... damn all these negatives!
Re:Wow! Cached Bittorrents!!!! (Score:2)
users should be more considerate (Score:2)
Locality awareness in the protocol is the answer (Score:3, Interesting)
See http://del.icio.us/tag/p2p+locality [del.icio.us]
Re:Locality awareness in the protocol is the answe (Score:3, Insightful)
Another Cache? (Score:3, Interesting)
Doesn't help us in the UK (Score:2)
Net result, those crappy bandwidth quotas / "ba
Re:Doesn't help us in the UK (Score:2)
Re:Doesn't help us in the UK (Score:2)
Other providers can cherry pick only the profitable exchanges.
Additioanlly BT wholesale will sell you a pipe to your customer and that is covered by the cost of the monthly charge and a bandwidth limit. The more you pay the more bandwidth you get. Thats how things work. An ISP has a guarnateed maximum downtime and response time to any pro
Why not IP Multicast? (Score:3, Interesting)
Wouldn't IP Multicast [wikipedia.org] be a more appropriate solution to this problem (and, for that matter, also for the whole lot of streaming content that flows on the 'net nowadays)? AFAIK it has been standardised for some time now, both for IPv4 for IPv6. Why, then, is it that multicast is virtually unused outside private networks?
Re:Why not IP Multicast? (Score:3, Informative)
Also, ISPs claim that they don't know how to bill for multicast.
Re:Why not IP Multicast? (Score:2, Informative)
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
cdp eh? (Score:2)
Why don't they use multicasting? (Score:5, Insightful)
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.
Bram Cohen is wrong (Score:2)
Re:Bram Cohen is wrong (Score:2)
Exactly. I routinely encrypt my harddrives for that very reason. There's not much illegal stuff there except for the occasional temporary movie (or mp3) downloaded in order to watch it (or listen to it) while everybody's talking about it, not when it suits the companies to release it here (usually months later). If the movie or song is crap it is deleted right away. If it is good, I hang on to it until I actually can buy it. Then it is deleted and I mak
This solves the WRONG problem (Score:2)
Re:This solves the WRONG problem (Score:2)
stealth bittorrent proxies (Score:2)
BUT...I'd DEFINITELY want it to be transparent and invisible.
So basically many ISP's will want this software BAD. But they don't want anybody to KNOW they do it for fear of lawyers from the RIAA/MPAA/SPCA/ECT comming down on them like a ton of bricks.
Re:Could an ISP would actually run this? (Score:2)
Re:Could an ISP would actually run this? (Score:2)
I think it's funny how the RIAA/MPAA are focusing their attention on all the newer technologies, when it seems to me like old technologies like Usenet and IRC are where the best sources are.
*shhhhhh* what are you trying to DO man? you're gonna tip em off!
Re:Could an ISP would actually run this? (Score:2)
Needless to say, there are a lot of dismally shitty clients as well.
Re:Torrents are major traffic hogs (Score:2)
As for spreading of data, tor
Re:Torrents are major traffic hogs (Score:2)
A 60Mb download normally "generates" 120Mb of traffic, since it uses 60Mb on the webserver and 60Mb on the client.
It's to be expected that bittorrent uses a little more than that since it's inherently more complex than http, i suspect you saw the 50% increase because shared more of the file than you downloaded -