BitTorrent Developers Introduce Comcast Busting Encryption
Written by Ernesto on February 15, 2008Several BitTorrent developers have joined forces to propose a new protocol extension with the ability to bypass the BitTorrent interfering techniques used by Comcast and other ISPs. This new form of encryption will be implemented in BitTorrent clients including uTorrent, so Comcast subscribers are free to share again.
BitTorrent throttling is not a new phenomenon, ISPs have been doing it for years. When the first ISPs started to throttle BitTorrent traffic most BitTorrent clients introduced a countermeasure, namely, protocol header encryption. This was the beginning of an ongoing cat and mouse game between ISPs and BitTorrent client developers, which is about to enter new level.
Unfortunately, protocol header encryption doesn’t help against more aggressive forms of BitTorrent interference, like the Sandvine application used by Comcast. A new extension to the BitTorrent protocol is needed to stay ahead of the ISPs, and that is exactly what is happening right now.
Back in August we were the first to report that Comcast was actively disconnecting BitTorrent seeds. Comcast of course denied our allegations, and ever since there has been a lot of debate about the rights and wrongs of Comcast’s actions. On Wednesday, Comcast explained their BitTorrent interference to the FCC in a 57-page filing. Unfortunately they haven’t stopped lying yet, since they now argue that they only delay BitTorrent traffic, while in fact they disconnect people, making it impossible for them to share files with non-Comcast users.
In short, the Comcast interference works like this: A few seconds after you connect to someone in a BitTorrent swarm, a peer reset message (RST flag) is sent by Comcast and the upload immediately stops. Most vulnerable are users in a relatively small swarm where you only have a couple of peers you can upload the file to.
For the networking savvy people among us, here’s an example of real RST interference (video) on a regular BitTorrent connection. In this case, the reset happens immediately after the bitfields are exchanged. Evil? Yes – but there is hope.
The goal of this new type of encryption (or obfuscation) is to prevent ISPs from blocking or disrupting BitTorrent traffic connections that span between the receiver of a tracker response and any peer IP-port appearing in that tracker response, according to the proposal.
“This extension directly addresses a known attack on the BitTorrent protocol performed by some deployed network hardware. By obscuring the ip-port pairs network hardware can no longer easily identify ip-port pairs that are running BitTorrent by observing peer-to-tracker communications. This deployed hardware under some conditions disrupts BitTorrent connections by injecting forged TCP reset packets. Once a BitTorrent connection has been identified, other attacks could be performed such as severely rate limiting or blocking these connections.”
So, the new tracker peer obfuscation technique is especially designed to be a workaround for throttling devices, such as the Sandvine application that Comcast uses. More details on the proposal can be found at BitTorrent.org, which aims to become a coordination platform for BitTorrent developers.
TorrentFreak talked to Ashwin Navin, president and co-founder of BitTorrent Inc. who has some of his employees working on the new extension. He told us: “There are some ISPs who would like people to believe that “slowing down” BitTorrent or “metering” bandwidth consumption serves the greater good. Consumers should be very weary of this claim.”
“In recent months, consumers enjoyed unprecedented participation in the political process thanks to the ability to upload opinions and feedback in the YouTube presidential debates. Musicians, filmmakers and artists are finding ways to connect with their audiences across the world thanks to MySpace and BitTorrent. Students are engaging with interactive learning tools in their schools. Which bandwidth intensive application will banned or shaped or metered next by these ISPs? The creative spirit of millions has been ignited, and our need to participate, to communicate will not be silenced.”
“The US government should encourage ISPs to innovate and invest in their networks,” Ashwin said. “Permitting them to interfere or interrupt in the communications of consumers, to protect ISP profit margins, would be a tremendous set back for our country and economy, when we are already slipping behind the first world (UK, EU, Japan, Korea, Singapore, etc) in its broadband capacity.”
We wholeheartedly agree with Ashwin on this one, as we’ve said before. The Internet is only a few years old, if the plan is to keep using it in the future, ISPs need to upgrade their networks. So, invest in more Internet gateway capacity, 10Gbps interconnect ports, and peering agreements. BitTorrent users are not the problem, they only signal that the ISPs need to upgrade their capacity, because customers will only get more demanding in the future. The Internet is not only about sending email, and browsing on text based websites anymore.
The new protocol extension is still under development, but the goal is of course, to get it out as soon as possible.
Hang on…
Previously: Village People Hire Web Sheriff for Assault on The Pirate Bay, ABBA on Standby
Next: PRQ Fire Takes Down Several Torrent Sites
102 Responses
Victory!
About time, thought it would never happen.
Damn straight. Get to it guys!
New counter-measures are always welcome :) Good work from the developers of this new technology, many people will benefit.
much respect to the dev team
note for the uninformed: this is just bouncing around ideas, nothing final, nothing even tested for effctiveness
opportunistic encryption using ipsec or l2tp .. then an ISP won’t be able to tell it apart from a vpn connection.
note that ipsec and l2tp are IP protocols, just like tcp. RST is a tcp concept, not an ip one.
Lovely…
hats off to the devs for stepping up on this one. looking forward to see this feature implemented in transmission / azureus.
Hopefully they add the encryption routine as an upgradeable module that the user will be prompted to upgrade. Afterall we all know this is nothing more than a cat and mouse game between Cisco (makers of the DPI P-Cube crap), and the people trying to bypass their throttling products (BT client developers). Cisco will always be releasing newer firmware to throttle these new encryption routines.
“weary” or “wary” of the claim?
Old Stuff I busted through Comcast with a modem fix that my daughters boyfriend done for me. Anyway Congrats!
Comcast is like a shotgun, one cock and it blows.
What hardware will this work against? Sandvine? It seems that trackerless (i.e. DHT) would have bypassed this method of packet resets, no?
FINALLY. I knew it was just a matter of time.
But now I’ll have to switch clients..
Did I read this wrong? …more reliance on trackers instead of less? …not the way I would have gone.
Why not just use public-key cryptography? Every user generates a public-private key pair, and gives the public key to any other user who asks. To encrypt, generate a random key, use that to encrypt the message, encrypt the random key using the recipient’s public key, then send the recipient the encrypted key and message. RSA and RC4 would probably work, because RSA is secure and RC4 is fast.
BitTorrent applications could make this very, very easy, and practically transparent to the end-user. They could just have a screen during the first start that says “Configuring *App* for Optimum Performance…” to generate the public-private key pair.
Does it matter that Comcast knows?
Not to sound like that *awesome* president… we don’t want the enemy to adjust.
Think about those wanting to share on priv trackers as well ;-)
Claps His Hands good job mate this is step in right direction.
@18 – From the detail on that link, apparently not, that site (and it’s goal) has obviously been in the works for sometime.
Its really fine if they rely more on trackers, the truth of the matter is that P2P will be shifting from torrents just like everything else faded into the past due to the fact its security becomes too compromised.
Oh, well. I just dropped Comcast’s service over this last month to pick up DSL. I get far better speeds overall (up AND down), and my torrents fly. Oh, plus it’s about 20$ cheaper, and I still get unlimited long distance (contrary to Comcast’s numerous commercials claiming only they provide such services).
@17 – They’re doing something simiar but using the infohash instead.
@22 – Not really. Less trackers would mean that torrents live longer (in the DDB)… for this new scheme to work, trackers will be an even more vital lynch-pin… if they go down, so does the network… unless of course, each client becomes a tracker.
[quote]before. The Internet is only a few years old[/quote]
No it’s not.
OK, so it’s an overly complex tracker extension to prevent an ISP simply reading the peer list and the info hash from your communications with the tracker.
You know what already exists and is already supported by most clients and easily implemented into trackers? SSL/https. It prevents the ISP reading anything that you send to the tracker, or the tracker sends back to you, and requires no recoding of either end to add support for the RC4 encryption. It also requires not a single change to the announce string.
As for this new extension being the saviour where comcast is concerned, I wouldn’t count on it. All it does is prevent them from reading your info_hash on announce. It doesn’t stop them reading your announced port or from dropping connections initiating transfers on that port. SSL on the other hand encrypts even the port number.
Also, tables to contain all the possible results of sha1 hashing a sha1 hash may seem infeasable now, but they will reach a point where they aren’t. Once that point comes, using the sha1 as the key seems like a really bad idea.
Even without having to wait for tables to become possible, and ISP can easily monitor your plain http traffic for downloads of torrent files. They can then grab the hash from there in the same way your client does. Given a user who downloads 20 torrent files before starting the client, it’s a massively simple operation to sha1 20 info hashes. If only 5 of those torrents contain the obfuscate-announce-list then it cuts 3/4 of the work.
But, guess what. SSL will also protect you from this form of attack as well.
The solution is already there, and it protects against a hell of a lot more than this proposal. We don’t need this half assed crap.
I’m glad that there are those who fight for their right instead of becoming apathetic thank you
@26 – think “shared secret”
Shared secret does noting over ssl. The only possible weakness is that the ISP could request the peer-list from the tracker and then use that to kill connections but thats very unlikely. Since they would need to scrape torrents and whatnot.
@28: What about shared secrets?
The info_hash is serving as a not very secret shared secret sure, but the word itself does not make this work.
The spec says that info_hash is changed to sha_ih in the announce, and that’s it.
So here’s what we have.
announce?info_hash=xxxx&port=123
becomes
announce?sha_ih=yyyy&port=123
Your ISP sees that announce with that port, they know that the port is handling bittorrent data no matter whether you encrypt your client to client messages or not.
All they have to do now is cut or limit the connections on that port.
Yes, you could rig up some proxy software or a hacked client to send a fake port number, but that would make you unconnectable. When everyone is unconnectable, bittorrent is broken.
Anyway, with SSL, your ISP will see a connection to the webserver and that’s it. Your client sends nothing until the SSL connection is set up, not even the GET request.
So the ISP sees a connection open, then nothing but gibberish. They could not tell you whether you are reading the forums or announcing 100 torrents. They cannot pull the port number from any of it, and cannot be sure that closing incoming encrypted connections on all ports will hit bittorrent only.
BTW, from the specs page:
The returned peer list is encrypted using RC4-drop768 encryption using the infohash as a shared secret
The info_hash itself is not protected in any way. Like I said, it can be gathered by simply looking at the torrent files you download.
@29 – RC4 is SSL (been there, done that, old news)… this new method is an improvement on the concept, based on a ’shared secret’.
(yea, I read the whitepaper)
I effin’ hate the fake spymac links. To those who haven’t figured it out, people are in a stupid mindless contest on spymac and they are luring you to the site with crap so they can get stupid hits and win a stupid contest. GHEY.
SSL is more than just RC4.
RC4 is only one of the supported ciphers. SSL can support others such as 3DES, AES, RC2 etc.
RC4 is also not just SSL, but is also found in WEP and others.
HTTPS also uses shared secrets to cut down on computation. The difference is that the secret is only shared by the server and one client, and it is sent encrypted using a public/private key pair making it a genuine secret.
The new extension on the other hand simply sha1 hashes a publicly known string that is possibly also known to the intruder (your ISP). Once the intruder knows your shared key, and the algorithm you are using (fixed in this extension, variable in SSL), it’s all over.
As already mentioned, SSL/HTTPS encrypts everything sent to the tracker, from query strings to cookies. It does a much better job of blocking known and future attack vectors. Maybe in future comcast will start automatically deleting accounts found on certain trackers, unlikely to happen yes, but protected against with HTTPS.
So I wouldn’t call this an improvement on SSL/HTTPS, although simply stating “use SSL” wouldn’t have gotten BT.inc another mention in the blogs.
@ #12 Pray tell….
Spymac must fucking die.
Flawless victoly !
It’s nice to see people taking action! The government and the internet providers aren’t gonna do anything, but we can!
Awesome work Comcast! Now you see how things go when you mess with things.
Its very wierd that mostly EU ISPs upgrade and improve networks and are against monitoring and interfering, while US ISPs seems to be the opposite, maybe its the US profit machine model or their just to swamped with lobbyists from the music industry? hmm its wierd anyway..
Im downloading right now on Comcast
Just give comcast the boot …tha’ll learnem
if i’m not mistaken the advantage this has over SSL is that it might actually be feasible for trackers to implement. Do you think there’s no reason SSL hasn’t been done? The reason is that most trackers are already pushed to their limits without trying to encrypt every connection. This scheme would be much much easier on the trackers.
Perhaps it will be possible for Sandvine to defeat this by caching torrent infohashes or some other method but it’s worth a shot and at the very least it should take them months to design and deploy the new software. Also keep in mind that ISPs, unlike the RIAA, don’t really care about piracy. If it becomes expensive enough for them to block p2p traffic they’ll stop trying and probably just impose monthly bandwidth caps or something.
rtfa 41.
“Even without having to wait for tables to become possible, and ISP can easily monitor your plain http traffic for downloads of torrent files. They can then grab the hash from there in the same way your client does.”
Even if you download the tiny torrent file from within the Tor network?
The only way to permanently stop this kind of crap from the ISP’s is to make the protocol cost them even more bandwidth when they try to interrupt them (for example, maybe something like resending the connection request every 500ms or so). By doing so, they will screw their own network by attempting to hinder the protocol.
I dunno what the legal implications of this would be, at least in the US, since it seems even idiots can sue and win, and they might be able to make a case that this type of protocol would be an attack on them. However, even that can be resolved by designing the protocol correctly.
Do you think there’s no reason SSL hasn’t been done?
There are a few private trackers that do indeed allow users to utilize SSL.
Are you sure the quote was:
“Consumers should be very weary of this claim.”
???
Although plausible, it’s more likely that he said:
“Consumers should be very _wary_ of this claim.”
The ambiguity of this phrase combined with the difficulty of spelling makes it useful to add an (sic) annotation when quoting it in print.
File sharing increases the load on the networks so users who share files should pay for the bandwidth they use. This is the only way ISPs can finance network capacity increase.
marijuana for life!
Yes it is. Even the very rudimentary ARPANET is not over 40 years old yet.
Excellent!
It should be noted that if you download a torrent file over an unencrypted connection, the attacker could know the shared secret of this obfuscation protocol.
Thus everyone affected by throttling should make sure to download their torrent files over HTTPS.
Websites that provide torrent files should make that option available, or even default.
46- awesome idea imo
I could kiss you.
in Argentina we have the same problems, at PRIMA S.A. (Flash Multicanal) they use netenforcer hardware and kill our connection at day time… we can download about 2.1 GB per night… KILL THEM PLEASE!
useless.
emule did such implement also but only manage to last not even a year before isp find the solution
[quote comment="291161"]File sharing increases the load on the networks so users who share files should pay for the bandwidth they use. This is the only way ISPs can finance network capacity increase.[/quote]
Hmm.. Funny European ISPs dont need to do that. Look at sweden 80% bandwith is used for filesharing the ISPs are doing great!
I think the flaw is somewhere else, not bandwith but greed and pressure..
Just part of a normal arms race, except what’ll happen at some point is that you get what you wish for and all the ISPs using this technology stop doing so (saving equipment $). Then they move to metered pricing so that they truly do not care what you use your IP connection for — and in fact want you to use more as it generates more money for them. Then a lot of people using torrents won’t want to anymore, because it’ll cost them a lot more than they’re paying. And once one ISP breaks out of flat-rate pricing, they’ll all rush to it because it’ll be more profitable.
To all Comcast Users – Change your ISP and say goodbye to Comcast! This company sucks.
Has anyone actually tried whether dropping RST packets on both sides helps? I think Sandvine sends 20x RST to both sides and drops the actual TCP packet, but TCP recovers from dropped packets, so ignoring the RST packets should work albeit there’d still be some throttling effect. While it’s not possible for application layer software to avoid that the TCP/IP stack handles the RST and resets the connection, the software can notice the RST by looking at the error code. Therefore you could simply aggressively re-establish connections which are reset. This would also have the effect which someone mentioned here. If the ISP tries to inject RSTs, they’ll just make it worse for themselves because it will result in a flood of connection attempts.
It’s kinda interesting that nobody mentions UDP as an option. You can’t really modify TCP because it’s officially standardized and the operating system handles it, leaving very little control to the applications using it – which of course is the idea and usually a good thing. However, it’s not difficult to design a TCP-like protocol over UDP, you could in fact tunnel TCP over UDP. Then all you have to do is adding a little modification that makes it impossible – or at least very difficult – that a connection can be trivially reset.
I find it really odd that neither ed2k or bittorrent support file transfers over UDP because it has several advantages especially in today’s NAT-crippled internet. There are disadvantages too but none of them are so bad, that it justifies complete ignorance of this option.
this could be awesome
Getting rid of Comcast isn’t an option for me. They are EVERYWHERE :(
Awesome!
[quote comment="291496"]To all Comcast Users – Change your ISP and say goodbye to Comcast! This company sucks.[/quote]
Your stupidity is showing.
@59 – (quoting Wikipedia)
“The UDP tracker is better optimized and puts less strain on the tracking server, however it is not supported by all BitTorrent clients. On the other hand the HTTP tracker is supported by all BitTorrent clients, is more reliable for ratio updates, but more of a strain on the server. Neither tracker has any effect on transfer speeds, except that if a user wanted to use a web browser (transfers via HTTP) then the UDP downloads would not be as affected by the increase in local traffic.”
Now you know.
i’m psyched about this. the exact same thing happens to me on my cox connection, but only when uploading, not downloading.
64, you didn’t understand a single word I wrote. I’m very well aware of DHT and UDP trackers but this absolutely nothing to do with what I wrote. I wouldn’t quote Wikipedia to save my life because it’s full of shit, misinformation and it’s getting worse with every edit.
So when are we going to get it?
Great Job To the dev team! keep it up
While Comcast wastes there profits in a traffic shaping battle. Other isps are making better faster networks useing fiber optics. They are shooting themselves in the foot
People Listen to Me I busted through Comcast with a modem fix my daughters boyfriend did for me, I seed I seedI seed I Dl and I Dl no interferance-Any TV repair shop can do it also any electronics student can too..
this is useless. its the TCP connection between the 2 peers that comcast is disrupting, not between tracker and client.
also, they are re-inventing the wheel. if you want to encrypt your announces use SSL. the developers pretty must wasted their time.
[quote comment="291866"]People Listen to Me I busted through Comcast with a modem fix my daughters boyfriend did for me, I seed I seedI seed I Dl and I Dl no interferance-Any TV repair shop can do it also any electronics student can too..[/quote]
um, can you make a complete sentence please? maybe then we will be able to do the same as you.
BTW, looks like comcast blocks torrentfreaks website. I came to read this article from my Comcast account and I get:
[10:21] ~> telnet torrentfreak.com 80
Trying 66.228.120.206…
telnet: connect to address 66.228.120.206: Connection refused
telnet: Unable to connect to remote host
But at the same second, from my SBC Yahoo DSL, I can read just fine. Somebody please confirm? I’m in Chicago area.
i heard comcast is going to move towards charging people per protocol per port.
Something needed to be done. I guess some new security measures are always welcome.
M
any people will benefit. Good work from the developers of this new technology.
____________________
Web Efforts
http://www.webefforts.co.uk
So I’m kinda new to all this, but before this all came out, I never had a problem with throttling. But I did get this notice and was wondering if this new encryption would block them from knowing what I am downloading. As you can see from the email below that I got from Comcast, they knew I was downloading. I really don’t care if it blocks them from slowing the connection, I just want to know if it makes them not able to see what i am getting. Also, is there anything better then Utorrent?
“Notice of Action under the Digital Millennium Copyright Act
Dear Comcast High-Speed Internet Subscriber:
Comcast has received a notification by a copyright owner, or its
authorized agent, reporting an alleged infringement of one or more
copyrighted works made on or over Comcast’s High-Speed Internet
service (the ‘Service’). The copyright owner has identified the
Internet Protocol (’IP’) address associated with your Service account
at the time as the source of the infringing works. The works
identified by the copyright owner in its notification are listed
below. Comcast reminds you that use of the Service (or any part of
the Service) in any manner that constitutes an infringement of any
copyrighted work is a violation of Comcast’s Acceptable Use Policy and
may result in the suspension or termination of your Service account.
If you have any questions regarding this notice, you may direct them
to Comcast in writing by sending a letter or e-mail to:
Comcast Legal Response Center
Comcast Cable Communications, LLC
650 Centerton Road
Moorestown, NJ 08057 U.S.A.
Phone: (856) 317-7272
Fax: (856) 317-7319
E-mail: dmca@comcast.net
For more information regarding Comcast’s copyright infringement
policy, procedures, and contact information, please read our
Acceptable Use Policy by clicking on the Terms of Service link at
http://www.comcast.net.
Sincerely,
Comcast Legal Response Center
Copyright work(s) identified in the notification of claimed infringement:
Title: Crysis
Infringement Source: BitTorrent
Infringement Timestamp: 23 Jan 2008 00:09:37 GMT
Infringement Last Documented: 23 Jan 2008 00:09:37 GMT
Infringer Username:
Infringing Filename: Crysis-Razor1911
Infringing Filesize: 6471561394
Infringer IP Address:
Infringer DNS Name:
Infringing URL: http://tv.tracker.thepiratebay.org:80/announce“
[quote comment="291161"]File sharing increases the load on the networks so users who share files should pay for the bandwidth they use. This is the only way ISPs can finance network capacity increase.[/quote]
that is a such a backwards way of looking at it. I already pay my ISP for a certain amount of Down/Up bandwidth. This whole fiasco shows that they have been overbooking bandwidth, probably because they assumed nobody would use what they paid for. I agree that a “scaled” pricing scheme would be one way out of this mess, but to place the blame on the consumer for actually using what they paid for is quite frankly absurd, and makes me wonder if you work for a big Telecom corporation. It is like Greyhound in the States – they’ll sell as many tickets as they possibly can, without concern for how many seats are on the bus. if the bus is overbooked – as they often are – tough shit for the consumer, first come first serve. Does that mean that people who ride the bus a lot should stop doing so? No, it means that the company needs to sell based on real and not infinite supply. If my ISP sells me a certain amount of bandwidth, they have no right to get all pissy when I actually use it. They should use some of their vast profits (not to mention public funds given to them to do just this!) and upgrade their infrastructure to handle the FACT that more and more people are actually going to use the full extent of their broadband connection nowadays.
[quote comment="291161"]File sharing increases the load on the networks so users who share files should pay for the bandwidth they use. This is the only way ISPs can finance network capacity increase.[/quote]
Boo-hoo for the ISP’s. You’re operating under a mistaken impression. Unlike many places around the globe, almost all ISP services in the US are sold to the public as unlimited service. This means that your “users who share files” ALREADY HAVE PAID for the bandwidth they use.
It is not the fault of the customer for taking them up on the unlimited bandwidth that was promised. It is solely the fault of the ISP’s for not taking into account that when they offered unlimited service that some customers would actually expect and use the unlimited bandwidth they contracted and paid for. Now that the ISP’s have been caught with their pants down because they don’t have the capacity to actually deliver the unlimited bandwidth they sold, they choose to blame their customers rather than investing in their own infrastructure to insure that they can deliver what was promised AND paid for.
So does this mean that this will block them from ISP’s knowing what you are downloading or or just from being able to throttle your downloads?
Friend of mine got a message from Comcast that told him to stop or His service will be terminated and they listed the Torrent he was downloading.
[quote comment="292462"]So does this mean that this will block them from ISP’s knowing what you are downloading or or just from being able to throttle your downloads?
Friend of mine got a message from Comcast that told him to stop or His service will be terminated and they listed the Torrent he was downloading.[/quote]
it won’t block them from knowing anything. this is dumb and the developers are wasting their time.
they are reinventing the wheel, if you want to encrypt your connection between tracker – client user HTTPS/SSL
this won’t help out comcast users at all
[quote comment="291427"]Just part of a normal arms race, except what’ll happen at some point is that you get what you wish for and all the ISPs using this technology stop doing so (saving equipment $). Then they move to metered pricing so that they truly do not care what you use your IP connection for — and in fact want you to use more as it generates more money for them. Then a lot of people using torrents won’t want to anymore, because it’ll cost them a lot more than they’re paying. And once one ISP breaks out of flat-rate pricing, they’ll all rush to it because it’ll be more profitable.[/quote]
That’s my worry
Thank you, thank you, THANK YOU! My ability to seed, and even download, has gone to complete shit on Qwest broadband. It pisses me off to no end that I pay top $ for their most powerful residential connection and they decide what I can and can’t do on my webs. My only alternative is Comcast or dialup in my area, so this update is very much appreciated.
Lots of respect to the dev team. Didn’t see this coming for some reason.
It’s incredible to see all you thieves go “hurray” about this.
I see you are happy as you expect to be able to steal even more.
Freeloaders are greedy, selfish idiots that are of no use to anyone.
Way to go team! Very respectable response.
so how would one go about using SSL for downloads and seeding?
its interesting that in the many responses so far , not one single person has bothered to talk about the torrent apps having a re-engineer to better keep the 80%+ of traffic inside the ISPs network were possible.
it seems a simple thing to add a finer grained swarm localisation that trys to keep as much torrent traffic inside the local LAN,then WAN,then ISP, then country, and so on, so keeping the ISPs happy and the users happy too as it should improve throughput.
if you then want to wrap all this inside a tunnel to clean it all up for encryption end to end you must also consider adding the Multicasting DHT extension to once again free up masses of bandwidth.
its not about fighting the ISPs, its more a case of getting more for less and a Multicasting torrent extension will benefit everyone, along side encrypted end to end tunnels.
id rather the able bodyed coder would spend time adding and extending the existing JAVA multicasting DHT abd tunnel code to make far better use of my limited upload pipe for the betterment of all torrent users ,than fight the ISP and l loose out anyway, while the payed binary usenet gets bigger and yet forgotten.
will someone please make a client add-in for AZ to use an _encrypted_ _multicast_ _tunnel_ to other clients etc and we can all be happy in a very short time.
[quote comment="291496"]To all Comcast Users – Change your ISP and say goodbye to Comcast! This company sucks.[/quote]
Exactly: instead of finding workarounds, why not vote with your pocket book? That’s likely to be more effective than identifying work arounds or contacting your legislator.
[quote comment="293650"]its interesting that in the many responses so far , not one single person has bothered to talk about the torrent apps having a re-engineer to better keep the 80%+ of traffic inside the ISPs network were possible.
it seems a simple thing to add a finer grained swarm localisation that trys to keep as much torrent traffic inside the local LAN,then WAN,then ISP, then country, and so on, so keeping the ISPs happy and the users happy too as it should improve throughput.
if you then want to wrap all this inside a tunnel to clean it all up for encryption end to end you must also consider adding the Multicasting DHT extension to once again free up masses of bandwidth.
its not about fighting the ISPs, its more a case of getting more for less and a Multicasting torrent extension will benefit everyone, along side encrypted end to end tunnels.
id rather the able bodyed coder would spend time adding and extending the existing JAVA multicasting DHT abd tunnel code to make far better use of my limited upload pipe for the betterment of all torrent users ,than fight the ISP and l loose out anyway, while the payed binary usenet gets bigger and yet forgotten.
will someone please make a client add-in for AZ to use an _encrypted_ _multicast_ _tunnel_ to other clients etc and we can all be happy in a very short time.[/quote]
It’s more than just transport between ISPs, it’s also about using up the limited upstream capacity of DOCSIS. 16-QAM is just 10 Mbps, while downstream at 256 QAM is ~38 Mbps. Of course there is usually at least 4:1 ratio of upstream ports to down ports, but it doesn’t take too many P2P clients uploading content to fill it up.
Has anyone considered that if Comcast’s current approach is kiboshed that they could go application-neutral rate limiting once a certain bandwidth cap has been exceeded? That wouldn’t be unlike higher ed, where because the Packeteers of the world can’t pump out application signatures fast enough, and where SSL prevents any identification, they’ve just implemented caps followed by rate-limiting to help manage their bandwidth costs?
MAYBE this is just buzz to get people to switch back or use utorrent, who is now in bed with the bad guys.
Google: utorrent mpaa
pip “Multicast….”
“by Anonymous:
It’s more than just transport between ISPs, it’s also about using up the limited upstream capacity of DOCSIS. 16-QAM is just 10 Mbps, while downstream at 256 QAM is ~38 Mbps.
Of course there is usually at least 4:1 ratio of upstream ports to down ports, but it doesn’t take too many P2P clients uploading content to fill it up.”
I agree, and my main point ,rather than the ease with which you might Encrypt the Tunnel, is its got to be FAR more economical to sent a single torrent/data packet _once_ to say 4 of your peers at a time with Multicasting, than send the same packet 4 seperate times to each unicast peer as now.
a very large saving in MC upload packets with even this basic 4/1 ratio compared to now with unicast.
sure it will take some thought regarding the re-transmission IF a seed didnt get that packet intact,but not that much work.
and every single packet saved is one less to send to the next Multicast peer.
its clear that even a very basic torrent Multicast peering is far better at using the very limited upstream capacity than any unicast peer if you have more than one person in a swarm.
id hope by now that multicasting has a clear advantage over uncast and we should at least consider moving to it.
at the very least, make a basic MC plug-in for AZ and try the Multicasting idea out.
bamboo DHT java code would seem to be a good starting point for any experimental Multicasting plug-in, also the java Mtunnel might get some torrent coders interest for inclusion.
@kami
you say to stop using comcast… sadly, the world is not always that simple. in some areas in the united states, comcast is a monopoly and if you want internet, you get it through comcast. or, you can get dial-up. but i and many other people would rather be beaten senseless (repeatedly) than go back to dial-up. besides, have you ever tried downloading a movie on dial-up? i have, and the beatings get my vote again.
it seems that this Peer Obfuscation subject recently got far more serious for the whole UK market place and the govt wish to legislate if the ISPs dont comply.
what will the developers do now?, stand by and wait, or place an all Peer Obfuscation in place ASAP, even to other connected peers to hide the users IP etc?.
http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/
http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/comments/
a fully Encypted Muticasting tunnel is looking like a very good thing to many (UK)P2p users right now, will you step up and make it hapen?.
[quote comment="296748"]it seems that this Peer Obfuscation subject recently got far more serious for the whole UK market place and the govt wish to legislate if the ISPs dont comply.
what will the developers do now?, stand by and wait, or place an all Peer Obfuscation in place ASAP, even to other connected peers to hide the users IP etc?.
http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/
http://www.theregister.co.uk/2008/02/22/burnham_dcms_filesharing/comments/
a fully Encypted Muticasting tunnel is looking like a very good thing to many (UK)P2p users right now, will you step up and make it hapen?.[/quote]
[quote comment="295621"]@kami
you say to stop using comcast… sadly, the world is not always that simple. in some areas in the united states, comcast is a monopoly and if you want internet, you get it through comcast. or, you can get dial-up. but i and many other people would rather be beaten senseless (repeatedly) than go back to dial-up. besides, have you ever tried downloading a movie on dial-up? i have, and the beatings get my vote again.[/quote]
about time!
bitTorrent has been behind the obfuscations/encryption game for the last five years!
[quote]“BitTorrent users are not the problem, they only signal that the ISPs need to upgrade their capacity, because customers will only get more demanding in the future.”[/quote]
Or rather, bitTorrent (level bandwidth usage) is not the problem, it is the future; and any service providers who dispute this are dinosaurs, likely to be toppled by their far-more evolved successors in the near future.
i take it with the total lack of response, the developers couldnt care less about the potential loss of the UK torrent underground or the anonanimity of non US users then?
what bit torrent client is the beast for Encryption
Encryption will only go so far. Rogers (a cable company in Canada) implemented pcube boxes to shape bittorrent traffic, and the community responded by encrypting the packets so that the pcubes could not do DPI on them. Rogers in turn responded by resorting to throttling *ALL* encrypted packets, taking SSL and IPSec VPN applications with them. Needless to say many of us here in the Great White North are eager to see the outcome of Comcast’s current bout with the FCC as an indicator of what can be done about Rogers’ practices.
Comcast is nothing but a bunch of two-bit swindlers. Instead of getting more bandwidth capacity they decided to take what seemed the cheapest route.
I strongly dislike the point of view many ISPs around the world have assumed. Too often they pretend to know better than us about our actual needs. Too willingly they give in to illegal requests of the IFPI and block sites for no reason.
Perhaps it’s time for natural selection to take its toll.
Yep I got the email from Comcast today. I’ll be dropping them as well. Gotta check into some DSL prices around here. Too bad..I’ve had them for many years now. This monitoring activity is BS. Now I feel like someone has broken into my home.
There Is Ppl Who Can Code ‘N’ Help Us…But If There Is No Seeding…This Will Not Be The Cure To The Epidemic.
Nor The ISPs Will Be The Virus…But Ourselves Who Don’t Want To Share.
Greed Is Part Of Our Human Nature…We Have To Act Against It.
Much Respect To The Dev Team.
I Take My Hat Off.
thumbs up for the guys working on the project
and d.icks up for the isps throtling bittorent trafic
however my isp doesnt do any such stupid thing cuz they dont want their heads to be blown off by me..
Hurray PTCL!!
12 references to this post
Responses are closed
All remaining responses will continue to be archived. Use the TorrentFreak forums if you want to discuss something.