dslreports logo
 story category
Bit Torrent Encryption
Cat & Mouse
The BBC explores the continuing cat & mouse game that is the use of Bit Torrent over broadband networks. The latest move, as we've discussed is the use of end to end encryption to confuse traffic shaping hardware. Torrent Freak has a quick rundown of how to enable encryption in most of the major Bit Torrent clients. Some ISPs, like RCN, are limiting the number of upstream Torrent connections that can be made, making this tactic ineffective.
view:
topics flat nest 

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3

Premium Member

Not only limiting number of connections...

...but by encrypting the packets, you essentially make any QoS your router does to limit the upstream torrent speeds when you need the bandwidth ineffective, IE: VoIP.
russotto
join:2000-10-05
West Orange, NJ

russotto

Member

Re: Not only limiting number of connections...

You can prioritize VoIP up rather than prioritizing bittorrent down.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3

Premium Member

Re: Not only limiting number of connections...

said by russotto:

You can prioritize VoIP up rather than prioritizing bittorrent down.
Yes, but then you have to do that for EVERY protocol you want to take precedent over BT. Otherwise, HTTP, POP3, SMTP, FTP, and anything streaming slows to a crawl. Including online gaming.

I guess you could install a second NIC, bind BT to that IP and deprioritize all traffic on that adapter.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

... Or they could just deploy the technology that has been available for years in other countries and give the users a REAL internet connection rather than these 3mbps sandboxes. Then QoS would be a non issue as the bandwidth would be available for all applications. They are going to have to upgrade soon, the only disagreement these days is how soon, and how much to upgrade. The biggest problem right now is the fact that the companies with the fiber, generally dont provide the end user connectivity, so the end users are stuck with these greedy resellers who themselves are getting gouged on price and passing on the load to customers.

sporkme
drop the crantini and move it, sister
MVM
join:2000-07-01
Morristown, NJ

sporkme to Matt3

MVM

to Matt3
said by Matt3:
said by russotto:

You can prioritize VoIP up rather than prioritizing bittorrent down.
Yes, but then you have to do that for EVERY protocol you want to take precedent over BT. Otherwise, HTTP, POP3, SMTP, FTP, and anything streaming slows to a crawl. Including online gaming.
No. You make VoIP the highest priority.

You do this either based on the IP of your TA or (better) by IP ToS. It works very well.

I use this: »www.pfsense.org/ and it works beautifully. I can ftp something up, do a big scp upload, BT and be on on the phone. My terminal sessions are still nice and zippy and the phone works well. Configuring the traffic shaper was 5 or 6 clicks at most.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

As VOIP providers get bigger, their server pools will too. You will need to have a HUGE list to compare destinations with to see whats a VOIP server and whats not. Every line of a filtering or priority rule slows down your box, so its not a very scalable solution, which is why we use port numbers. Just keep that in mind =P

G_Poobah
join:2004-01-17
Schenectady, NY

G_Poobah to Matt3

Member

to Matt3
"you essentially make any QoS your router does to limit the upstream torrent speeds when you need the bandwidth ineffective"

That is in fact, a true statement. But focus on the important part of that.. "YOU".. as in YOU, the consumer, decide what traffic you want to go in/out of your connection, how much bandwidth it gets (by configuring your bittorrent client), not the ISP. If YOU decide to run it that way, it's YOUR call. YOU paid for XXX bps upstream/downstream, so YOU decide how to use it.

Replace the word "YOU" with the word "COMCAST", and you'll see why encryption is required.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3

Premium Member

Re: Not only limiting number of connections...

said by G_Poobah:

"you essentially make any QoS your router does to limit the upstream torrent speeds when you need the bandwidth ineffective"

That is in fact, a true statement. But focus on the important part of that.. "YOU".. as in YOU, the consumer, decide what traffic you want to go in/out of your connection, how much bandwidth it gets (by configuring your bittorrent client), not the ISP. If YOU decide to run it that way, it's YOUR call. YOU paid for XXX bps upstream/downstream, so YOU decide how to use it.

Replace the word "YOU" with the word "COMCAST", and you'll see why encryption is required.
What point is it you're trying to make? I'm a little lost. It sounds to me like you're simply re-stating the obvious.

If you use encryption to defeat the QoS Comcast or any provider is doing to shape traffic, you also lose the ability to EASILY shape your own traffic.

Like the article said though, eventually all providers will simply limit the number of simultaneous outbound connections, which encryption will do nothing to prevent.

knightmb
Everybody Lies
join:2003-12-01
Franklin, TN

knightmb

Member

Re: Not only limiting number of connections...

Then that's another clause to add to their terms of agreement. You know that won't sit well those that read through it.

"By signing up with this service you can only make 10 upstream connections at one time"

This does nothing except force the BT client to use the X number of fastest connections, which still results in full upstream bandwidth usage.

They have solved nothing, if their network can't handle everyone doing full upstream, then they need to figure out how much they can handle and divive the bandwidth out evenly and just don't bother with the upstream advertised speed. There is a ton of technology to do even bandwidth splits and it's much cheaper and eaiser to use than per packet inspectoin and all the likes. They need to join us in the 21st century
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

Actually, They WONT be able to limit outbound TCP connections if people started using IPSEC. And since XP supports it, with it enabled by default in vista, all *nix has supported it for years. Their days of spying and attempting to bean-count traffic are coming to an end. All it would take is one enterprising coder to write a simple ipsec tunneling proxy for everybodys favorite bittorrent client and the game is over.
yabos
join:2003-02-16
London, ON

yabos

Member

Re: Not only limiting number of connections...

But who's going to host the other end of the VPN? There'd have to be a central hub using enormous amounts of bandwidth if you wanted everyone to tunnel to it.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

This is NOT a VPN. IPSEC Transport Layer Security provides encrypted payload without the need for any tunnels. Investigate wikipedia. IPSEC + IKE = WIN.

Combat Chuck
Too Many Cannibals
Premium Member
join:2001-11-29
Verona, PA

3 edits

Combat Chuck to meta

Premium Member

to meta
said by meta:

Actually, They WONT be able to limit outbound TCP connections if people started using IPSEC.
How so? They won't be able to limit it based on whats inside the packet, but the packets still behave like a BT packet. They can still develop systems that can block based on the behavior.

IE: no limits on outbound packets until the user exceeds 100 in ten seconds, then limit it to 1 per second until the number of attempts goes down.

Ultimately what it comes down to is that you are bound by whoever sit above you in the chain you can encrypt and whatnot to make it harder for them to target specific things but ultimately they can throw the switch, be it turning you completely off or dropping random packets to slow you down.
meta
join:2004-12-27
00000

1 edit

meta

Member

Re: Not only limiting number of connections...

The entire tcp segment is encrypted. That means:
No port numbers are visible.
No TCP Session information is visible.
No bittorrent header or data is visible.
The only available information to the ISP would be the source and destination IP addresses, as well as other standard IP header fields. NONE of which would permit them to distinguish that traffic as different or p2p related.

If the traffic is indescernable from any other, there will be no point in QoS rules. They work by clear simple criteria met by a frame/packet/segment. There isnt enough processing power on earth to perform the heuristic calculations necessary to guess at what a user is up to providing the encryption is implimented at the appropriate layer.
Necronomikro
join:2005-09-01

Necronomikro

Member

Re: Not only limiting number of connections...

Yes, and they can still block based on connection attempts. If I make 20 connections in a second, I'm obviously using P2P...
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

THEY CANT SEE CONNECTION ATTEMPTS. Im getting sick of repeating this. The concept of CONNECTIONS is implimented through the use of TCP. If that is encrypted they cant tell who you have an active connection with!
Necronomikro
join:2005-09-01

2 edits

Necronomikro

Member

Re: Not only limiting number of connections...

Ok. The traffic is going through their router. You can't magically make a connection without the ISP knowing about it. THE ISP ROUTER HAS TO KNOW WHERE TO SEND THE PACKETS TO! THAT IS A CONNECTION! (Even if you're using UDP or similar [EG, a different, "connectionless", protocol] you're still transmitting end IP information. If you're sending packets to 20, or 100 people at a time, that'll look quite suspicious, don't you think?) YOU SAID YOURSELF THAT THEY KNOW WHAT THE END IP IS! Thus, if you use an IPSEC connection to each person, they will know how many connections you have simply by the number of IP tunnels (Connections, UDP sessions, IPSEC sessions, whatever) you have open. Now, if you use an IPSEC/VPN tunnel to, say, some router someone has that has an ISP that doesn't block this, that's a different story, they'd only be able to see one connection.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

You clearly dont understand how TCP/IP works. They can see individual IPs however that DOESNT let them know a connection is established. That means after viewing 100 webpages they would still think you have 100 open connections because THEY DONT HAVE THE TCP SESSION INFORMATION. NO SESSION = NO CONNECTION BASED COUNTING OR THROTTLING.
Necronomikro
join:2005-09-01

1 edit

Necronomikro

Member

Re: Not only limiting number of connections...

Ok. Let me spell it out to you. TCP works on an open and close system - you open a connection, and it's considered open until you send a close.

Now, you have other protocols, like UDP that work on a connectionless system - you just listen, and you can send a packet at any time. For this protocol, they use a timeout system, so that when you send, a "connection" is established for the next, say, 30 seconds, so that a packet can be sent back (for routing purposes).

I'm sure there are other protocols that work with different ideas in mind, but I'm not aware of them.

Now, even if the protocol uses a connectionless system like UDP, they can still watch you sending packets. If you haven't sent a packet to an IP in 5 minutes, then consider the connection "closed". If you have sent a packet within 5 minutes to said IP, then the connection would be "open". They could make it so that if you have 20 "open" connections, then you have to wait for one to time out before opening a new one.

You should read up on TCP.

»en.wikipedia.org/wiki/Tr ··· Protocol

And, as for IPSEC... it's an encrypted connection based protocol, but, they still have to rely on IP connections. This isn't much different from what they're already doing with bittorrent, except that it's done over a TCP connection.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

Sigh, i give up. You fail at the internet.

If they cant see any connection details, every packet to every distinct IP would have to be counted as a connection under any halfassed solution you or they cook up. That means thismorning you have made 500 "connections" just surfing a few sites. IF YOU DONT KNOW WHEN A CONNECTION TERMINATES YOU HAVE TO ASSUME ITS STILL OPEN and since we know if encrypted it cant tell. That means under the proposed solution you would have 500 open connections right now and your going to get throttled for reading your broadband news. Good game. Im going to get lunch.
Necronomikro
join:2005-09-01

Necronomikro

Member

Re: Not only limiting number of connections...

YOU CAN USE A TIMEOUT.

You can use timeouts to see whenever the connection is "closed". If there has been no packets sent to an IP for 5 minutes, consider it closed. Is that so hard to think of?

And, you can still look at TCP/IP connections, and they still use open/close. So, reading BBR is irrelevant [EG. they're normal TCP/IP packets, and they know when those close, because your client sends a close packet!!!!]. You just give totally encrypted IPSec traffic different treatment...
Necronomikro

Necronomikro

Member

Better yet, let's put it this way. Current Bittorrent encryption VS your ipsec idea.

Current:
1. Connect to tracker and get tracker details for the torrent.
2. Open TCP/IP connection to peer/seed.
3. Send encryption details.
4. Start sending data.
5. Repeat 2 to 4 for each peer.

Your idea:
1. Connect to tracker and get tracker details for the torrent.
2. Send IPSec encryption header.
3. Use IPSec tunnel to connect to peer/seed.
4. Start sending data.
5. Repeat 2 to 4 for each peer.

How are those really much different? And, by the way, the encryption header can be seen as a connection attempt, and use a timeout for finding out when the connection is "closed".
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

Whats the timeout? 3 minutes without seeing traffic? Is that fair.

How many different connections can you legitimately make in 3 minutes without using file transfer services.

Answer: Fire up ethereal and go google something. Every page you open to check before clicking back loads dozens of images, and if you look at most major sites (just take cnet for example) they have many different content servers.

Hundreds of connections and no p2p. That sort of filtering WILL NOT WORK AS DESIRED.
Necronomikro
join:2005-09-01

Necronomikro

Member

Re: Not only limiting number of connections...

You can still monitor TCP/IP properly. Just give special treatment to your fabled IPSEC packets. TCP/IP *does* send an open packet and a close packet, so you can monitor it properly.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

"Monitoring TCP" without being able to see any of it is absolutely rediculous.

The only "OPEN" sort of message you could POSSIBLY look for is the AH.

Any closes would still be guesses based on timeouts.

Creating a box with enough memory and processing power to REMEMBER every IP to IP link and track bandwidth is absolutely beyond fiction.
Necronomikro
join:2005-09-01

1 edit

Necronomikro

Member

Re: Not only limiting number of connections...

I was refering to you stating that they can't use that model, because it'd catch web traffic, too. They CAN monitor HTTP traffic, because it uses standard TCP connections.
You're confused. READ UP ON WHAT TCP IS!

Connection establishment

To establish a connection, TCP uses a 3-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established then a client may initiate an active open. To establish a connection, the 3-way (or 3-step) handshake occurs:

1. The active open is performed by sending a SYN to the server.
2. In response, the server replies with a SYN-ACK.
3. Finally the client sends an ACK back to the server.

At this point, both the client and server have received an acknowledgement of the connection.

Example:

1. The initiating host (client) sends a synchronization (SYN flag set) packet to initiate a connection. Any SYN packet holds Sequence Number. The Sequence Number is a 32-bit field TCP segment header. For example let the Sequence Number value for this session be x.
2. The other host receives the packet, records the Sequence Number of x from the client, and replies with an acknowledgment (ACK). The Acknowledgment Number is a 32-bit field in TCP segment header. It contains the next sequence number that this host is expecting to receive (x + 1). The host also initiates a return session. This includes a TCP segment with its own initial Sequence Number value of y.
3. The initiating host responds with a next Sequence Number (x+1) and a simple Acknowledgment Number value of y + 1, which is the Sequence Number value of the other host + 1.

Connection termination

The connection termination phase uses, at most, a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical teardown requires a pair of FIN and ACK segments from each TCP endpoint.

A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can.

It is also possible for a 3-way handshake when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK. This is perhaps the most common method.

Finally, it is possible for both hosts to send FINs simultaneously then both just have to ACK. This could possibly be considered a 2-way handshake since the FIN/ACK sequence is done in parallel for both directions.
From wikipedia: »en.wikipedia.org/wiki/Tr ··· Protocol

Now, that's TCP. What you're talking about for use with bittorrent is a totally different protocol - IPSec [which, by the way, a lot of routers have problems with, for example, I don't have the option to forward any IPSec traffic to my machine with mine, nor do many residential routers]. IPSec does use an AH which could be interpreted as a connection attempt, and then you can use a timeout.
meta
join:2004-12-27
00000

2 edits

meta

Member

Re: Not only limiting number of connections...

Im talking about the future and WIDESPREAD DEPLOYMENT OF IPSEC MAKING DISTINGUISHING OF INVIDUAL PROTOCOLS LIKE HTTP AND BITTORRENT IMPOSSIBLE.

Dont confuse TODAY with ENABLED BY DEFAULT IN VISTA. As soon as its available WIDELY on clients, server operators need only enable their favorite IKE daemon.
Necronomikro
join:2005-09-01

1 edit

Necronomikro

Member

Re: Not only limiting number of connections...

Then you should have made that clear! Yes, if EVERYTHING is encrypted with IPSec, then distinguishing them would be difficult. However, most servers don't support it, so that's a moot point ATM.

Edit: Not to mention that you can still watch some behavior patterns - like number of outbound connection ATTEMPTS (AH) per second, number of active connections (eg. how many ips you're recieving and transmitting to), not to mention that you kinda give yourself away with the visit to the tracker, if that's over tcp/ip (eg. not using an ipsec tunnel)
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

The SERVER side supports it fine. Every modern Linux and BSD box out there is only a kernel module load away from it. The CLIENTS are what dont support it. Eventhough support exists in XP nobody has it enabled except a few enterprise users.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3

Premium Member

Re: Not only limiting number of connections...

Because once it hits your ISP who doesn't know what you do with the IPSec encrypted traffic, you either have to encapsulate it inside a normal IP packet which defeats the purpose, or their network will simply drop it.

IPSec is NOT the answer.

There really isn't an answer that the current implementation of BitTorrent can address. There are enterprise level traffic shaping devices (think Packeteer) that do BEHAVIORAL analysis on traffic and, encrypted or not, can tell what is likely going on. There is no way to get around that at this point, but I don't put it past the BT client developers to find a way.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

Your wrong plain and simple. You dont know how IPSEC TLS works. I dont have time to explain it now.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3

Premium Member

Re: Not only limiting number of connections...

said by meta:

Your wrong plain and simple. You dont know how IPSEC TLS works. I dont have time to explain it now.
Actually, I'm quite familiar with IPSec TLS and AH.

It doesn't matter if the header, the payload or both are encrypted, if you're opening 500 connections a second to random addresses on the internet, it's pretty easy for the ISP to deteremine that you are running a P2P program and throttle the number of connections you're opening.

Can the ISP see the data inside the packet? No. But it simply doesn't matter because there isn't a single other program out there that has a "fingerprint" like P2P programs do.

So until there is either a protocol that opens a SINGLE tunnel to one location, then funnels all your traffic through that to disperse your multiple connections out the other end, or a BT client developer figures out a way to fool all the behavioral and/or fingerprinting detection and shaping devices, IPSec won't make a damn bit of difference.

I suggest you read this plain English definition of IPSec so you will understand why it's not the solution: »en.wikipedia.org/wiki/IPSec
Necronomikro
join:2005-09-01

1 edit

Necronomikro to meta

Member

to meta
said by meta:

The SERVER side supports it fine. Every modern Linux and BSD box out there is only a kernel module load away from it. The CLIENTS are what dont support it. Eventhough support exists in XP nobody has it enabled except a few enterprise users.
Just because you CAN install support for it doesn't mean that EVERYONE has it installed. There's still the issue of not many routers supporting IPSec traffic properly (NAT problems, mainly).

Like the clients, not many servers have it installed, enabled or set up properly. Any of those three makes it useless.

EDIT: Besides, why would, say, microsoft.com want to enable ipsec? Or, any of godaddy's hundreds, or thousands, of servers? Why would they even bother? What's the point? So that it'll make things confusing? There's not much of a point to enabling it just for HTTP.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

They would turn it on because their clients would like secure access to their sites. I can see IPSEC replacing SSL. But thats a random prediction. The point is there are ALOT of legit uses for it. In fact they probablly already have it enabled for internal use. MOST carriers know how to setup IPSEC for stuff like BGP sessions.

Combat Chuck
Too Many Cannibals
Premium Member
join:2001-11-29
Verona, PA

Combat Chuck to meta

Premium Member

to meta
said by meta:

Creating a box with enough memory and processing power to REMEMBER every IP to IP link and track bandwidth is absolutely beyond fiction.
The state of a TCP connection is irrelevant, the fact that a connection was at least attempted is.

Furthermore you don't have to save many specifics, just the info on endpoints that were active in the last X number of seconds and possibly some sort of modifier that represents how likely it was you were using BT in previous timeframes.

It doesn't have to be perfect, quick and dirty is going to be enough.

••••
Combat Chuck

2 edits

Combat Chuck to meta

Premium Member

to meta
said by meta:

The only available information to the ISP would be the source and destination IP addresses, as well as other standard IP header fields. NONE of which would permit them to distinguish that traffic as different or p2p related.
Incorrect they still can watch the behavior.

streaming: a steady stream of low bandwidth outbound packets being sent to one IP and a steady stream of relatively high bandwidth packets inbound from the same IP.

websurfing: short bursts of low bandwidth packets outbound to one IP that and are followed up by a short burst of medium bandwidth packets inbound from the same IP.

BT: A steady stream of outbound, high bandwidth packets being sent to multiple IP's accompanied by a stream of incoming high bandwidth packets from multiple IP's.

All IPSEC will do is make it harder to target an individual protocol running on your machine for degradation; so instead, should they choose, they'll degrade the whole line if they suspect you're using BT based on it's behavior.

You don't have to see a truck to know one is driving down your street.

••••••••••••
yabos
join:2003-02-16
London, ON

yabos to meta

Member

to meta
OK, even if it doesn't work with the same concept as a connection, they can still see you are blasting packets to 200 IPs. IPs WON'T be hidden because the whole internet relies on them to work.

Even with the concept of a connection, you don't physically have anything on the router connecting you. You are just sending packets every x ms or second to say that your connection is open. The only thing that a router needs to do in this situation is forward packet x to destination y which I don't see how IPSEC could change that.

I don't know if they do filter on session information in the packets or what, but it's still suspicious if you are sending packets too >100 peers and receiving packets from that number of peers as well. It's pretty obvious to me if IP address Y receives packets from 100 different IPs in such a short period of time even if you don't know what's in the packets.
meta
join:2004-12-27
00000

meta

Member

Re: Not only limiting number of connections...

Thats right, they will see how much traffic your sending. But thats ALREADY CAPPED so what does it matter. They wont be able to TARGET individual connections or streams. JUST YOUR ENTIRE CONNECTION which is already limited to 3mbps or whatever.

Ignite
Premium Member
join:2004-03-18
UK

Ignite

Premium Member

Re: Not only limiting number of connections...

said by meta:

Thats right, they will see how much traffic your sending. But thats ALREADY CAPPED so what does it matter. They wont be able to TARGET individual connections or streams. JUST YOUR ENTIRE CONNECTION which is already limited to 3mbps or whatever.
You sir fail at traffic shaping class, every connection your PC opens is considered a 'flow' which can be dropped or shaped depending on ISP needs.

You think the current DPI hardware can't handle load? These guys will happily sit there monitoring and throttling 500k flows and upwards with 2Gbit/s bandwidth. More than enough to handle a few cable CMTSes or DSLAMs.

You seriously don't understand how the hardware works, encrypt all you want they still have control, and if they can't work you at layer 7 they'll work you at layer 4. If they can't work you at layer 4 they'll work you at layer 3. Try encrypting IP headers without having a tunnel endpoint.

G_Poobah
join:2004-01-17
Schenectady, NY

G_Poobah to Combat Chuck

Member

to Combat Chuck
"but the packets still behave like a BT packet."

Hmm.. I'm not exactly sure how a packet behaves like a bit torrent packet. All packets behave as packets. They can either block ALL encrypted packets, or no encrypted packets, there's no middle ground. They can either throttle ALL encrypted packets or NO encrypted packets, again, there's no middle ground.

The CAN tell that I opened up 100 connections in 10 seconds. But what if I tell my client to only open up 8 new connections per second. (assuming I didn't use ipsec) That's no different than a web browser opening CNN. How can they tell if it's not 5 different computers behind a NAT, say a home. They can't.

So, they drop random packets? Hmm.. that means that they are deliberately messing with my VoIP. That's a big no no..

The bottom line is this. There is no cost effective, easy way for an ISP to throttle bit torrent without impacting other services. If they WANT to throttle bittorrent, then they need to only sell 512kb/128kb connections. That is the ultimate solution. But then they can't complain when people use all 512/128. If they sell 8mb/1mb, then they should expect people to use 8mb/1mb. As new technologies and capabilities come out, more and more people will be using 8mb/1mb. They can upgrade, or sell less. That, of course, is the only possible outcome.

••••••

BT why
@speakeasy.net

BT why to knightmb

Anon

to knightmb
BT is at best just plain wrong. It hacks around bandwidth limiting and QOS put in place by the ISP. So that is kind of like hacking an ATM to give you $100 instead of $10 and saying it is okay...

Combat Chuck
Too Many Cannibals
Premium Member
join:2001-11-29
Verona, PA

Combat Chuck to G_Poobah

Premium Member

to G_Poobah
said by G_Poobah:

Replace the word "YOU" with the word "COMCAST", and you'll see why encryption is required.
Just for clarity, Comcast isn't throttling P2P at this point.

Perhaps you could choose one who actually is in you're next example so those who don't know how to set up BT don't run a search and stumble on your post and then use it as "evidence" that CC is throttling BT.

BIGMIKE
Q
Premium Member
join:2002-06-07
Gainesville, FL

BIGMIKE to Matt3

Premium Member

to Matt3
Let's Keep File Sharing Safe and Legal

Sixty million Americans use peer-to-peer applications to trade files. That's more people than voted for George Bush. If we work together, we can shake up the government so profoundly that sharing music - anyone's music - is no longer illegal.

Many, many millions more people share music around the world - if your country is democratic, you can change your laws too. If your country is not democratic, I can certainly appreciate the difficulty you're in. But if you have courage, political change is still possible, although more costly, but worthwhile for reasons a lot more significant than making it legal to swap music.

If you don't think this can happen, consider Slashdot user Quizo69's comment "Illegal becomes legal if YOU change it", in which he points out that although it was once illegal to be homosexual throughout the United States, the gay community worked together to fight sodomy laws. Through their efforts, state after state repealed their laws until the Supreme Court of the United States recently ruled the last sodomy laws unconstitutional.

If the gay community can fight millennia of hatred until they can live without fear of criminal prosecution, you can overturn the copyright laws. If you don't think you have the political power, consider that there aren't as many homosexual people in the U.S. as there are file traders.

In the United States, copyright is not a Constitutional right, like freedom of speech. The Constitution grants Congress the power to create copyright, but doesn't require it to do so. From Article I, Section 8 of The Constitution of the United States of America:

The Congress shall have power to... promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries;

No form of "intellectual property", also including patents, trade secrets and trademarks are a "natural right". The concept of intellectual property has not existed for very long in history at all. (While trade secrets have existed throughout history, it is only recently that they have enjoyed any sort of legal protection.)

Our founding fathers didn't grant Congress permission to make copyright legal because they felt is was any sort of natural right. They did it because they thought it would be a useful thing to do to stimulate the economy of a young nation: "To promote the progress of science and useful arts". Copyright and patents encourage authors, artists or inventors to openly publish their works by giving them a temporary monopoly. In return for this grant of monopoly, the work is supposed to eventually go into the public domain, so all may benefit from copying it. Let me make it explicit:

The purpose of both copyright and patents is to make it worthwhile for authors and inventors to release their writing, music and inventions to the public domain, rather than keeping them secret.

But that's not the situation today. Because the copyright on Mickey Mouse was due to expire in 2004, Walt Disney lobbied Congress (with the aid of prodigious campaign "donations") to pass the Sonny Bono Copyright Term Extension Act, extending the copyright term to ninety-five years, not just for new works, but for works that were copyrighted before the act was passed. The law applied even to works about to pass into the public domain, so Congress rode to Disney's rescue to keep Steamboat Willie safe.

(If any of Mickey Mouse's cartoons ever entered the public domain, it would not have diluted Disney's trademark on the character, but it would have made it possible for others to use Mickey Mouse in ways that did not dilute the trademark.)

With the current ninety-five year copyright term, you cannot expect that you will live to see a copyrighted work created today ever go into the public domain. The creators of copyrighted works are not keeping up their end of the bargain that the framers of the Constitution offered them. Because the copyright term was extended even for works whose copyrights were about to expire, no reasonable person can consider that the requirement that copyright be granted for "limited times" has been obeyed by Congress.

A brilliant young law professor named Lawrence Lessig, who has an understanding of technology issues quite unusual for an attorney, led a lawsuit to overturn the Sonny Bono Act. The closely watched Eldred v. Ashcroft case quickly reached the Supreme Court. Yet in an astonishing rejection of Constitutional principles, the Court ruled against Lessig. Read the Court's opinion. (Supreme Court opinions are often surprisingly readable for legal documents - it's worth your while to take a look.)

Sucks, doesn't it? What can you do about it? Well, let me tell you:

Speak Out
»www.shoutwire.com/viewst ··· nd_Legal
Necronomikro
join:2005-09-01

Necronomikro

Member

Re: Not only limiting number of connections...

They found in the favor of Disney on the grounds of them extending it now for them won't necessarily happen in the future. Ok, so now that it's 95 years, what happens when they extend it again?... What's the point, anyways, with it being 95 years? Copyright should be 10 years, 15 for art/books/music. That's a lot fairer, gives them time to do what they want. Besides, anything older than 10 or 15 that they're still selling is just them bleeding their customers dry.

TOPDAWG
Premium Member
join:2005-04-27
Calgary, AB

2 edits

TOPDAWG

Premium Member

ISP's need to deal with the data load.

SO WTF are the ISP's going to do when Hollywood starts to use BT for downloading movies? Allot more companies are moving towards it as a way to save money. BT is great for indie film markers and music people.

A few anime companies are using it to make longer trailers for shows for download.

BT is the future of download ISP's can't block it forever. Just cause BT can be used for something bad does not mean it should be blocked. Hell you may as well blame the net itself for all the child porn on it and other illegal crap.

God if ISP's hate all this data people are downloading now they will have a heart attack once downloading games and all types of media become the norm. Anyway just to ask how much data is a true HD movie? That is going to come sooner then later.

ISP's are going to have to deal with it and come up with a way to deal with it.

So to make sure I understand do ISP's have issue with BT itself or just all the bandwidth that BT users are using?
meta
join:2004-12-27
00000

meta

Member

Re: ISP's need to deal with the data load.

See thats why ISPs want to run their own video and content services. It costs them nothing to push movies over their copper. They are mad because their customers are accessing that content on REMOTE networks which is massively increasing the $ they need to pay their upstream providers. They still think the future is some middle man getting rich without creating any content or laying any new fiber.

Ignite
Premium Member
join:2004-03-18
UK

1 edit

Ignite

Premium Member

Re: ISP's need to deal with the data load.

You appear to think that the ISPs should just put the infrastructure in and not get paid. Sadly the the real world doesn't work that way, someone has to pay for the equipment and its' maintenance.

If shareholders aren't getting a return on their investments companies go out of business. The internet is actually powered by companies, not magical mystical Torrent fairies hailing BT as being the entire internet. These guys don't get paid the internet dies, simple as.

asdjf
join:2005-01-01

asdjf

Member

Are that many ISPs really traffic shaping?

I just can't imagine that there are really that many ISPs willing to make their service less valuable to their most satisfied customers.
meta
join:2004-12-27
00000

1 edit

meta

Member

Re: Are that many ISPs really traffic shaping?

ISPs have been traffic shaping for YEARS. Just not targeted at downgrading consumer service. QoS (Quality Of Service), CoS (Class Of Service), DIFFSERV (Differenciated Services), MPLS (Multi-Protocol Lable Switching). These are all related to shaping traffic, and you wont find a job description for a network engineer at an ISP that doesnt mention them in the criteria. For a long time the only people with the hardware necessary to do this were the larger carriers and backbone providers, however these days it seems every small to medium sized last mile isp can get their hands on the hardware necessary to degrade the connectivity of the internets killer application on an idiot executives whim.

Count on one thing: Until widespread implimentation of bulletproof encryption things will only get worse as these companies misplace blame and attempt to make the same kind of profits when the world has changed.

Ignite
Premium Member
join:2004-03-18
UK

1 edit

Ignite

Premium Member

Re: Are that many ISPs really traffic shaping?

said by meta:

ISPs have been traffic shaping for YEARS. Just not targeted at downgrading consumer service. QoS (Quality Of Service), CoS (Class Of Service), DIFFSERV (Differenciated Services), MPLS (Multi-Protocol Lable Switching). These are all related to shaping traffic, and you wont find a job description for a network engineer at an ISP that doesnt mention them in the criteria. For a long time the only people with the hardware necessary to do this were the larger carriers and backbone providers, however these days it seems every small to medium sized last mile isp can get their hands on the hardware necessary to degrade the connectivity of the internets killer application on an idiot executives whim.

Count on one thing: Until widespread implimentation of bulletproof encryption things will only get worse as these companies misplace blame and attempt to make the same kind of profits when the world has changed.
I'd love to see how your bullet proof encryption were to get around an ISP that allocates a low priority to all consumer traffic coming from CMTSes and DSLAMs. Presumably you can encypt your way around the CoS information the ISP would set on your packets as they traversed their routers. Maybe you could pop your own MPLS labels onto the traffic so that the nasty ISP can't place labels on there with low CoS.

Whether you like it or not, and you clearly don't, it's not your network you connect to, it belongs to your ISP or their provider and they have every right to set the terms on which you use their network. That's all you buy, the right to use their network with their conditions. If you don't like it go elsewhere.

mikef1
Mike
join:2004-10-28
Littlestown, PA

mikef1

Member

just a short term fix

If enough people start using bit torrent with encryption then the majority of the traffic will be encrypted. If the ISPs are using decent packet shapers they will then just prioritize all encrypted traffic to the lowest level.