How Comcast customers can seed 100 times faster and bypass TCP resets
As many of you reading this blog probably already know, Comcast has been disconnecting a certain percentage of TCP streams emanating from BitTorrent and other P2P (peer-to-peer) seeders. This effectively delays and degrades the ability of Comcast customers to seed files using P2P applications. For normal healthy Torrents that are distributed across multiple users and multiple ISPs, losing a few seeders intermittently isn’t too noticeable. But for rare Torrents or Torrents that have to originate from a Comcast broadband customer, this can pose some challenges. The rare Torrent becomes even less reliable than they already are while popular Torrents originating from Comcast’s broadband network take much longer to become healthy.
While Comcast has stated they will try to move off of their Sandvine system that uses TCP resets by the end of this year, there’s no guarantee that they will complete on schedule and there’s no relief in the mean time for customers who are having a tough time seeding their files for distribution. Even without the challenges posed by TCP resets, seeding a torrent file is still problematic and burdensome. Not only does the seeder have to turn his/her computer in to a server, they must also allocate significant portions of their upstream bandwidth – as well as their neighbor’s bandwidth which they share – to seeding while providing relatively minimal capacity to the Torrent.
The opposite challenges of client-server and peer-to-peer
One way around this is to use the gigabyte of web space that Comcast provides you, but there are downsides to a pure HTTP client-server model. While an HTTP client-server model works great because it’s persistent and the web server offers much higher capacity than any individual seeder, there’s a fixed amount of web server capacity which quickly divides as the number of clients increases. That means client-server works great when there are fewer clients but it degrades in proportion to the number of clients who want to use the server.
The P2P model has just the opposite problem in that it works better and better as more clients/peers are added because each client becomes an additional server, but it’s horrible when there are few clients and quickly accelerates to death as it loses popularity. The less popular a Torrent is the less likely it is to attract peers because people tend to avoid less popular Torrents fearing slower speeds or being stuck with a Torrent that can never complete.
Combining the two file distribution models
Given the fact that client-server is weak where peer-to-peer is strong and the fact that client server is strong where peer-to-peer is weak; I thought what if we combined the two models in to a single client or a single protocol that gave you the best of both worlds! All we need to do is have a BitTorrent pull from an HTTP source that remains persistent so that there will always be a fast seed to fall back upon even when there are no other peers in the Torrent.
This not only guarantees a survivable Torrent which attracts more peers, it also provides a rocket boost in performance because web servers tend to be 50 to 100 times faster than any Broadband consumer seed. The original seeder would be able to seed and forget and avoid saturating his own upstream connection as well his neighbor’s upstream connection. Given the fact that a typical Cable ISP operating DOCSIS 1.1 protocol allocates 1.25 megabytes/sec of upstream capacity for 200-400 users in a neighborhood, a hybrid web seed would not only benefit consumers but the ISP as well because it alleviates the biggest bottle neck on Cable ISP’s network.
But before I could celebrate my “new” idea and invention, Ludvig Strigeus (creator of the best and most popular BitTorrent client uTorrent) with tongue placed firmly in cheek explained that I was a few years late in my discovery and that the concept of web seeding was already proposed by John Hoffman and “DeHackEd”. Furthermore, the feature is already implemented in uTorrent as well as the official BitTorrent client called “BitTorrent” and Azureus all support web seeding. Those three clients command the lion’s share of BitTorrent clients and there is a full list of compatible clients here.
Note: It’s not your imagination that BitTorrent looks just like uTorrent with a few extra features; BitTorrent Corp acquired uTorrent from Ludvig Strigeus at the end of 2006 because it was technically superior.
Web seeding in practice
One of the problematic Torrents that has been hotly contended in the Comcast TCP reset fiasco is the King James Bible. The is a classic example of something that isn’t popular in BitTorrent because it’s relatively small and readily available on the world wide web over HTTP but it still serves as a good example of what happens to rare Torrents using the pure peer-to-peer model. I created a web seeded Torrent for the King James Bible using Richard Bennett’s gigabyte of web space provided at no extra charge by his ISP Comcast to serve as a persistent and lightning fast seeder. I also took this traditional P2P Torrent of Leonardo da Vinci’s complete Notebooks and converted it to this web seeded torrent.
The difference in speed for this rare torrent was an astounding 100 fold increase in performance. The reliable of this Torrent also shot up because it doesn’t depend on an individual seeder in a residential Cable broadband network who may shut off his computer or P2P application or get TCP reset. The web seed sits outside of the Cable broadband network in some ultrafast server farm that is spared from TCP resets. The ultimate irony here is that Comcast who is known to slow down everyone’s BitTorrent seeds is now giving you a free 100 fold boost in performance! Not only that, but they’re alleviating their last-mile congestion as well as giving you more reliability.
How to create your own web seed
By now I’m sure you want to know how to create your very own web seed Torrent. Simply fire up a copy of uTorrent or BitTorrent and press Control-N or go to the File menu and hit “Create new Torrent”.
You will see the screen on the right and all you need to do is choose a source file from your hard drive, enter in a list of trackers you plan on using, then hit “Create and save as”.
Once you save the .Torrent file, the next step is to copy the source file (the book, video, or song) you want to distribute up to a publicly accessible web server such as the free web space Comcast provides their customers. Many other ISPs also provide free web space if you look around or ask.
Update 5/1/2008 – Robb Topolski posted a comment for this article saying that the example I’m using is actually the getright web seeding specification. Thanks for the clarification Robb!
At this point in time there is no automated support for creating web seeds so you’re going to have to use a program called BEncode Editor to modify the .Torrent file you just created. Once you open up the .Torrent file with BEncode Editor, you will see the following window.
All you need to do is hit the + button and add a “url-list” to the root. You will see the following window where you will add a list of URLs that have a copy of the file that you want to distribute. Note that if you want to distribute multiple files, you point to the folder containing all those files and not just the file. Also note that Apache web servers don’t properly work for filenames with spaces for web seeding while the IIS 7.0 server I tested did work for web seeding even if the filename had spaces in it.
The final step is to publish the .Torrent file on your preferred tracker. For the purpose of this discussion, I used ThePirateBay.org as the tracker and uploaded the files there after creating an account on their site. After I finished uploading the .Torrent file, I got this page which gives you a public link for the .Torrent that you can distribute on a website or via email. You can also email people the .Torrent file directly or you can direct link to the .Torrent file from the tracker. At this point you don’t even need to have your computer participate as a seeder and the seed is extremely fast and reliable. You can even publish the link to the HTTP site if people don’t want to or can’t (office policy) use the Torrent version and those people can download from their web browser directly.
The final outcome is that Comcast doesn’t have to worry about you hogging all the upstream bandwidth in your neighborhood, you free up your computer and bandwidth, the seed runs up to 100 times faster, and now everyone’s happy because of a technical solution.
The person who writes a BitTorrent client that handles this automatically for the top 50 or so ISPs becomes an instant millionaire.
J.Ja
BitTorrent and Comcast – http://www.slyck.com/story1683_BitTorrent_and_Comcast_Work_Together
(Article) BitTorrent and Comcast Work Together
Of course, this doesn’t stop Macrovision and other asshats working for the RIAA/MPAA from sending TCP RST’s and other nefarious tactics.
Informative article, beyond the basics I’m already hip to as a reluctant (cautious) P2Per. And yes, Ludvig Strigeus really was a wiz kid for that crazy little thing called uTorrent. Slicker than Slick Willie himself, yet tinier than Monica’s thrill (so I hear).
George,
Thanks for a good article. Have you taken a look at Deluge (fully open-source and runs on Windows, Linux, and Mac)?
http://deluge-torrent.org/
P.S. does your website support various embed tags for italics, bold, urls, etc?
Thanks
You really need a Digg button on your posts. I almost didn’t digg this because of the extra hassle of having to do it manually through the digg site.
Hi George,
Great article!
The BitTornado webseeding proposal you linked to is not the one you are using, however. You are using the GetRight proposal, and the link for that information is http://getright.com/seedtorrent.html.
Robb Topolski
Just added the digg button. Thanks Digg.
"P.S. does your website support various embed tags for italics, bold, urls, etc?"
You mean in comments dietrich? I’m not sure, I need to search if the default DotNetNuke blog module allows this or not.
"The BitTornado webseeding proposal you linked to is not the one you are using, however. You are using the GetRight proposal, and the link for that information is http://getright.com/seedtorrent.html."
Thanks Robb, I noted it in my blog with credit.
"Of course, this doesn’t stop Macrovision and other asshats working for the RIAA/MPAA from sending TCP RST’s and other nefarious tactics."
Dre, the RIAA/MPAA can’t send TCP resets. Even if you know the all of the IP addresses of the clients participating, you don’t know the dynamic port numbers they’re using.
Although I’ve seen some misinformation among everything else,
This still has multiple levels of cause for concern.
First being that this is really not any different than normal seeding, merely a different location for the file.
Second, being that I don’t really care to use comcast’s network by force in this fashion – web multicasting already provides that benefit in certain uses.
Third being that I don’t trust comcast with my information, not now, not ever, and this doesn’t ensure any form of security for the torrent (because there is none: it’s no longer on the host computer, it’s on someone else’s).
Fourth being that it still doesn’t solve that Comcast has been doing a piss poor job of upgrading bandwidth capability, as upload and download use on the network are still upload and download.
All this is saying is "let comcast host the document so you can download it" but the issue has never been the download speed, its been the 8thousand hours to upload a document to say, comcast’s gig of storage.
1 gig of storage at 1.25MB/200 users = .00625mb/s per user = approximately 6 KB/s. SIX. How long would a gig file to take on 6 KB/s assuming nothing else whatsoever is using any bandwidth at all? I’ve got an easy answer for you: a long time (160,000 seconds) = 2660 hours = 111 days. Let’s take the current real upload cap on the connection, assuming you can use it 24/7 without TCP resets: 40KB/s to upload a gig would still take you almost 2 days (1.7ish)
For large files, this is completely pointless. Even at 80KB/s its completely pointless. The issue remains the same, which is upload speed caps being rediculous. Download speeds with comcast are just barely competitive, but upload? Please, this doesn’t help it anywhere.
"First being that this is really not any different than normal seeding, merely a different location for the file."
There’s a big difference here. It’s 100 times faster than what you can host out of your computer and broadband connection. It doesn’t tie up your upstream or your neighbor’s upstream and it doesn’t tie up your computer.
"Second, being that I don’t really care to use comcast’s network by force in this fashion – web multicasting already provides that benefit in certain uses."
Being "forced" to use something that’s 100 times better isn’t my idea of a bad thing. Web multicasting? What are you talking about? Web sites unicast; not multicast.
"Third being that I don’t trust comcast with my information, not now, not ever, and this doesn’t ensure any form of security for the torrent (because there is none: it’s no longer on the host computer, it’s on someone else’s)."
If you don’t trust Comcast with your information, you shouldn’t trust using P2P on their network either and you shouldn’t trust them with your personal information. If you’re concerned about privacy, you can just encrypt the file and then place it on the web server.
"All this is saying is "let comcast host the document so you can download it" but the issue has never been the download speed, its been the 8thousand hours to upload a document to say, comcast’s gig of storage."
No, it’s about offloading the uploading work to Comcast’s web servers which not only makes it 100 times faster, it also alleviates congestion on your end of the pipe as well as your neighbor’s connection.
"1 gig of storage at 1.25MB/200 users = .00625mb/s per user = approximately 6 KB/s. SIX."
First of all, a web server in a data center usually has about 12.5 MB/sec of peak throughput. Your broadband connection usually has about .048 MB/sec of peak throughput at best.
Second, the web server is only providing the seed bandwidth, 100 times more seed bandwidth than you’re capable of providing. When other peers latch on to the Torrent, they also become servers for each other so this lets you scale to as many users as possible.
Matt, seems to me that you don’t understand the situation or the technology. Even Robb Topolski sees the benefit of this.
Yeah. Oh. Wait?! Was that a slam? From George Ou? Oh no!
Here’s the thing. There’s this "DOCSIS moat" between "Comcast HSI – Internet Side" and "Comcast HSI – Customer Side." (It’s not really a moat, but it is a non-TCP/IP zone your bytes must cross and it’s a bottleneck in a Cable-Internet setup, mostly on the upload side.) ((Suddenly I feel like a certain Senator from Alaska.))
With a normal BitTorrent download, (normal meaning you’re going to finish with a 1 to 1 or 100% upload/download ratio), each byte of that file crosses the "DOCSIS moat" twice. Once down, once back up.
Also, to upload the file to Comcast’s webspace, you need to upload across that moat, sending 100% of the bytes. (Free from RST interference, I might add).
So, either way, you’re taking 100% or more of the data across the upload side. Either way, you’re innocently contributing to congestion on the upload link.
Here’s where the advice gets useful: With your own content, which you are trying to spread, you usually need to seed anywhere from 105% to 150% in order to get the swarm to be healthy. Again, that’s across the moat. But, as someone whose done this a number of times with my own content, I find that I’d rather not concern myself with trying to keep "my" torrent swarm alive. So using my own BitTorrent client, my uploading of my own content across the moat is constant. If I webhost it, the moat is only crossed once. I can turn off my machines, and all that other good stuff George mentioned.
The BitTorrent clients should (and do) only use the webhost for the rarest pieces. If the swarm is well seeded, the webhost might not get hit at all. When i downloaded George’s example, I actually never hit Richard Bennet’s site, because there were sufficient peers.
It’s not for everyone, but it’s a good idea for people publishing their own software, music, or whatever to BitTorrent since it has the added feature of keeping the swarm alive forever without having to babysit it yourself.
"If the swarm is well seeded, the webhost might not get hit at all. When i downloaded George’s example, I actually never hit Richard Bennet’s site, because there were sufficient peers."
Not uploading constantly and not having to baby sit continuously is the whole point of web seeding. Even if that web server only allocates 40 KB/sec per file, it’s as good as a fulltime dedicated seeder.
Now I ran the web seed test for the da Vinci file multiple times and every time the web seed did contribute most of the bandwidth even though there were 12 other seeders. It would seem that backing this file up with a web seed made it a whole lot more popular than the P2P version. It would probably help even more if the file was compressed, but I didn’t do that because I wanted an exact comparison with the pure P2P version.
George and Robb, as always thank you both for the reply.
To first state I don’t think that in any way this is a horrible idea, but I think it needs a lot of further refining and examination before expecting this to be a good solution. Sorry that things came out in a far more hostile fashion.
However, even if a file is encrypted and zipped (at which case safety is less of an issue), I fail to see that it still must be uploaded to the webserver at a slow rate (which they claim is .048, but its really .040 in most cases, but I’m just humorously nitpicking on that), and as said we’d be held to comcast’s decisions. If there happens to be a bad ruling in the court of law and comcast goes "damage control" for liabilities, all you get is a big "so sad, too bad", when your seed is removed. Nothing seems to cover who has the absolute authority over the file.
We still have the basic issue of centralizing hosts vs decentralizing hosts. Having the information on one apparent comcast webserver would mean it is optimal for a certain specific group of people by area. What does that say for the rest of the country, let alone the world, who wishes to download said document? I forsee potential legal and technical issues arising out of this aspect.
I do agree that an ISP offering to take over the bandwidth resource costs of distribution is a good thing. I also agree with yours and robs statements that (in my own wording here) its basically the equivalent of being rented for free someone else’s server, per-se…in terms of that you don’t have to manage things as much..
I do understand the benefits of this technology, even if you seemed to interpret otherwise from my comment. The "let someone with more bandwidth resources" handle the connection is fine. However the "how the heck do I get it to them in the first place" still remains, in terms of upload capacity. 40KB/s as mentioned for an upload (and vigorously advertised by comcast as 320 kb/s "WOW" factor) will still take an excessive amount of time for many legitimate independent works to reach a webserver, such as audio and video recording, theatrical works, etc.
"However the "how the heck do I get it to them in the first place" still remains, in terms of upload capacity."
You upload it to the web server using FTP or HTTP at full speed (whatever peak upstream you can get). This will never be reset and you’re only doing it once.
"40KB/s as mentioned for an upload (and vigorously advertised by comcast as 320 kb/s "WOW" factor) will still take an excessive amount of time for many legitimate independent works to reach a webserver"
40 KB/s is the same thing as 320 Kb/s. You might in reality get 384 Kb/s. It’s pretty standard for the networking people to quote bits/sec rather than bytes/sec. For whatever reason, application vendors choose to use bytes/sec and that has caused a lot of unnecessary confusion for consumers.
As for taking an excessive time to get to the web server and it is the same for any protocol you choose. Your problem is that you’ve bought the wrong technology if 384 Kbps isn’t suitable for you needs.
You do have the FREEDOM to buy a faster Broadband connection or a T1/T3 line to your house if you want the faster upload speeds.
Freedom has nothing to do with dealing with what is the case for comcast. It’s one or the other, which you have very selectively taken out of context as well as jumping past the other issues.
Yet again, I’ll post from above since you somehow missed things I said. Also, notice my capitalization, I did not misinterpret terminology nor mathemetics. I was indeed deliberately denoting kilobytes and not bits. I get 40KB/s, and not 48. You and I both know why vendors use bytes/sec, its for sales psychology. Larger numbers = more. Basic obfuscation of fact.
We still have the basic issue of centralizing hosts vs decentralizing hosts. Having the information on one apparent comcast webserver would mean it is optimal for a certain specific group of people by area. What does that say for the rest of the country, let alone the world, who wishes to download said document? I forsee potential legal and technical issues arising out of this aspect.
Also, correct me if I am wrong, but I do recall there being issues with extended duration TCP and/or FTP transfers, that there are things that can interrupt the connection. Especially considering 1-2days to upload an orphan work of artistic value, for example.
"You and I both know why vendors use bytes/sec, its for sales psychology. Larger numbers = more. Basic obfuscation of fact."
Matt, do you know what baud rate is? The baud rate is the fundamental unit used in communications and it is defined as bits/sec. The unit has been in use since the days of the 300 baud modems. When a web browser displays kilobytes/sec, the browser is the one breaking convention. When bits per second is advertised, that is the correct terminology. If that happens to be the bigger number, then all the better for the marketing department.
"We still have the basic issue of centralizing hosts vs decentralizing hosts."
Last time Matt, this is NOT centralized hosting. The web seed is there as a persistent and fast backup. When you have 10,000 people trying to get the file, they’re most likely not going to be touching the web seed.
"Also, correct me if I am wrong, but I do recall there being issues with extended duration TCP and/or FTP transfers, that there are things that can interrupt the connection."
There is no indication of TCP resets affecting FTP transfers.
Actually, the baud rate is the number of signal transitions per second. With any protocol newer than 300bps modems, the baud rate is actually a fraction of the transfer rate in bps because there are more than two states used in the signalling protocol.
http://en.wikipedia.org/wiki/Baud
FYI You can add a list of Web Seeds when you create a new torrent with utorrent 1.8 beta.