Bittorrent To Cause Internet Meltdown
Gimble writes "Richard Bennett has an article at the Register claiming that a recent uTorrent decision to use UDP for file transfers to avoid ISP 'traffic management' restrictions will cause a meltdown of the internet reducing everybody's bandwidth to a quarter of their current value. Other folks have also expressed concern that this may not be the best thing for the internet."
Not really. You would need that if you were transferring a file from one computer to another. But Bittorrent scrapes together little bits of file from lots of other computers. If a packet is lost here and there, that bit of file is naturally requested again, probably from a different machine. That's just a consequence of the way Bittorrent works.
There's no reason in principle for this to be the case; obviously, metering of bandwidth should be by subscriber according to money paid, not by some arbitrary and easily manipulated value like number of open TCP connections.
-- Ed Avis ed@membled.com
...but nobody wants to pay for it. It's been said many, many, many, times before but the average user doesn't have any concept how much bandwidth costs for the circuit to a carrier alone, much less the hardware required to light it. I work with carrier-level Cisco gear, a single linecard alone is in the 50k price range. A single router I work with has 8 of those. It takes at least 2 of those routers to handle a few small to medium size towns, (30k subscribers). That's just the price to give you a connection back to the local building, of course I'm omitting the cost of the wiring to your home, the equipment required to power it, etc, etc. We haven't even discussed how much the transport out to the internet begins to cost. I think a lot of ISP's are beginning to see that it's probably a failing business model, and because of that they are making some-what drastic changes to try and make it sucessful. Things like bittorrent, youtube, etc are what make the web truely great, but at the same time they very well could be the downfall in the current state of the internet. You of course could always get your own internet circuit but even a T1 will be at least $300 per month + construction costs and appropriate gear to utilize it.
ISP's have been managing UDP traffic for years now, this won't change anything. Any of the deep packet inspection boxes (Packeteer, Allot, Sandvine, Ellacoya, etc) can identify the traffic whether it is UDP or TCP as can open source tools like Ntop. Encrypting the traffic can of course disguise what's in the packets, but the overhead hurts transfer speed. In addition, several of the new generation of traffic shapers don't even care what layer 4 protocol you're using, things like Netequalizer just looks at the two IP end points of a given conversation and treats it as a flow regardless.
Not really. You would need that if you were transferring a file from one computer to another. But Bittorrent scrapes together little bits of file from lots of other computers. If a packet is lost here and there, that bit of file is naturally requested again, probably from a different machine.
No... you're getting confused between network packets (a kilobyte or two) and bittorrent's blocks (many kilobytes). Each bittorrent chunk is transferred using many network packets. If you're going to transfer those chunks using UDP, you need to sort out the packet order and do all the missing-packet checks and retries etc yourself. So you still DO need to build some kind of TCP-like protocol on top - even just for the error checking.
Can you imagine signing up for a "3 DVD's at a time" plan from Netflix and then when you actually check out 3 at a time they start bitching up a storm because "You're hoarding the DVD's!!! None of the other customers will be able to rent any of them!!!".
Umm, I believe Netflix was throttling your movie delivery times based on your usage.
http://slashdot.org/article.pl?sid=06/02/11/0754230
Not true, actually. BitTorrent doesn't ask for data in packet-sized blocks. If a single packet is missing from the block, it doesn't (currently) have a way to ask for just that packet. You'd basically be re-implemented TCP to do that.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
That is just not true. Telephone companies where very clear that you should go with them because you don't have to share a line. That was the benefit they claimed that DSL had over cable internet access.
If I sell you a garage for 2 bucks a month, you might wonder but you will probably take the deal. Then you come around and notice that someone else is already standing in the space I sold you, and I tell you that you're allowed to use that space to park your car but only when it's free. Would you be happy? I guess not.
All utilities use statistical averaging. It's not possible to allow for all users to be using 100% of what is available at the same time. Well, perhaps if the infrastruture of all utilities were completely redone it might be possible. For even 1000 people in close proximity to coordinate use of electricity, they could cause massive damage to the system from nothing other than just using what they had paid for.
Phones everywhere in the US were useless on 9/11/2001. Where I worked, they had 2 T-1s for a little over 100 people. The T-1s were full. That's the first time that has ever happened. To have over 50% of people picking up the phone at the same time is unheard of. Sure, we could have bought a dedicated line for each person, but that's not what companies do. I live in Alaska. You have less than a 50% chance of getting a long distance line on Mother's Day. That's right, the entire state is busy. The cell phone systems crash around every large event I've ever been to. The Las Vegas Convention Center is the closest I've been to a large place that worked. It would pop up my voicemails quickly when the person was sent straight to voicemail. For other places that are much more seasonal or random in their use (like state fair grounds) I've seen horrible dial rates. Phone lines all over the US (and the world) were jammed when 9/11 happened, and people were unable to make calls because the utility wasn't able to provide. If there was something that caused similar unusual spikes in demand in any utility, it would crash. No utility designs for 100% utilization by everyone 100% of the time.
The only way to get what you demand is to design all utilities to do that, and no one does. The only functional difference with Internet and the other utilities is that Internet is designed with more sharing. It's like when you buy a phone line, and you get a party line. Sure, you have a phone line, but you can't use it if your neighbor is on it. You had access for emergencies 100% of the time, and otherwise had to share nicely with others.
Learn to love Alaska
See http://forum.utorrent.com/viewtopic.php?id=49813
"What is in 1.9:
uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.
What was in 1.8.1:
uTP, but connection attempts were not initiated by default, and there was no control over TCP as described above. You can enable it, but likely you will see the uTP connections not transfering much data, because they are pushed out of the way by TCP."
This sounds like congestion control of some sort to me.
For example, where I live, I have signed for an electrical plan that entitles me to use a certain amount of electrical power at a given time (=bandwidth). If everyone in my neighborhood used the power they're entitled to, the power lines would melt.
That's half-true. The power company MUST meet peak demand, as well the rest of the electrical system. You can't say to people "sorry, you won electricity tonight because your neighbor is consuming too much power". That's absurd and ridiculous. What ISPs did was to HEAVILY oversell capacity. Too much greed is the problem, not heavy usage.
Marketing half-truth. True you don't share the connection with the ISP with any other customer (thank goodness, the connection is crappy enough), however once it is in the PBX you share the available bandwidth with others in your neighborhood.
So the only difference between cable and telephone (besides the transmission medium) is the point where sharing occurs (cable trunk vs. PBX).
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Note that they don't actually open the packages themselves unless there is an extenuating circumstance (bomb, etc), they might quickly look inside the box with a scanner to detect explosive devices/etc, but this is far and away from what ISP's can do, you can't send bombs that can blow people up in packets. Your counter example is not with the intent of my original message - being able to open private mail.
You can use it but what you can't do is use it for things you agreed not to use it for in your Terms of Service agreement.
That tends to include such things as "running servers." Because of the amount of data uploaded by things like BitTorrent, the ISPs tend to consider that "running a server."
Not a Twitter sockpuppet... but I wish I was.
But BT can well work on UDP and even generate less overhead and thus actually less traffic than it does today.
Only if it adds its own layer of TCPness on top.
Here's the deal. You have one gigabyte of data to download. It's been split into one megabyte chunks, and you know the sha1 hash of every 1-meg chunk.
You go ask a peer for a 1-meg chunk. You get 1024 little 1k-chunks in return. There are 1024! permutations of them. Please put them in the right order.
You could, you know, number them. If you want men outside the middle to not be able to spoof a connection from you, you need to start numbering from a random place, and tell the other endpoint from where you start your numbering.
Presumably, you want to make outgoing connections to several peers at the same time. Hmm... I know, let's number each of the connections, and send the number to the receiving end.
Boy, this sounds a lot like port and sequence numbers...
If you do a 20-byte hash (say, sha1) of every 1k block, you end up with a 1-to-50 reduction. For a 1G torrent, the .torrent file is 20 meg. Presumably you could use a somewhat smaller hash function for each packet and then use a bigger hash for a chunk of packets...
I'm not saying it can't be done. But I don't see what compelling features UDP offers that you can't get almost as effectively with TCP. Care to enlighten me?
BitTorrent claims it is actually trying to reduce congestion.