Sure ISP can do anything they want. Hell then can even cut your connection on ALL traffic to 0.00000kb/sec. Generally that doesn't make them money.
Throttle all encrypted traffic? Sure they can do that. Only problem is the thousands of support calls as it breaks dozens of legit apps and ecommerce.
Throttle when upload rate >2kbps? Sure they can do that to. However given that EVERYTHING requires at least some upload bandwidth that essentially is throttling all traffic.
The point of MSE isn't to the "magic winz" button but rather to make the ISP job difficult. The more draconian their shaping the most resource intensive it is, the more expensive it is, and the more it cost them in upset customers and tech support calls.
"The encryption is application-level... Level 7 in the OSI model"
Wow that is enlightening. I guess all encryption can be defeated by simply looking at a lower protocol layer. You should patent that and make billions.
The reality is an encrypted packet doesn't tell you much.
It tells you where it came from and where it is going and the payload (the inspect portion of DPI) is "garbage".
While it can be done it really isn't at least not by most ISP.
Future versions of BT protocol could be "enhanced" to disrupt traffic pattern matching.
Dynamically changing the size of the "pieces", using a rolling number of ports, putting in pseudo-random delays in messages, doing request redirects (instead of sending out 100 requests, send 5 requests and request those clients forward to the end-peer).
Most people who claim their ISP is blocking BT haven't even enables MSE much less gone to a strict MSE mode (force MSE on outbond, reject non-MSE inbound packets).
No we just need to get rid of NAT. IPv6 can't come soon enough.
Of course you still need a firewall and thus you need to open firewall but removing the complexity of NAT makes that a lot easier (especially when you have multiple clients using same protocol).
Really, just give us a damn torrent file and let us use uTorrent because it's better than anything you could come up with off the cuff
This is what Eve Online did. Usually within a hour of patch release the number of seeds is in the thousands (sometimes tens of thousands) and you download speeds get very fast.
"Many linux patches involve downloading hundreds of small files, not one big one."
Put 100 small files inside a single torrent.
Torrent will happily share hundreds of thousands of small files, directories, even entire directory trees without reduced efficiency. The entire torrent is simply a block of data to the BT protocol.
1GB torrent consisting of single file. 1GB torrent consisting of 4839048329 files Performance is identical.
Bittorrent works w/ uPNP and most routers sold today come w/ uPNP turned on. Not saying uPNP is a good thing, desirable, or even safe just pointing out a reality.
Bittorrent also works while firewalled however is a reduced effectiveness mode. It is a misnomer that a firewalled client can't upload to the swarm. It can however it requires the assistance of an open client.
Client A = firewalled (has piece 1234 and needs piece 9999) Client B =open (has piece 9999) Client C = open (needs 1234)
Client A contacts client B requesting piece 9999. Client B notices client A has piece 1234 which Client C needs it. Client B will then send a piece to A AND requires A send piece 1234 Despite being firewalled A was both able to download a piece and upload a piece.
Bittorrent needs open clients just like herd immunity requires a certain % of population to be immunized. However just like herd immunity one can benefit from BT even when firewalled.
then reiterate "as others are only receiving data from the much fewer clients that have ports open"
This is a false statement. A firewalled client WILL STILL UPLOAD. A firewalled client will still contribute to overall torrent success. It simply requires the assistance of another seed. It isn't AS effective but it is effective.
Every single firewalled client will contribute some upload bandwidth. They will provide requires pieces for another peers as directed by the seeds. Like herd immunity only some of the peers need to be unfirewalled for the system to work.
" just creates more traffic from failed attempts to initiate a connection to systems behind restrictive firewalls." Another misnomer. When a peer joins the swarm it indicates it's firewall status. Other peers will never attempt to contact that peer because the client is smart enough to know it can't accept connections.
How BT gets around this is by using a seed. Say your client downloads pieces 18393 from a seed. The seed knows another client needs piece 2878 which you have. Now since your client is firewalled the other client CAN'T contact you directly. Thus the seed instructions your client to send piece 2878 to the other client. No incoming connection was required. As a result bandwidth on the seed was saved allowing the seed to help other clients (maybe even you).
"because of the fact that the VAST majority of people wouldn't actually be seeding." Once again while that is true it doesn't mean what you think it does. You can upload in a swarm without being a seed. You can upload in a swarm (with assistance of an open peer) while being firewalled. In any particular BT session a significant fraction of your downloads comes from NON-SEEDS.
I think your confusion comes from the fact that you think: Only Seed provide upload bandwidth thus no seeds = no upload bandwidth.
That is false.
Just because Valve hasn't implemented it yet doesn't mean they won't EVER implement it.
If you think you are blocking BT then you aren't......
BT supports packet encryption. The Sonic firewall gladly lets all those through because it can't do an inspection of the payload.
Like others have said actually implementing traffic shaping is more effective. Complete block of BT protocol simply will move your users to encrypt BT packets making your "block" utterly ineffective.
Moving BT traffic to a "scavenger" class would keep most user's unecrypted (most clients by default leave encryption off) and thus manageable.
The sad thing is Wow is one of the first examples people think of when it comes to a specific purpose BT implementation.
I agree Blizzard's implementation isn't just bad it is downright incompetent.
Take Eve Online (yeah I know much smaller and less well known). They simply provide a torrent file. Usually an hour or so after patch release you will have couple thousand seeding and is accessable from any of a number of well designed BT clients (supporting things like upload/download limits and encryption to avoid ISP traffic shaping).
Then that is more an issue w/ Blizzards IMPLEMENTATION that an issue w/ Bittorrent protocol.
Even if Blizzard made uploads non-configurable one would think they would at least be smart enough to have the client do a bandwidth check and then internally limit uploads to some fraction of total.
While a firewalled user can't accept incomming connections and it reduces the effectiveness of the protocol they can (and will) contribute to the overall bandwidth.
bitorrent protocol allows non-firewalled peers to directed firewalled peers to contribute upload blocks.
So your mom's computer is firewalled. She requests block A from a peer. That peer informs her client to send a block B (which she has already downloaded) to another firewalled peer.
She can contrbribute significant resources as a leecher even while firewalled. It isn't optimal but anything she shares is better than nothing.
Problem A: ISP blocking is easily solved by encryption. Torrent protocol supports both payload & header encryption. Unless ISP want to blindly start blocking random encrypted packets that is a non-issue.
Problem B: Every heard of a hash? The bitorrent protocol effectively deals (far more than any other protocol). Automatically your bittorrent client ranks peers based on how accurate they are. As accuracy of a peer falls off it is dropped to the back of the pack. Much easier for MPAA to poison ftp servers, usenet, and other p2p systems.
Problem C only exists in your brain. Honestly I don't even know what you are talking about.
Monthly caps are an issue but with protocol encryption it is not possible for ISP to put a limit on bitorrent downloads for example. An http download would count against the same limit.
Have you enabled ecryption. MSE (Message Stream Encryption) is standard on most torrent clients however most clients have it disabled by default. In uTorrent I enable MSE and reject all non encrypted packets & requests.
Using MSE ISP can no longer simply shape based on protocol. Bittorrent uses a random port which makes shaping based on port equally ineffective.
No it doesn't. It normalizes across the entire content. Your TV has no way to know the difference between a commercial and content.
Thus you can apply normalization however it crushes the dynamic range of the content and ends up reducing the INTENTIONAL peaks (chase scenes, explosions, etc) in that content to clip the commercials.
If the commercials are mixed hotter than the content they will STILL be louder just the relative difference is smaller.
The networks can normalize the content and EACH commercial seperately. By the time it gets to you it is all mixed up and anything your TV can attempt is going to be half assed and with significant side effects.
Exactly that is the key point that makes it "difficult" to do smart normalization by the consumer.
when your TV or receiver plays sound it has no concept of content vs commercials. it is simply one giant block on sound. Now you can normalize it however the commercials are mixed hotter thus commercials will still be louder and you will crush all the intentionally loudER parts of the content.
The networks have access to the discrete components content commercial 1 commercial 2 commercial 3.... commercial n
they can determine the average loudness of the content and each commercial SEPARATELY. Then apply a gain to each commercial to normalize it to the content. something like commercial 1 -20db, commercial 2 -13db, commercial 3 +2db.
By the time it gets to the consumers it is "all mixed up" and attempting any normalizing isn't going to work well.
Your right it is just stupid to spend money on a 50" HDTV displaying a 20-50Mbps stream and surround sound when a the 15" screen and pathetic laptop speakers decoding a 2Mbps internet stream gives you THE EXACT SAME EXPERIENCE.
Say you have a show that ranges from -80db to -40db. It simply reduces the dynamic range so the peaks and valleys in the show get "smoothed out".
The problem with commercials is they simply are on full blast w/ vary little dynamic range.
So either a) AGC is too conservative and commercials remains significantly louder b) AGC is aggressive and it dampens commercials but also turns your content into a monotone speech.
Tivo has no automatic commercial detection system.
ReplayTV did and they got sued (and eventually went bankrupt over it despite winning the lawsuit). ReplayTV looks for the blank frames in 30 second intervals +/-2 seconds. Sometimes it would mistakenly jump past content though (Law & Order has noticeable fade to blacks which mess up ReplayTV).
Tivo has no automatic commercial detection/skip system however it does have the next best thing.
You can jump ahead exactly 30 seconds. So commercials come on. Jump jump jump jump jump. Back to content. Sometimes if the first commercial in the block is a good one I will watch that. Makes me wonder if the first commercial spot is worth more.
Slashdot Mirror
Sure ISP can do anything they want. Hell then can even cut your connection on ALL traffic to 0.00000kb/sec. Generally that doesn't make them money.
Throttle all encrypted traffic? Sure they can do that. Only problem is the thousands of support calls as it breaks dozens of legit apps and ecommerce.
Throttle when upload rate >2kbps? Sure they can do that to. However given that EVERYTHING requires at least some upload bandwidth that essentially is throttling all traffic.
The point of MSE isn't to the "magic winz" button but rather to make the ISP job difficult. The more draconian their shaping the most resource intensive it is, the more expensive it is, and the more it cost them in upset customers and tech support calls.
"The encryption is application-level... Level 7 in the OSI model"
Wow that is enlightening. I guess all encryption can be defeated by simply looking at a lower protocol layer. You should patent that and make billions.
The reality is an encrypted packet doesn't tell you much.
It tells you where it came from and where it is going and the payload (the inspect portion of DPI) is "garbage".
There are anonymous VPN tunnels for BT
Also if you are that concerned about your privacy you likely should route all web traffic through an anonymous VPN tunnel.
Then the next level of paranoia is how good a job does your tunnel provider do at deleting logs and leaving no evidence behind?
Which has nothing to do with this article.
Real time traffic analysis is far more difficult.
While it can be done it really isn't at least not by most ISP.
Future versions of BT protocol could be "enhanced" to disrupt traffic pattern matching.
Dynamically changing the size of the "pieces", using a rolling number of ports, putting in pseudo-random delays in messages, doing request redirects (instead of sending out 100 requests, send 5 requests and request those clients forward to the end-peer).
Most people who claim their ISP is blocking BT haven't even enables MSE much less gone to a strict MSE mode (force MSE on outbond, reject non-MSE inbound packets).
No we just need to get rid of NAT.
IPv6 can't come soon enough.
Of course you still need a firewall and thus you need to open firewall but removing the complexity of NAT makes that a lot easier (especially when you have multiple clients using same protocol).
Really, just give us a damn torrent file and let us use uTorrent because it's better than anything you could come up with off the cuff
This is what Eve Online did. Usually within a hour of patch release the number of seeds is in the thousands (sometimes tens of thousands) and you download speeds get very fast.
How do they know?
Bittorrent supports protocol encryption.
Just enable MSE, force all outgoing connections to use MSE, and ignore all non-MSE incoming connections.
Your computer is simply uploading encrypted data. It could be a pushed to a webserver, game traffic, or even VOIP phone call.
"Many linux patches involve downloading hundreds of small files, not one big one."
Put 100 small files inside a single torrent.
Torrent will happily share hundreds of thousands of small files, directories, even entire directory trees without reduced efficiency.
The entire torrent is simply a block of data to the BT protocol.
1GB torrent consisting of single file.
1GB torrent consisting of 4839048329 files
Performance is identical.
Bittorrent works w/ uPNP and most routers sold today come w/ uPNP turned on. Not saying uPNP is a good thing, desirable, or even safe just pointing out a reality.
Bittorrent also works while firewalled however is a reduced effectiveness mode. It is a misnomer that a firewalled client can't upload to the swarm. It can however it requires the assistance of an open client.
Client A = firewalled (has piece 1234 and needs piece 9999)
Client B =open (has piece 9999)
Client C = open (needs 1234)
Client A contacts client B requesting piece 9999. Client B notices client A has piece 1234 which Client C needs it.
Client B will then send a piece to A AND requires A send piece 1234 Despite being firewalled A was both able to download a piece and upload a piece.
Bittorrent needs open clients just like herd immunity requires a certain % of population to be immunized. However just like herd immunity one can benefit from BT even when firewalled.
You can't say "I get that"
then reiterate
"as others are only receiving data from the much fewer clients that have ports open"
This is a false statement. A firewalled client WILL STILL UPLOAD. A firewalled client will still contribute to overall torrent success. It simply requires the assistance of another seed. It isn't AS effective but it is effective.
Every single firewalled client will contribute some upload bandwidth. They will provide requires pieces for another peers as directed by the seeds. Like herd immunity only some of the peers need to be unfirewalled for the system to work.
" just creates more traffic from failed attempts to initiate a connection to systems behind restrictive firewalls."
Another misnomer. When a peer joins the swarm it indicates it's firewall status. Other peers will never attempt to contact that peer because the client is smart enough to know it can't accept connections.
How BT gets around this is by using a seed. Say your client downloads pieces 18393 from a seed. The seed knows another client needs piece 2878 which you have. Now since your client is firewalled the other client CAN'T contact you directly. Thus the seed instructions your client to send piece 2878 to the other client. No incoming connection was required. As a result bandwidth on the seed was saved allowing the seed to help other clients (maybe even you).
"because of the fact that the VAST majority of people wouldn't actually be seeding."
Once again while that is true it doesn't mean what you think it does. You can upload in a swarm without being a seed. You can upload in a swarm (with assistance of an open peer) while being firewalled. In any particular BT session a significant fraction of your downloads comes from NON-SEEDS.
I think your confusion comes from the fact that you think:
Only Seed provide upload bandwidth thus no seeds = no upload bandwidth.
That is false.
Just because Valve hasn't implemented it yet doesn't mean they won't EVER implement it.
If you think you are blocking BT then you aren't......
BT supports packet encryption. The Sonic firewall gladly lets all those through because it can't do an inspection of the payload.
Like others have said actually implementing traffic shaping is more effective. Complete block of BT protocol simply will move your users to encrypt BT packets making your "block" utterly ineffective.
Moving BT traffic to a "scavenger" class would keep most user's unecrypted (most clients by default leave encryption off) and thus manageable.
The sad thing is Wow is one of the first examples people think of when it comes to a specific purpose BT implementation.
I agree Blizzard's implementation isn't just bad it is downright incompetent.
Take Eve Online (yeah I know much smaller and less well known). They simply provide a torrent file. Usually an hour or so after patch release you will have couple thousand seeding and is accessable from any of a number of well designed BT clients (supporting things like upload/download limits and encryption to avoid ISP traffic shaping).
Then that is more an issue w/ Blizzards IMPLEMENTATION that an issue w/ Bittorrent protocol.
Even if Blizzard made uploads non-configurable one would think they would at least be smart enough to have the client do a bandwidth check and then internally limit uploads to some fraction of total.
Price of CDN these days .... runs about $0.10 to $0.20 per GB. ($100 to $200 per TB).
However cheap is all relatively. Sure if your host is pushing 100GB of data per month not a big deal however how about 1TB, 20TB or even 100TB.
In an instance like that CDN isn't a cheap option which is why wikimedia is considering a torrent based option.
Good points except #4
The entire file on each peer and each individual piece are SHA-1 hashed. They ARE all exact copies of the original.
The whole download vs upload thing when it comes to legal action is an interesting issue though.
While a firewalled user can't accept incomming connections and it reduces the effectiveness of the protocol they can (and will) contribute to the overall bandwidth.
bitorrent protocol allows non-firewalled peers to directed firewalled peers to contribute upload blocks.
So your mom's computer is firewalled. She requests block A from a peer. That peer informs her client to send a block B (which she has already downloaded) to another firewalled peer.
She can contrbribute significant resources as a leecher even while firewalled. It isn't optimal but anything she shares is better than nothing.
Problem A:
ISP blocking is easily solved by encryption. Torrent protocol supports both payload & header encryption. Unless ISP want to blindly start blocking random encrypted packets that is a non-issue.
Problem B:
Every heard of a hash? The bitorrent protocol effectively deals (far more than any other protocol). Automatically your bittorrent client ranks peers based on how accurate they are. As accuracy of a peer falls off it is dropped to the back of the pack. Much easier for MPAA to poison ftp servers, usenet, and other p2p systems.
Problem C only exists in your brain. Honestly I don't even know what you are talking about.
Monthly caps are an issue but with protocol encryption it is not possible for ISP to put a limit on bitorrent downloads for example. An http download would count against the same limit.
Have you enabled ecryption. MSE (Message Stream Encryption) is standard on most torrent clients however most clients have it disabled by default. In uTorrent I enable MSE and reject all non encrypted packets & requests.
Using MSE ISP can no longer simply shape based on protocol. Bittorrent uses a random port which makes shaping based on port equally ineffective.
Exactly HOW DARE EA censor themselves.
I mean there should be a law against that or something.
We need to government to pass a law that prohibits any company from self-censorship. Now THAT would be some freedom.
No it doesn't. It normalizes across the entire content. Your TV has no way to know the difference between a commercial and content.
Thus you can apply normalization however it crushes the dynamic range of the content and ends up reducing the INTENTIONAL peaks (chase scenes, explosions, etc) in that content to clip the commercials.
If the commercials are mixed hotter than the content they will STILL be louder just the relative difference is smaller.
The networks can normalize the content and EACH commercial seperately. By the time it gets to you it is all mixed up and anything your TV can attempt is going to be half assed and with significant side effects.
Exactly that is the key point that makes it "difficult" to do smart normalization by the consumer.
when your TV or receiver plays sound it has no concept of content vs commercials. it is simply one giant block on sound. Now you can normalize it however the commercials are mixed hotter thus commercials will still be louder and you will crush all the intentionally loudER parts of the content.
The networks have access to the discrete components ....
content
commercial 1
commercial 2
commercial 3
commercial n
they can determine the average loudness of the content and each commercial SEPARATELY. Then apply a gain to each commercial to normalize it to the content. something like commercial 1 -20db, commercial 2 -13db, commercial 3 +2db.
By the time it gets to the consumers it is "all mixed up" and attempting any normalizing isn't going to work well.
Wow a whole 15.4" low quality laptop screen.
Your right it is just stupid to spend money on a 50" HDTV displaying a 20-50Mbps stream and surround sound when a the 15" screen and pathetic laptop speakers decoding a 2Mbps internet stream gives you THE EXACT SAME EXPERIENCE.
AGC doesn't work for commercials.
Say you have a show that ranges from -80db to -40db. It simply reduces the dynamic range so the peaks and valleys in the show get "smoothed out".
The problem with commercials is they simply are on full blast w/ vary little dynamic range.
So either
a) AGC is too conservative and commercials remains significantly louder
b) AGC is aggressive and it dampens commercials but also turns your content into a monotone speech.
So right you are. I hate that. I would throw in cellphone rings, honking horns, and car crash sounds.
Tivo has no automatic commercial detection system.
ReplayTV did and they got sued (and eventually went bankrupt over it despite winning the lawsuit). ReplayTV looks for the blank frames in 30 second intervals +/-2 seconds. Sometimes it would mistakenly jump past content though (Law & Order has noticeable fade to blacks which mess up ReplayTV).
Tivo has no automatic commercial detection/skip system however it does have the next best thing.
You can jump ahead exactly 30 seconds. So commercials come on. Jump jump jump jump jump. Back to content. Sometimes if the first commercial in the block is a good one I will watch that. Makes me wonder if the first commercial spot is worth more.