Slashdot Mirror

← Back to Stories (view on slashdot.org)

Bittorrent Implements Cache Discovery Protocol

Posted by ryuzaki0 on from the middlemen-i-wouldn't-want-to-be dept.

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

170 comments

  1. i wanna go fast by MrSquirrel · · Score: 5, Funny

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

    --
    A computer once beat me at chess, but it was no match for me at kick boxing.
    1. Re:i wanna go fast by ronanbear · · Score: 1

      It's about time something like this was done. Caching is complicated but is in theory so much faster. The older system of local mirrors for downloading software faster is something that could really benefit from being used in conjunction with bittorrent.

      --
      the more they over-think the plumbing the easier it is to stop up the pipe
    2. Re:i wanna go fast by timeOday · · Score: 3, Insightful

      Wouldn't this technology make your ISP a seeder? Now that would be fast.

    3. Re:i wanna go fast by arivanov · · Score: 4, Interesting

      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.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    4. Re:i wanna go fast by IAmTheDave · · Score: 1

      Whatever, I don't care how it works. Are the WWDC installs of Leopard on Pirate Bay yet?

      --
      Excuse my speling.
      Making The Bar Project
    5. Re:i wanna go fast by Qzukk · · Score: 1

      The only people who will actually suffer from the reintroduction of bandwidth and differentiated charging

      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!

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    6. Re:i wanna go fast by imboboage0 · · Score: 1

      Awesome! Now I can kill the gaming industry faster!

      --
      Honesty may be the best policy, but by process of elimination, dishonesty is the second best policy.
    7. Re:i wanna go fast by Anonymous Coward · · Score: 0

      You really need to go read RFC 2001.

    8. Re:i wanna go fast by Qzukk · · Score: 1

      You really need to go read RFC 2001.

      Why? Because if I want to move a 2MB file from here to there, sending it slowly is going to keep the ISP from dropping every other packet? Fast or slow, the ISP gets to charge me for the 2MB file plus 2MB of retransmitting retransmitted retransmits. The internet can fix a lot of things, route around damage and whatnot, but it can't fix malicious behavior at the first or last hop.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
  2. Off the cuff thought by Arimus · · Score: 5, Interesting

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

    --
    --- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
    1. Re:Off the cuff thought by zhouray · · Score: 5, Informative

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

    2. Re:Off the cuff thought by eipgam · · Score: 1

      I'm surprised nothing like this has come up already with ISPs using (transparent) caching HTTP proxies.

    3. Re:Off the cuff thought by Anonymous Coward · · Score: 1, Informative
      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.
    4. Re:Off the cuff thought by saleenS281 · · Score: 1

      no different than news servers. They don't monitor what goes on it, they only respond when contacted by the copyright holder. No harm no foul.

    5. Re:Off the cuff thought by muftak · · Score: 5, Insightful

      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.

    6. Re:Off the cuff thought by Andy+Dodd · · Score: 5, Interesting

      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.

      --
      retrorocket.o not found, launch anyway?
    7. Re:Off the cuff thought by Sark666 · · Score: 5, Interesting

      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"

    8. Re:Off the cuff thought by mzs · · Score: 5, Insightful

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

    9. Re:Off the cuff thought by jandrese · · Score: 1

      ICANN?

      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-starter. Multicast is just difficult to get right.

      --

      I read the internet for the articles.
    10. Re:Off the cuff thought by Anonymous Coward · · Score: 0
      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..

      If you really had read the article, you would have seen that only commercially licensed content is going to be cached. It's the last sentence in the "however" paragraph. (That's the paragraph where every sentence begins with "However".)
    11. Re:Off the cuff thought by Belial6 · · Score: 1

      The should be under the same risk as they would be using a web proxy. Web proxies can distribute illegal content just as easily as bittorrent.

    12. Re:Off the cuff thought by Andy+Dodd · · Score: 1

      As I mentioned in my post, even a limited form of multicast such as explicit multicast (Google for xcast) solves both the issue of limited multicast groups and of massive routing tables. It isn't as formalized a standard as traditional IP Multicast, but that doesn't really matter since IP Multicast is basically not implemented by anyone except in very limited scopes. Yes, xcast has its own limitations (limit on number of destinations from the maximum size of an IP datagram, and the potential for "spam" style abuse), but even if xcast (or a similar approach) were limited to a maximum of x (say, 8 for example) recipients per datagram by routers, it would present a MASSIVE advantage for P2P.

      --
      retrorocket.o not found, launch anyway?
    13. Re:Off the cuff thought by xenocide2 · · Score: 2, Informative

      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.

      --
      I Browse at +4 Flamebait

      Open Source Sysadmin

    14. Re:Off the cuff thought by Psykosys · · Score: 1
      The short and long of it is that if you're gonna cache bittorrent, you might as well just use something like newsgroups instead.
      Sshhh! Keep it on the d/l!
    15. Re:Off the cuff thought by John+Hasler · · Score: 1

      > It looks like (from TFA), there will be restrictions in place that only allow caching
      > 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.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    16. Re:Off the cuff thought by Pxtl · · Score: 2, Interesting

      I think you've hit the nail on the head with "ya right".

      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 problem there are two solutions, the right solution and the easy solution - and an ISP will always choose the easy solution unless it offends 99% of their customers.

      3) The only people who want this feature are the kind of users the ISP would rather be rid of. You know, the users that actually use their service instead of just checking email once in a while.

      3)

    17. Re:Off the cuff thought by Spezzer · · Score: 4, Insightful

      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.

    18. Re:Off the cuff thought by xdotx · · Score: 1

      I assume this type of action would be of the same legality as Google's caching. Which has to my knowledge gone unquestioned for years.

      --
      Our wealth breeds emptiness
    19. Re:Off the cuff thought by silas_moeckel · · Score: 3, Informative

      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)

      --
      No sir I dont like it.
    20. Re:Off the cuff thought by AnyoneEB · · Score: 1

      But it could save bandwidth for the ISP. Any transfers they can keep within their own network are transfers they do not have to pay someone else for. As to whether that outweighs the reasons you give against implementing caching remains to be seen.

      --
      Centralization breaks the internet.
    21. Re:Off the cuff thought by TCM · · Score: 1
      If ISPs want to reduce bandwidth overuse by seeders... Just IMPLEMENT MULTICAST ALREADY!
      Isn't Multicast a real-time protocol, i.e. everyone would have to download a torrent at the same time to benefit from it? Multicast seems to be more suited for TV-like applications, not random access bulk data. Or am I missing something?
      --
      Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
    22. Re:Off the cuff thought by nuintari · · Score: 2, Informative

      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.

      --

      --Nuintari

      slashdot : where an opinion can be wrong.

    23. Re:Off the cuff thought by loraksus · · Score: 1

      Bandwidth only costs money when the consumer is being billed for it.

      --
      1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcfv gbhnjmk,l.;/
    24. Re:Off the cuff thought by aprilsound · · Score: 3, Interesting
      You choose one at random. The chance of a collision is low, and if it is detected, you randomly choose again. Not a big deal.

      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 and essentially piggybacks off BGP's unicast routes.

    25. Re:Off the cuff thought by StikyPad · · Score: 1

      Oh, right. We'll just set the licensed-for-unlimited-distribution-flag in the torrents. Why didn't somebody think of that sooner?

      --
      https://www.eff.org/https-everywhere
    26. Re:Off the cuff thought by Anonymous Coward · · Score: 0

      Ya, but what ya gonna do, ya?

      Ya.

    27. Re:Off the cuff thought by matts-reign · · Score: 3, Informative

      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.

      --
      Waffles rock.
    28. Re:Off the cuff thought by AnyoneEB · · Score: 1

      I think you are misunderstanding me. The ISP is certainly paying someone for their bandwidth. I'm sure they would like any way to cut costs. For most ISPs that seems to be capping heavy p2p users so they do not use as much bandwidth.

      --
      Centralization breaks the internet.
    29. Re:Off the cuff thought by HiThere · · Score: 1

      In that case, let's go the protocol encryption route. Most things I would want to download won't be paying any license fees to become "commercially licensed". (When did you last download a "commercially licensed" distro?)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    30. Re:Off the cuff thought by porttikivi · · Score: 1

      FRM seems like an interesting research topic, but while addressing the limitations of now fashionable Single Source Multicast (SSM), it is an overkill for P2P. P2P could do fine with very simple SSM.

      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 bandwith requirement (everybody has to recieve at the same bandwith), inflexibility of UDP traffic (does not adapt to network congestion like TCP, which is scaring the ISPs) and above all, the need to have unbroken chain of supporting routers in order to work at all.

      P2P already is application level multicast. It can work without support from the routers, with flexible ISP friendly TCP, and with no synchronized bandwith or time synchronization of clients. Besides, application level allows all kinds of innovative optimizations like compression, caching, security, anonymity, billing or whatever. And multicast for video streaming really might require different approach than multicast for file delivery, it is not a good idea to force them to use the same low level mechanism.

      Besides, market fragmentation of P2P protocols is not such a bad thing, because f.ex. all my stuff is there in my iTunes or video directories, and I share it on all my active P2P networks anyway.

      --
      Anssi Porttikivi / app@iki.fi
    31. Re:Off the cuff thought by theonetruekeebler · · Score: 1
      the intention of the law for caching is for otherwise legal copies

      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. 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 something like, "This isn't a cache, it's a piece of software," and hope the judge and jury think a cache is like a galvanized lunch pail or something. Or they'll try to spin the "Everybody knows file sharing is illegal, so they're doing something illegal" approach, A.K.A. the Chewbacca Defense.

      I'd like to take a look the protocol: If it's set up to identify blocks by their signature alone, then the ISP really is turning a blind eye to content, as it should.

      --
      This is not my sandwich.
    32. Re:Off the cuff thought by markom · · Score: 2, Informative

      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.

    33. Re:Off the cuff thought by Ginger+Unicorn · · Score: 1

      no, its distributing unlicensed content that gets you in trouble. if you are licensed to distribute it, then you are fine.

      --
      (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
    34. Re:Off the cuff thought by Anonymous Coward · · Score: 0

      With Source Specific Multicast, that is no longer a problem. SSM is also simpler to implement for an ISP.

    35. Re:Off the cuff thought by CTachyon · · Score: 1

      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, nobody's going to bother.

      --
      Range Voting: preference intensity matters
    36. Re:Off the cuff thought by Crayon+Kid · · Score: 1

      I suppose it would be too much to expect to be able to use both caching and encryption. :) First because you can't cache what you can't identify, second because the ISP would most definitely be caching "gray" content. Still, it would be pretty sweet to have the ISP's help distribute BT content without knowing what's in it. They'd still get their bandwidth saving, wouldn't they? :)

      --
      i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
    37. Re:Off the cuff thought by markom · · Score: 1

      You are completely missing the point.

      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 be back to a bunch of unicast streams.

      That in particular is the reason why you don't see a lot of Internet-wide multicast.

    38. Re:Off the cuff thought by Chandon+Seldon · · Score: 1
      If even two peers manage to get a chunk off the same transmission you save bandwidth. Especially with the current asynchronous connection fad it would increase bittorrent download speeds considerably while reducing total bandwidth used.

      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 implementation would create a shitload of multicast groups, perhaps something like (n!) of them per torrent - therefore the multicast implementation would have to store recipient lists in packets rather than having centrally specified multicast groups.

      --
      -- The act of censorship is always worse than whatever is being censored. Always.
    39. Re:Off the cuff thought by Akatosh · · Score: 1

      Hi, as an ISP I'm sure you know that you are protected by the Online Copyright Infringement Liability Limitation Act section 512(a). It protects an ISP from all liability concerning transit traffic. Any smart ISP noc follows strict DMCA takedown procedures if the content is stored on their systems (such as a website), and drops all transit takedown requests not in the form of a court order on the floor to avoid opening them self up to civil liability.

    40. Re:Off the cuff thought by nuintari · · Score: 1

      I believe I just said that, "Doesn't mean it happens, any smart ISP noc shuts anything down as soon as they get a complaint." Albeit, with a great deal less detail. That's my less fancy way of saying, "Just do what the law tells you to do, and you will have no problems."

      Basically, you are liable if you don't do anything, or don't do it fast enough, or it happens a lot .Which is why I wish somedays, it was my decision to send some customer's right into the complaintant's waiting hands, but I am not the POC for DMCA and Copyright violations, someone else here recieves them directly, and usually, they are forwarded to me for immediate action. But I have no say in the decision of whether or not a customer should have their address sent to the authority making the complaint.... but some days, I really wish I could.

      We have never had to hand anyone over, we have always shut stuff down promptly. But we do have repeat offenders, and I have one in mind that I simply _loathe_. But I guess letting your personal opinions into your work is a bad way to run a business, so I simply complain about this person all the bloody time.

      --

      --Nuintari

      slashdot : where an opinion can be wrong.

    41. Re:Off the cuff thought by Akatosh · · Score: 1

      You obviously did not read the link. An ISP is _not liable_ for transit traffic. Ever. Even if you write the complainant back and say "LOL YA RIGHT" or flat out ignore them. Even if the notice is sent certified mail, says 'DMCA NOTICE' in the subject line, follows your takedown proceedures to the letter and threatens (e)legal action. DMCA takedown procedures (or even court subpoenas for that matter) do not apply to transit!

    42. Re:Off the cuff thought by biz0r · · Score: 1

      I also have worked for several ISPs (as CTO, network admin, software engineer, and a bunch of other hats) that sell a myriad of services including DSL,T1s,T3s,Dialup,ISDN, etc...and the parent poster is 100% correct. I'd mod the parent up if I had any mod points. So someone else do that please, it is deserved.

      --
      /* sig */
  3. Possible legal problems by woodhouse · · Score: 4, Insightful

    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.

    1. Re:Possible legal problems by Bryansix · · Score: 1

      Dang I was just going to say that! Well here is to hoping that the MPAA and RIAA sue every ISP in the nation. When all the evildoers are busy fighting with each other they are bound to leave us consumers alone. (Maybe wishful thinking)

    2. Re:Possible legal problems by MrZaius · · Score: 2, Interesting

      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.

      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 employer's just ~300-400 customers strong, but I don't see how this could be useful to any ISP, given that the largest would probably only benefit if the caches were replicated and stored close to the users.

    3. Re:Possible legal problems by cmeans · · Score: 2, Informative
      From the article:

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

      --
      Give a hand, not a hand-out.
    4. Re:Possible legal problems by Bogtha · · Score: 4, Informative

      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.

      --
      Bogtha Bogtha Bogtha
    5. Re:Possible legal problems by ajs · · Score: 3, Interesting

      First off, many torrents are copyrighted, but many more are not, and they're both a problem for ISPs, so yes they'll WANT to. The question is CAN they? I thik they can, but have to look over the details more.

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

    6. Re:Possible legal problems by tacarat · · Score: 1

      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 employer's just ~300-400 customers strong, but I don't see how this could be useful to any ISP, given that the largest would probably only benefit if the caches were replicated and stored close to the users.

      For larger ISPs (the type that sell off bandwidth to smaller ISPs, especially), this could be very useful for reducing bottleneck issues. The efforts to "legitimize" Bit Torrent could go hand and hand with the caching. Improve usage by removing legal threats and reducing ISP degredation. I'd like to see the WoW updater (broken piece of crap) get in on that. Movie trailers and (in my dreams) linux distros could be sped up as well as well (what about a BT based update system for linux? Interesting). Improving the efficiency of BT on all levels would help spur companies to use the technology more and help chip away at technophobic and ignorant policies and ideas.

      Well, maybe not. People fight much more passionately for dumb things than sensible ones.

      --
      "Common sense will be the death of us all"
    7. Re:Possible legal problems by Ant+P. · · Score: 2, Insightful
      On top of that, what torrents are ever so common as to warrant the use of a cache?

      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.
    8. Re:Possible legal problems by ivan256 · · Score: 1

      Almost no data transmitted over BitTorrent is without copyright, as under the Berne Convention, works are copyrighted upon creation even when such rights are not claimed by the creator, or when the creator remains anonymous.

      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.

    9. Re:Possible legal problems by McDutchie · · Score: 1
      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.

      Google's caches are full of copyrighted content. Are they a huge target for lawsuits? If not, why not?

    10. Re:Possible legal problems by Anonymous Coward · · Score: 0

      So they'll only be caching public domain works, GPL software and Creative Commons artwork?

      Is that a bad thing?

    11. Re:Possible legal problems by Loonacy · · Score: 1

      "vast minority" ... Are you saying it's the large minority?

    12. Re:Possible legal problems by Anonymous Coward · · Score: 0
      It's not up to them to decide which bits are "good" bits and which bits are "naughty" bits.

      You're right. That's what the Evil Bit is for.

    13. Re:Possible legal problems by Jugalator · · Score: 1

      Thank god, another use for the evil bit!

      Or rather, content not having it set.

      --
      Beware: In C++, your friends can see your privates!
    14. Re:Possible legal problems by tom's+a-cold · · Score: 1
      Given that a lot of torrents are copyrighted content ...
      I think I know what you're trying to say, but free and open-source software and content that's distributed over BitTorrent is also copyrighted content. I think you're trying to say "Copyrighted content distributed without the owner's consent" or something like that.

      I don't like to see the notion reinforced that "copyright" == "RIAA/MPAA bait."

      --
      Get your teeth into a small slice: the cake of liberty
    15. Re:Possible legal problems by xenocide2 · · Score: 1

      Nevermind the occasional Linux ISO over BT. 20-30 gigabytes is chump change compared to the cost of a disk to store that data on. Instead, think Naruto. With over 2 thousand simultaneous users (and this is almost two weeks old!), it's likely a valuable net gain for them there. And if they go ahead with it, usage would spike even higher; many users find BT throttled or simply slow; if suddenly you were maxxing out that "6 mbps" line the cable company sold you for BT, I don't think you'd bother with DCC bots anymore. Scarywater used to host linux stuff on BT, but it's dwarfed by the sheer scale of their anime tracker.

      But if ISPs are going to cache files like this, it pretty much eliminates the point of bittorrent.

      --
      I Browse at +4 Flamebait

      Open Source Sysadmin

    16. Re:Possible legal problems by hedwards · · Score: 1

      _ALL_ torrents are copyright to somebody (Well, at least here in the US).
      The real issue is whether or not that somebody wants it distributed, doesn't care or is opposed to the distribution.

      I don't know what the case is in other countries, but here as soon as a creative work is created and placed in some sort of physical medium (written, recorded or possibly encoded on a disk), then it is considered to be copyrighted.

      That is not to say that all or even most of the work has been registered, that is an entirely different issue.

    17. Re:Possible legal problems by x2A · · Score: 1

      They do get targetted, off the top of my head I recall at least one porn site taking action for cached images etc, and there was the thing with them scanning books in too. Google's argument goes along the lines of checking for things like a robots.txt file, or certain META tags in documents, and excluding anything requested. This does make them more opt-out than opt-in, but I think everybody realises how useless an opt-in search engine would be in comparison to a spidering one.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    18. Re:Possible legal problems by hyynes · · Score: 1

      Two words, common carrier. When ISP's don't monitor the traffic/data they support, technically they're not breaking copyrights. As soon as they start to stop it, and it keeps happening, they're accountable.

    19. Re:Possible legal problems by Anonymous Coward · · Score: 0
      It's not up to them to decide which bits are "good" bits and which bits are "naughty" bits.


      What is there to decide? Usually the naughty bits are the good bits.
    20. Re:Possible legal problems by Anonymous Coward · · Score: 0

      Yes - most if not all internet content being cached is copyright material. If this were a problem, ISPs would not be allowed to cache anything at all.

    21. Re:Possible legal problems by ivan256 · · Score: 1

      Exactly. :)

  4. the next logical question... by zonker · · Score: 3, Insightful

    when will this be implemented in azureus and utorrent? i appreciate bram's work immensely but i'm not too keen on his app...

    --

    Large print giveth, and the small print taketh away

  5. Could an ISP would actually run this? by SkOink · · Score: 1

    IANAL, but it doesn't really seem like an ISP could run this as an open, unprotected service. The legal rammifications to them of becoming more actively involved in torrenting are monstrous.

    --
    ---- I'll take you in a Hunt deathmatch any day.
    1. Re:Could an ISP would actually run this? by CastrTroy · · Score: 1

      They've been doing it with Usenet for years. I've never heard of an ISP getting sued for content on Usenet, and there is some extremely questionable content on Usenet, beyond your usual pirated material. 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. Then again, my ISP recently got rid of Usenet, claiming that it wasn't popular enough, and they were cutting it out to bring other services. Maybe the RIAA/MPAA think people will just eventually abandon the old technologies.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    2. Re:Could an ISP would actually run this? by kv9 · · Score: 1

      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!

      --
      Stop Computers/Cars Analogies on S
    3. Re:Could an ISP would actually run this? by mshurpik · · Score: 1

      Very few people know about Usenet or, more important, *how* to use it. There's an excessive amount of rarring and parring involved, not to mention finding a decent client app. It took me 12 years to find the one I'm using now (newsbin), and the guy is still developing it.

      Then you have the fact that downloading 11 million headers for alt.binaries.dvd (yes, I just checked) would take all afternoon. And browsing it, one page at a time, would take a week.

      Bittorrent is another question. But if they manage to kill bittorrent, usenet is basically the same thing, just more work.

    4. Re:Could an ISP would actually run this? by loraksus · · Score: 1

      There are clients and srvices out there that "greatly simplify" the process and eliminate the need to download tons of headers (alt.binaries.multmedia has 2.5 gigs of headers alone on a news server that I used.)
      Needless to say, there are a lot of dismally shitty clients as well.

      --
      1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcfv gbhnjmk,l.;/
    5. Re:Could an ISP would actually run this? by Anonymous Coward · · Score: 0
      Then again, my ISP recently got rid of Usenet, claiming that it wasn't popular enough
      So did my crappy ISP.
  6. Pipes? by norminator · · Score: 4, Funny

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

    You mean tubes.

    1. Re:Pipes? by Scorchmon · · Score: 3, Funny

      Not to be confused wtih a big truck. The internet is most definitely not a big truck. You could possibly confuse the two.

    2. Re:Pipes? by Anonymous Coward · · Score: 1, Funny
      Currently, Bittorrent traffic is suffering from bandwidth throttling ISP's that claim that Bittorrent traffic is cluttering their pipes.
      You mean tubes.
      You mean straws .
    3. Re:Pipes? by MikeWasHere05 · · Score: 2, Funny

      Looks to me like some horses and poker chips could solve the ISPs problem.

    4. Re:Pipes? by MarkRose · · Score: 1
      Currently, Bittorrent traffic is suffering from bandwidth throttling ISP's that claim that Bittorrent traffic is cluttering their pipes.

      You mean tubes.

      No, I'm pretty sure he mean hoses.
      --
      Be relentless!
    5. Re:Pipes? by TheSpoom · · Score: 2, Funny

      NO! The poker chips will stack up and clog the porn! You meant lottery balls, my friend.

      --
      It's better to vote for what you want and not get it than to vote for what you don't want and get it.
      - E. Debs
    6. Re:Pipes? by x2A · · Score: 2, Funny

      Look, you can't just keep dumping your own private jokes on this slashdot, it can't support them, and results in situations where it can take me 5 days to get the joke.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
  7. Way to pick a new protocol abbreviation by Anonymous Coward · · Score: 2, Insightful

    CDP = Cisco Discovery Protocol
    http://www.javvin.com/protocolCDP.html

    1. Re:Way to pick a new protocol abbreviation by Amouth · · Score: 2, Funny

      ahh just give it spanning tree's abv.. no one cares about it anyways

      --
      '...if only "Jumping to a Conclusion" was an event in the Olympics.'
    2. Re:Way to pick a new protocol abbreviation by ToTheBone · · Score: 2, Funny

      A few alternative suggestions:
      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

  8. obligatory by cli_rules! · · Score: 3, Funny

    Isn't torrents clogging up the tubes the real problem?

    1. Re:obligatory by JabberWokky · · Score: 1
      Care to explain the joke to the people who don't follow the latest digital fads and jokes?

      --
      Evan

      --
      "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
    2. Re:obligatory by PhatMoFo · · Score: 1

      So send a lotto ball through?

    3. Re:obligatory by mspohr · · Score: 1

      Senator Ted Stevens of Alaska (previously famous for "the bridge to nowhere") is one of our leading idiots (and it really does take a lot to stand out in our current crop of Senators). He was recently featured on the Daily Show comparing the Internets to a bunch of "tubes". He was speaking as a no doubt well paid agent of the poor telecoms industry which needs to be able to extort money from Google, et al in order to pay for new tubes.

      --
      I don't read your sig. Why are you reading mine?
    4. Re:obligatory by Constantine+Evans · · Score: 1

      Wikipedia has a reasonably comprehensive article on the term and its origins here.

      Personally, I believe that a better joke at Senator Stevens' expense could be had by noting that this might significantly speed up the transmission of the internets that his staff sends him.

    5. Re:obligatory by chmod+a+x+mojo · · Score: 0, Flamebait

      well at least you said ONE of our leading idiots... THE leading idiot would get mad at you and fling poo everywhere if you mistook stevens as the leading idiot.

      ( P.S. yes, i am talking about the monkey that is the president.)

      --
      To err is human; effective mayhem requires the root password!
    6. Re:obligatory by x2A · · Score: 1

      yeah but it might still take you 5 days to get it.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
  9. Between the... by Known+Nutter · · Score: 2, Funny

    between the clogged tubes and the friggin SNAKES... on a PLANE! I'm not sure what to do...

    --
    Beware of the Leopard.
  10. No, ISP's won't get in trouble. by saleenS281 · · Score: 4, Insightful

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

  11. Technical errata by ElephanTS · · Score: 2, Funny

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

    Jeez, who writes this stuff? Must be clueless because everyone knows the internet uses tubes. Sheesh.

    --
    spoonerize "magic trackpad"
    1. Re:Technical errata by Anonymous Coward · · Score: 0

      ok this is the fourth joke in a row, wtf is up with tubes?

  12. great idea by ctime · · Score: 1

    Seems like CacheLogic will be providing hardware supporting this new CDP protocol (which, ahem, CISCO Discovery protocol also shares the same acronym). Neato. It's open source as well, so I'm sure we'll see ISP's deploying linux boxes running the CDP daemon..CacheLogic and BitTorrent didd good. One thing I noticed on the official press release was that the engine caches content, but specifically 'legitimate content'. Hmm..

  13. Wow! Cached Bittorrents!!!! by pandrijeczko · · Score: 1
    Now all the adolescents can download at twice the speed, a whole 2 KILOBYTES every decade.

    Is this a good time not to say anything about that "port 119 service" thingy that we geeks are not supposed to ever mention?

    --
    Gentoo Linux - another day, another USE flag.
    1. Re:Wow! Cached Bittorrents!!!! by Anonymous Coward · · Score: 0

      Is this a good time not to say anything about that "port 119 service" thingy that we geeks are not supposed to ever mention?

      Shhhhhh!!!! You've said too much already!

    2. Re:Wow! Cached Bittorrents!!!! by Anonymous Coward · · Score: 0

      On the Up side, "leechers" will not be as big of a issue anymore

    3. Re:Wow! Cached Bittorrents!!!! by x2A · · Score: 1

      "Is this a good time not to say anything about that"

      No it's not a good time to not say... erm... no... yes, it is a good time... damn all these negatives!

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    4. Re:Wow! Cached Bittorrents!!!! by cheezemonkhai · · Score: 1

      What you mean the binary warez transfer protocol (BWTP) :P

  14. RIGHT ON, BECAUSE NO ISP RUNS A USENET SERVER... by Anonymous Coward · · Score: 0


  15. However, however, however... by Anonymous Coward · · Score: 1, Funny

    "However, Bram Cohen, the creator of the bittorrent protocol and the developer of the mainline bittorrent client did not believe that encryption was the solution, and found (tohether with Cachelogic) a more ISP friendly alternative. However, this new and improved version is promising the opposite, downloads will be accelerated instead of throttled. However, only for commercially licensed content."

    Well, I guess that takes care of the legal liability issue.

    Also, *barf* at three sentences in a row starting with "However."

  16. Torrents are major traffic hogs by Anonymous Coward · · Score: 1, Interesting

    I think the ISP's are right and that this particular program is doing a great time helping the Net to become clogged up. Not to extreme amounts ofcourse but all little bits help in the process.

    I've used torrents for 2 periods; one time I only let it run 4 - 6 hours to grab some mediafiles and noticed how my bandwith consumption was actually threefold of what I'd normally use. To download a 60Mb (or so) I was at some point with 20Mb downloaded and approx. 60Mb uploaded. Since speed goes both ways (what goes up can't come down (at the same time anyway) and I had a maximum amount of data traffic to consider I decided to stop using the program after this session. Picture my surprise when I kept noticing 'torrent connects' on my firewall logs for the next 4 weeks! I really consider that a major overhead, especially if you consider that not every firewall blocks a port by giving out a response "sorry no access" but many, like mine, simply ignore the whole attempt alltogether. Thats bound not to work well with regards to timing.

    And now that we're on the issue of firewalls. I think that the flexibility to change the used ports is something simply needed in such software. If you can change ftp ports, why wouldn't you be able to change torrent usage ports? However, it would have been a lot nicer if you could specify what port(s) you used so that others would stick to it. I don't like opening up a zillion ports on my firewall, so when I opened up the very basic range in my second session attempt (approx. 1/2 - 1 year later) I noticed that an increase of peers wasn't using the ports I specified to be using. In fact, even though I clearly indicated that I wanted the "default" range I kept torrent hits on ports never progagated (or so I assume) by my torrent client/server.

    So my simple conclusion is that while the whole concept (spreading the load over multiple sources) is a smart one the reality shows a completely different picture where there is a massive amount of overhead being created. Either they look at the global picture (no need anymore to keep sending 60Mb (for example) from your site over and over again, that load is spread over many sites) or simply take a look at a very narrow picture (no problem if there is a server with a slow upload somewhere, there are many others being used in parallel) but it seems no one pays attention to the generated overhead.

    Yes, its nice that you can grab a 60Mb file from many sites in parallel. But is it really as fast as people claim? Using several feeds means more overhead on your box with regards to dataprocessing. Then there's the bandwith itself to keep in mind, you only have so much to spare... But when I see that a 60Mb download actually generates 180Mb worth of data then I can't agree with people saying how much better a torrent is and that the spreading of data is actually a good thing. Sure, perhaps in a global picture... But for anything else (security, bandwith, etc.) I think its a poor concept.

    1. Re:Torrents are major traffic hogs by ichigo+2.0 · · Score: 1

      I don't know what client you have been using (or how old it was) but all the clients I've tried support the changing of ports, and all of them have also used only one port for incoming traffic. Now outgoing connections are a different matter, as you'll need one port for every peer you connect to, and I don't think you can select those ports on most clients. 4 weeks of incoming connections? That sounds like a bugged or very poorly designed client, that should not happen usually.

      As for spreading of data, torrents are easily the second best way of obtaining legal material (and when a HTTP/FTP server is clogged torrents are the best way), and the best way (for us mundane non-sceners) of obtaining illegal stuff. If you download slower than you upload, then the swarm is usually too small and only has that much of capacity to give. Your client will always attempt to upload at maximum speed even if the others are incapable of giving you data at your maximum speeds, as it helps the data propagate faster and lessens the need for others to upload among themselves, enabling them to give you all of their capacity. So I'm guessing you were on a dying or unpopular torrent, that just didn't have enough bandwidth to go around.

    2. Re:Torrents are major traffic hogs by Anonymous Coward · · Score: 0

      I would make three points in reply. One is that I have seen immense speeds on torrents. Its not uncommon for me to download at over 300KB/s on a busy torrent. That beats the newsgroup connection my ISP gives me. Second is that speed isn't the only factor. The built in hash checking and general reliability of labeling propel torrents far ahead of newsgroups or ftp sites or even some p2p programs in terms of usability and reliability. Third, bit torrent as a protocol doesn't seem to have been focused on efficiency for the end user though I believe it works out well in that respect. If I recall when Bram Cohen released it he was focused more on the bandwidth savings an organization such as Redhat or Blizzard could attain. Of course I don't know the man, thats just the impression I got from interviews and news storys at the time.

    3. Re:Torrents are major traffic hogs by DestroyAllZombies · · Score: 1

      Hey, cut this out! There's a limit on the number of reasonable conversations here and you're clogging the pipes.

      --
      This login name for sale.
    4. Re:Torrents are major traffic hogs by Anonymous Coward · · Score: 0

      Clogging the [b]tubes[/b].

    5. Re:Torrents are major traffic hogs by Anonymous Coward · · Score: 0
      Using several feeds means more overhead on your box with regards to dataprocessing.

      Oh noes! The box I dedicate to pulling down files from P2P and Usenet will be using more CPU cycles than it would be were it...doing nothing!

      Then there's the bandwith itself to keep in mind, you only have so much to spare...

      Every BitTorrent client I've ever seen has this awesome feature that lets you throttle both up and download speeds to whatever you want. Now-a-days I hear the kids even have these fancy routers with QoS features set up so that BT is automatically throttled back when the router detects (for example) Quake III packets.

      But when I see that a 60Mb download actually generates 180Mb worth of data then I can't agree with people saying how much better a torrent is and that the spreading of data is actually a good thing.

      Yeah, a centralized model where only rich people can afford to distribute large files is much better.

    6. Re:Torrents are major traffic hogs by grahamsz · · Score: 1

      But when I see that a 60Mb download actually generates 180Mb worth of data then I can't agree with people saying how much better a torrent is and that the spreading of data is actually a good thing.

      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 - which is good and makes up for some of the leechers.

  17. users should be more considerate by cephyn · · Score: 1

    bittorrent causes a lot of traffic. I mean come on, the internet isn't like some sort of truck you can just dump stuff on. It's a series of tubes, man!

    --
    Moo.
  18. If you throttle my bandwidth.. by Anonymous Coward · · Score: 0

    I swear to god I'll come at you like a spider monkey!

  19. Locality awareness in the protocol is the answer by sdpinpdx · · Score: 3, Interesting

    No ISP cooperation necessary. This has been tested experimentally a couple of times.

    See http://del.icio.us/tag/p2p+locality

  20. Another Cache? by OverlordQ · · Score: 2, Interesting

    Azureus has supported JPC (http://www.joltid.com/index.php/peercache) for quite a while now.

    --
    Your hair look like poop, Bob! - Wanker.
  21. Doesn't help us in the UK by mattbee · · Score: 1

    Here in the UK, for an ISP to buy a 622Mb pipe into BT's network (our beloved monopoly telco) costs £1.5m per year. That's a wholesale price of £200 per Mb, which is over 10-20x more than the external bandwidth is going to cost. So even if your traffic is only going from your local cache direct to your customers, it still costs WAY more to send it that one last hop than it would to get the same amount of traffic from anywhere else on the internet.

    Net result, those crappy bandwidth quotas / "bad boy" pipes / (un)fair use policies are staying.

    I'm not sure how broadband economics work out in other countries, but here any high-bandwidth applications are still prohibitively expensive and it'll stay that way until Ofcom (our telecoms regulator) can finish their tortuous process of opening BT's network up to competition.

    --
    Matthew @ Bytemark Hosting
    1. Re:Doesn't help us in the UK by x2A · · Score: 1

      Or use the /other/ network, telewest/ntl blueyonder *woot* their accounts dept sucks, but other than that they're million times better than going through BT.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    2. Re:Doesn't help us in the UK by SpeckledJim · · Score: 1

      You say that like it's a choice anyone can make. The reality is most people are stuck with BT because of poor coverage by the alternative cable networks.

    3. Re:Doesn't help us in the UK by cheezemonkhai · · Score: 1

      Well yes BT are not the cheapest, however they also have to install a telephone line anywhere at all in the UK for you for a fixed relatively low price and keep it working.

      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 problems from BT and it costs a lot to keep things working.

      It's not like you can just sling an ethernet cable from one place to another. Fibers regularly get broken by rats, traffic works, trees, other telephone companies etc digging the roads up. The backhaul to the rest of the world is what the 655Mb pipe is for. The link from the Exchange to the ISP network should be paid for in the monthly charges to the customer.

    4. Re:Doesn't help us in the UK by makomk · · Score: 1

      Of course, many of the larger ISPs in the UK have taken to installing their own equipment into BT exchanges where possible (local-loop unbundling) in order to bypass BT's network and reduce their costs. (IIRC, they have to do so anyway if they want to offer fast connections...)

  22. Is it just me or ? by rmallico · · Score: 1

    Do we finally have a model where a software developer is working hand in hand with the ISP, End-Users and the Content (DRM) folks and managing to make all happy?

    I just see this guy has someone who has a freaking clue as how best to manage the many touchpoints a product like his makes when out in the wild and is using his business/technical acumen to move things forward all the while making each layer 'happy'

    Kudos to Bram and anyone contributing to the cause...

    --
    sig goes here!
  23. Re:Only for commercially licensed content by Anonymous Coward · · Score: 0
    It says "only for commercially licensed content".
    I thought the point was to help reduce the amount of bittorrent traffic. How many of the torrents in your queue are "commercially licensed content", and not illegal warez, movies, games, pron, etc? I for can't recall that I've ever even seen a "legal" torrent anywhere on the internet.
  24. Stop twatting about by Kamineko · · Score: 1

    Stop twatting about with all of this jiggery-pokery and deal with the real problem:

    Get more and faster computers, more and faster networks and tubes that don't get clogged up every time somebody sends you an internet.

    Folks are using the internet a lot, that's what they want, that's what you [ISPs] want: they pay you for that.

    Don't oversell, now!

  25. Is this really feasible? by andrewmmc · · Score: 1

    I have to confess to not really knowing about this stuff, but all the torrents I download are used by relatively few people in isp terms ... does this not mean that to have any significant benefit to end users, the storage requirements of such a cache would be vast? The ISPs may as well trawl the internet for torrents and become seeders themselves. I bet the MPAA would prefer non obfuscating clients too.

  26. Why not IP Multicast? by doshell · · Score: 2, Interesting

    Wouldn't IP Multicast 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?

    --
    Score: i, Imaginary
    1. Re:Why not IP Multicast? by Wesley+Felter · · Score: 2, Informative

      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.

    2. Re:Why not IP Multicast? by modeless · · Score: 2, Informative

      What about XCast? 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.

      --
      Firebug. It will make your jaw hit the floor.
  27. cdp eh? by sedawkgrep · · Score: 1

    Now I can do 'show cdp neighbor eth0' on my linux box and actually get something back!

    --
    Is that a salami in my pants or am I just happy to be me?
  28. Why don't they use multicasting? by mi · · Score: 4, 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.

    --
    In Soviet Washington the swamp drains you.
    1. Re:Why don't they use multicasting? by Anonymous Coward · · Score: 0

      The technology for doing this is called FLUTE, a protocol from the IETF. There's a working demonstrator available called MAD FLUTE and there are graphical tools, although it occurs to me that I don't recall whether I ever released source for mine. FLUTE will work with any multicast technology (or on an IPv4 LAN, with broadcast), but it works best with Source Specific Multicast. Last time I looked it worked on Linux, Windows, and OS X, so practically everyone could use it if their ISP supported SSM.

      Of course the sort of users who get their Torrent traffic rate limited (a) are probably with an ISP that think the I stands for Interweb not Internet, and thus isn't providing multicast, IPv6, or anything else less popular than MSN; and (b) mostly download illegal copies of other people's copyrighted works, and thus don't want anything to do with a protocol that's so centrally managed and easily traced.

      However you're right, FLUTE is ideal for sending popular files to many distant mirrors or to large numbers of simultaneous downloaders.

    2. Re:Why don't they use multicasting? by 0x537461746943 · · Score: 1

      How would this work at any acceptable speed if it had to slow down for the slowest client(dialup).

    3. Re:Why don't they use multicasting? by csnydermvpsoft · · Score: 1

      The best way I can think of would be to have multiple streams going at once, each at a fixed speed (32 kbps, for instance). Each client could decide how many streams to subscribe to at a time.

  29. Re:Only for commercially licensed content by Anonymous Coward · · Score: 1, Informative

    You've never seen a legal torrent? Seriously?

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

  30. Bram Cohen is wrong by nurb432 · · Score: 1

    Encryption should be on EVERYTHING, be it legal or not.

    --
    ---- Booth was a patriot ----
    1. Re:Bram Cohen is wrong by xenobyte · · Score: 1

      Encryption should be on EVERYTHING, be it legal or not.

      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 make my own rip.

      Anyway, the encryption is there only to make it hard for anyone going through my data to discover anything without my cooperation. And I will only cooperate if I accept the reasons for them wanting it. In other words, I want the right to exclusively decide who's to access those data and who's not. I'm not hiding something, I'm hiding everything. After all, the government sits on many exabytes of so-called secret information that really belong to all of us, and if they can decide that we the people shouldn't have access, we certainly can and should decide to deny them access to our data as well. It's simply the principle of it.

      --
      "For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
  31. 21st century newsgroups done right. by AHuxley · · Score: 1

    So you can just point and click as an end using tube consumer.
    No more up/down pipes for the customer.
    You do not host anymore.
    You accept what they put up for you to consume.

    --
    Domestic spying is now "Benign Information Gathering"
  32. Re:Only for commercially licensed content by stfvon007 · · Score: 1

    Some games distribute updates via bittorrent (such as Gunz: the duel)

    --
    All misspellings and grammatical errors in the above post are intentional and part of my artistic expression.
  33. Yeah! by SlickMcSly · · Score: 1

    Let's make the ISPs liable for everything we download!!!! Yeah, that'll stop ISPs from censoring Bittorrent. Why didn't I think of that?

  34. Sounds just like Freenet.. by Myself · · Score: 1

    ...but without the crypto.

    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.

  35. This solves the WRONG problem by David+E.+Smith · · Score: 1

    The problem, at least at the small ISP I work for, isn't with out upstream connection; we've got bandwidth to spare in the NOC. For me, the problem is actually in the last mile. This would only work if I could buy about fifty of these caches, and deploy them at or near my POPs. I'm gonna take a wild guess and say that's not cost-effective for me.

    1. Re:This solves the WRONG problem by Wesley+Felter · · Score: 1

      If a customer saturates their own last mile connection it's their own problem. If the last mile is shared (cable modems or wireless), why not just enable fair queueing and let them fight it out amongst each other?

  36. JPC by eddy · · Score: 2, Interesting

    Azureus already have LAN Peer Finder and JPC (Joltid Peer Cache). Not sure how this is different from JPC on the practical level:

    Joltid PeerCache (JPC) is a device employed by ISPs to reduce the huge external network bandwidth required to support today's P2P networks. It basically acts as a caching web proxy (like Squid), only for P2P file data.

    Looks like by going its own way, the official client will once again create segmentation, just like with DHT.

    --
    Belief is the currency of delusion.
  37. Re:Locality awareness in the protocol is the answe by Wesley+Felter · · Score: 2, Insightful

    A locality-aware swarming protocol can only discover other peers at the same ISP that are running at the same time, but a cache hosted by the ISP is always running and can serve content that was downloaded by another client earlier (sort of cooperative prefetching). Also, the bandwidth between the cache and a customer is usually going to be much higher than the bandwidth between two customers because of asymmetric connections.

  38. Re:Only for commercially licensed content by rikkards · · Score: 3, Insightful
    Most of the GNU/Linux distributions I've downloaded were via Torrents.


    It's not GNU/Linux distributions that have caused ISPs to decide to bandwidth throttle bittorrents.
  39. has to be said by Zashi · · Score: 1

    Yeah, finally, a way to keep the tubes from getting over filled.

    --
    Skiffy is Spiffy, but Ort is tort.
  40. Oh the irony by Chewbacon · · Score: 1

    I remember when bittorrent launched, the idea was to save bandwidth. Now that idea is what hurts them.

    --
    Chewbacon
    The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
  41. I run a small ISP by maxrate · · Score: 1
    I run a small ISP - bittorrent and other P2P can be a problem at times, even with our small subscriber base and our OC3 connections. It's just a reality - a real drag on the network. No doubt someone will have something 'smart' to say. We do throttle the connections down - and really, who cares? It's low priority traffic, the file(s) will come thru, you just have to be patient. There is a lot of overhead on P2P connections - if they didn't carry so much overhead, it wouldn't be much of a problem. YES - we offer our services to business only, and NO we don't charge expensive rates. We don't screw with VoIP traffic, and we actually pick up the phone when you have a support issue.


    Bittorrent as cool as it is, really puts a strain on an otherwise smoothly running network! (just a reality) - I like bittorent otherwise!

  42. my reply to this by meliux · · Score: 1

    me (the 'Dan' that replied to the article on that site) said this:

    bah... i work for a major .au ISP and i would argue that the users use their "favourite applications" for sharing ILLEGAL software - hence it probably won't catch on with any ISP, UNLESS someone creates a new 'killer service' to satisfy this great new isp-based p2p seeding capability.

    I can say right now that all that is needed for ISPs to provide GREAT service levels to customers for LEGITIMATE application use (web2.0 + video stuff, etc), is to simply throttle back the amount of illegal file trading activities - which is what we're doing!

    It seems to me that this technology is simply providing a solution to a problem that doesn't quite exist yet.

  43. ISP are only carriers by turbofisk · · Score: 1

    Okay... So you sell a Internet connection with 1Mbit with a flat price. And people actually USE it? Not any fun? Do what the ISPs do in Sweden - upgrade. 1, 2,5 and 10Gbit backbones are everywhere around here. If they were to throttle connections there would be a riot over here. Blocking / Throttling is a stupid idea. Feh.

    1. Re:ISP are only carriers by Anonymous Coward · · Score: 0

      Wish we could have 10 Gbit pipes willy nilly, but unfortunately it is far to expensive here in .au and many (maybe even most) other places.

      Stop rubbing it in our faces that people in Sweden has it so good.

  44. Keeping the tubes clear for all... by gillrock · · Score: 1

    What we need to do here to free up all these tubes is to order up a bunch of lottery balls and shoot them through the tubes at a high velocity to keep the tubes clear. Then everyone is happy.

    I'm shocked that no one has thought of this. :)

    --
    "...the shortest distance between two points may be straight line, but it is by no means the most interesting."
    1. Re:Keeping the tubes clear for all... by Random+Destruction · · Score: 1

      Yeah, too bad nobody else thought of that joke

      --
      :x
  45. Re:Only for commercially licensed content by JDevers · · Score: 1

    And World of Warcraft...

  46. the tubes by Anonymous Coward · · Score: 0

    oh no, bit torrents cloging up the tubes. why didnt we listen to ted stevens.

  47. And in other news by bjoeg · · Score: 1

    Cisco today made patent on CDP (Cisco Discovery Protocol)

    1. Re:And in other news by Anonymous Coward · · Score: 0

      and since cache discovery protocol is not cisco discovery protocol then a patent is irrevelant to bit torrent

      but a trademark on CDP... i dunno, i'm no lawyer

  48. Hurry up with it! by version2 · · Score: 1

    I am trying to download Harry Potter, dammit!

  49. Don't say Telco. by Anonymous Coward · · Score: 0

    Don't say Telco. You blame the Telco for the throttling... when the problem is the ISP. The Telco would LOVE to sell more bandwidth. The ISP does not want to buy more bandwidth. If your ISP is also the Telco, well than that's your fault for being stupid.

    In the next few years, you'll see ATM-based DSL move over and it'll be replaced by ethernet over copper, or Ethernet-First-Mile. Even before that happens, you will hear about more ATM-to-Vlan based services in the Telcos as they prepare for the change. VLAN-based edge technologies are going to allow for newer QoS and accounting processes. But, no one wants to go to the satellite method of charging for bandwidth used. They'd just as soon shoot themselves in the foot.

    And no ISP wants to buy an armload of servers and park them at every POP. It'd be like Usenet News all over again. And who wants the ISP to keep a record of what is stored, who grabbed it, etc? And what happens when the ISP filters Torrents, and has a $hitty retention policy? Torrent will mutate into something else, and the entire investment will do down the tubes except for a few ISPs that implement it.

    Keep the ISP out of the business. They should provide as little "service" as possible... basically offering access to the internet and the basic services. Usenet, Mail, Webhosting.

  50. stealth bittorrent proxies by Danathar · · Score: 1

    If I were an ISP and had a bittorrent problem (and it's obviously an issue with pirated content on bittorent), I'd be interested in having the proxy up if it really helped defer my bandwidth costs.

    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.

  51. Re:Locality awareness in the protocol is the answe by Chandon+Seldon · · Score: 1

    Any time the ISP gets owned on bandwidth (or in any other way) because they handed out crappy asymmetric connections is a good time.

    --
    -- The act of censorship is always worse than whatever is being censored. Always.
  52. The Internet Is Not A Truck by Guysmiley777 · · Score: 1

    It's a series of tubes. (cue techno music)

    --
    Coding with assembly is like playing with Legos. Coding an application in assembly is like building a car with Legos.
  53. jesus christ by Magius_AR · · Score: 1
    Some ten to fifteen posts on here are nothing more than assinine "make fun of the internet tube statement" posts.

    Will you people get off the man's back?

    Would you be as unforgiving had he said "pipes"?
    I hear "pipes" used interchangably with "bandwidth" all the time.

    Dictionary.com defines "tube" as: A hollow cylinder, especially one that conveys a fluid or functions as a passage.
    Dictionary.com defines "pipe" as: A hollow cylinder or tube used to conduct a liquid, gas, or finely divided solid.

    They're freakin synonyms! How is this deserving of endless mockery? The analogy made sense.

  54. Re:Locality awareness in the protocol is the answe by gritzko · · Score: 1

    Ideally, locality-aware algorihtms could give wonderful results, such as orders of magnitude lower P2P load on backbones. Caches may give same results. See How hard will P2P hit backbones? For inherited asymmetric-last-mile networks caches are obviously better. If a network is built with P2P in mind, it might need no caches.