Debate over Protocol Encryption

[osm0sis]

if you read through the above, it will tell you that the difference is that µT and Az are encrypting everything and that the header-only method isn't good in the long run because ISPs could still more easily detect it. And yes, BitComet's was closed so it only benefited users of BitComet with other users of BitComet, which isn't very fair. the joint effort between µT and Az in creating a spec is an excellent development. please try to read a bit more thoroughly next time.

edit: hotrice, this isn't a feature request thread... feature requests belong in the "Feature Request" section of the forum. what's THAT about?

[Firon]

Azureus lets you choose between the handshake and all traffic, µT does all traffic and does not let you choose.

hotrice: it's off by default and will always be off by default, BUT, the only thing that you can control is outgoing connections. All clients can accept incoming encrypted connections, and it's not possible to disable this, so shaped users can turn it on and still be able to connect to everyone that has a client with PE.

[Falcon4]

Please make encryption an option that is on by default. All of the major Canadian cable operators have throttled Bittorrent traffic.

If it's "on" for you, then whenever possible it'll make connections using encryption. In the meantime, many people in the US don't have a problem with traffic shaping (I run a web server, hostfile.org (among others), off my DSL at home), so encryption would be rather useless for me. However, µTorrent still supports encryption and will encrypt data if requested by the peer (you).

So, basically, so long as you're doing outgoing connections with it "enabled", it'll always be encrypted to whoever supports it.

[hotrice]

Thanks Falcon4. Is there any reason why I would want to have Encryption enabled always?

BTW, I got encryption working with one torrent only so far. Encryption is the solution, but we need more people using clients that support it.

[Firon]

hotrice: if you are shaped, then you should set it to Enabled. If you're really heavily shaped and can only use encrypted connections, then you should use "Enabled, always" and turn off "Allow incoming legacy connections."

If you are not shaped, you should leave everything at default, because shaped users can already connect to you with encrypted connections.

[hotrice]

Great I am shaped, my ISP throttles my uploads to about 12 kB/s. I guess the best option for me is to leave encrytion enabled and allow legacy connections.

[Falcon4]

The debate about allowing legacy connections is that some ISPs may get smart (or stupid) and note one true incoming BitTorrent stream, and realize what that port is being used for, and throttle it. If all (and I mean ALL) traffic is being encrypted, they'll never find out.

However, if they only slow down known BT traffic on a packet by packet (non-learning) basis, then simply "Enabled" and "allow legacy connections" is a great setup.

[ev0|]

The (only) option at the moment is to allow legacy connections and enabled (with the fallback to non-enabled) because unchecking and enabled, always means you'll only ever connect to clients that support encryption which is hardly ANY at the moment, although hopefully this will change soon.

[kurahashi]

Let me vote here for making encryption option default.

Imagine yourself, you are using torrent shaped connection. You are - of course turning on encryption enabled, but what about legacy incoming one?

1. turn it off

Ok, we are heavily shaped, legacy BT connections won't do anything for us.

This is bad, because all legacy connections will be rejected - including those incoming from peers supporting encryption, but having it disabled - because it is set to default.

True, we should be able to connect to such peers when we reinitiate the connection, but still it doesn't sound to economical to me (rejecting its connection attempt only to initiate ours? and what about reconection time?) Finally, if the remote peers are NATed we won't connect with them ever

2. leave it on

Again, what about peers supporting encryption, but having it disabled by default?? Well, if we are lucky it will be our client to initiate connection and it will be ok, but otherwise... (or if remote peer is NATed) we'll connect unencrypted and our transfers will be shaped by ISP. Disaster

Of course, all problems would be resolved by leaving encryption outgoing enabled.

Please, consider this. The power of the default settings is huge. Lots of people never ever bother to check their settings, neither they are interested what encryption means - all they really want is to turn it on and download "teh stuff". Unfortunatelly, the fate of the torrent shaped networks users lies also in such fire-and-forget users' hands. So what we leave default is very important because it will mean majority of uTorrent clients settings throughout the world.

And what are the cons about leaving encryption enabled, really? A little bit CPU more. I know, it doesn't fit too good to the uTorrent marketing And this "little bit" could be not so little when suddenly there will be many encryption transfers... but on the other hand: uTorrent is popular but is still much behind Azureus and BitComet. How many people are using uTorrent? 10%? 15%? I'm not suspecting to see too many encryption connections in the nearest future even with the enabled encryption as default anyway.

[rafi]

I'll probably be the only one to think so, but in my opinion the default for the PHE should be "enabled".

The reasoning behind that is this - a good test for it (to see it's effectiveness) - is when MANY peers are using this. If we (the users) will volunteer to put it on - this check will be feasible and effective.

So I suggest to do it this way - in the first "official" release - if this is set to "disabled" have a pop-up dialog ask the user if he "permits" this option to be set to on, and explain a bit why.

What do you think ?

[hotrice]

Well leaving it disabled is just fine since the client still can receive encrypted connections. The problem with shaped connections is the outgoing stream, so why have it enabled if you are not being shaped since there's more overhead with encryption.

[uusr]

I'm not sure about leaving it disabled being the best option to be honest. The reason being that I had a quick play about here with this client testing out the 3 encryption options to note differences/etc and seemed to notice something a bit odd. I caught a link in a thread here that had a 'linux' torrent up for testing and such so I gave it a try. I was alternating utorrent between "Disabled" and "Enabled" and noticed, specifically, a chello.nl client, also running 141B, was apparently showing quite a big difference in its upload rates to me depending on how I had utorrent configured. Now my ISP does not run any protocol-level traffic shaping policies that I'm aware of, and I've not heard of Chello shaping traffic personally, so which party (if any) might be to blame I really don't know.

This brings something into question though with regards this 'chello' user. When I had utorrent set to "Disabled", and that user uploaded to me, the transfer rate was pretty weak, mostly from about 5-20KB/s, though generally nearer 5KB/s, with the transfer never indicating an "E" flag to suggest the comms were not encrypted. But, everytime I set utorrent to "Enabled", then started transfer again, this same user's rate would shoot right up to 50KB/s with utorrent showing "E" to indicate encryption was now being used. I did this test about 8 times I guess, flicking between "Disabled" and "Enabled", and the result showed the same thing everytime. Strange coincidence? Possibly...

My point is that even though both sides were running 141B, whenever I didn't force encryption by enabling it, it appeared that client never utilised encrypted comms at all and consequently it appeared *something* influenced the transfer rates, whether that be my ISP, or theirs (or some other oddity). Of course this wasn't a serious test at all, though it causes me to question whether I should run utorrent set to "Enabled" by default simply for the fact that there's a good chance you do not know exactly which ISPs are shaping to any degree. I'm sure folks are aware that ISPs often try their damned hardest not to let their subscribers know about traffic-shaping for reasons that when it becomes known beyond a reasonable doubt the subscribers tend to kick-up a lot of fuss. So, sure, there are ISPs like Rogers and Shaw and Plusnet and OOL that are quite obvious shapers, but who knows who else is shaping but not to such an obvious degree?

Personally I'm going to run with uTorrent set to "Enabled" for time being as at the moment I'm thinking this might be the better option to use as a rule.

[rafi]

Well leaving it disabled is just fine since the client still can receive encrypted connections. The problem with shaped connections is the outgoing stream, so why have it enabled if you are not being shaped since there's more overhead with encryption.

Well, as I understand the client WILL initiate non PE connections to ANY peer. So if this peer's ISP IS shaping him - we can detect it's listening port and may start shaping ULs. So, enabled might serve for the sake of the opposite peers, no yourself.

and uuser - I agree with your conclusion, although I did not notice any difference in speed as you did.

[Switeck]

Now my ISP does not run any protocol-level traffic shaping policies that I'm aware of, and I've not heard of Chello shaping traffic personally, so which party (if any) might be to blame I really don't know.

There is a 3rd possibility which you may not have heard of...

AT&T is throttling alot of p2p traffic that passes through their backbone lines. We inadvertently discovered that in BearShare beta-test, with ISPs that officially stated they DID NOT throttle...yet people on them were having immense trouble running file-sharing programs, unless they found someone else on the same ISP.

End-to-End encryption is about protecting us from the man-in-the-middle. Our ISPs can stills screw with us, but it's a game they're better off not playing to the fullest. Because at the end of the day, biting the hand that feeds you...even if it only feeds you reluctantly...will leave you even more starving than before.

It will take ISPs a major upgrade to their shaper software and hardware to defeat the level of encryption µTorrent has. However, as I've already said, they don't need to if the encrypted traffic runs on the same port as the regular traffic:

ISP senses one "in the clear" BitTorrent packet, BAM! that port gets crippled to dial-up speeds!

Outgoing encrypted packets would of course be on random ports, so lots of traffic would not be shaped. But your download speeds would be, as that's all arriving on a single port -- the one which will be showing unencrypted BitTorrent packets.

Alot of the reasons for packet-shaping are not as applicable today. Many of the ISPs have grown so huge that alot of the file-sharing traffic is staying inside their intranets. They typically don't have to pay Tier-1 backbone traffic costs for that. For cablemodems, the trunk line that carry 5-100 cablemodems on it back to the ISP's gateway are often rated for 100 Mbps or more. For local traffic that doesn't go through the gateway, the cablemodems could run at max speed and not overload the lines.

At the gateways, the distinction between cable and ADSL ends. They're both typically tied into T-3/OC-3 lines, with an oversubscribe ratio somewhere between 5 and 100 -- meaning they only have enough bandwidth for 1%-20% of everyone running their connections at max. And it is there they suffer when we use p2p file-sharing with upload set to "unlimited". We suffer too with low download speeds when we let upload run "unlimited", but all the lost incoming data ISPs probably have to pay for twice or more.

Something I've always hated about various types of file-sharing is the connection swarm I see hitting my router days after I stop running a file-sharing program. Establishing a connection, however brief, probably has a cost for an ISP. With 100's or even 1,000's per minute from file-sharing, those fractional costs add up.

Fewer and faster connections (such as 10 connections at 10 KB/sec each) for file-sharing wins out over 100's at <1 KB/sec speeds. The trick is getting everyone to play that game. Then ISPs wouldn't see the obvious 100's of connections going to our ips per minute. Even multiplayer games would be comparible. So to would be web surfing, especially when you hit a web page full of unblocked off-server banners -- they all load from separate ips almost simultaneously. This is the reason I suggest 4 upload slots even for fast connections...just remember to allow additional upload slots if <90% max speed.

[Brisk]

I'm a Chello.nl user. The things Switeck wrote sound formiliar. From chello <-> chello no speed probs. And Chello say they don't throttle BT traffic. So maybe they use throttled backbones.

I'm using 1.4.1 BETA 419 atm with Encryption enanbled,always and get really good download speeds (@ privat tracker 1MB/s+). But the upload speed is still bad. One time i had my max upload (220kb/s) to another µTorrent/141B user that had Encryption enabled and wasn't another Chello member.

I have Allow legacy incoming connections on. Do you think this effects my upload speed? When i turn this option off, my client allmost doesn't connect to any other clients. Is this because they have encryption disabled or a client that doesn't use encryption?

As you see i'm not an expert in this...trying to learn evryday tho....

Brisk

[splintax]

Well leaving it disabled is just fine since the client still can receive encrypted connections. The problem with shaped connections is the outgoing stream, so why have it enabled if you are not being shaped since there's more overhead with encryption.

Yep, I don't know why nobody seems to be able to understand this.

Can I just confirm that if a user has encryption disabled, and initiates a connection with a peer who has it ENABLED, will that connection be encrypted? That is, will µT tell that peer that it does support encryption and use it if the peer wants?

[Ares]

@splintax: From what others have told me, no, a disabled client initiating a connection with an enabled client will NOT be encrypted.

That's why you have to uncheck "allow legacy incoming connections" if you really want to "force" encryption. If you "force" it and leave that checked, both non-µTorrent clients and µTorrent clients with encryption disabled will connect to you without encryption.

[DreadWingKnight]

both non-µTorrent clients and µTorrent clients with encryption disabled will connect to you without encryption.

Current Azureus betas also support a compatible encryption system with µTorrent. Just for the record.

If you uncheck the "Allow legacy incoming connections" clients that don't support a compatible encryption system won't connect to you at all in either direction.

[Ares]

Er, yeah, I meant to include Azureus lol

If you uncheck Allow Legacy Incoming Connections, and have encryption set to Enable, but not "Always", then you will still make unencrypted outgoing connections to non-encryption-supporting peers. The only way to block out non-encrypted peers completely is Enabled, Always and uncheck the Allow Legacy Incoming Connections.

[Ares]

Okay, if I'm talking about YOUR settings and YOUR µTorrent, here's what happens:

*Disabled + Legacy ON = unencrypted outgoing | unencrypted and encrypted incoming

*Disabled + Legacy OFF = unencrypted outgoing | encrypted incoming (I don't know why this is an option)

*Enabled + Legacy ON = encrypted and unencrypted outgoing (favoring encrypted) | encrypted and unencrypted incoming

*Enabled + Legacy OFF = encrypted and unencrypted outgoing (favoring encrypted) | encrypted incoming

*Forced + Legacy ON = encrypted outgoing | encrypted and unencrypted incoming

*Forced + Legacy OFF = encrypted outgoing | encrypted incoming

So, for example, "Enabled + Legacy ON" means I would make encrypted and unencrypted outgoing connections, and receive encrypted and unencrypted incoming connections.

So, to further explain Splintax's question, if I am "Disabled" then I would make an OUTGOING UNENCRYPTED connection to him, and as long as he has "Legacy ON," he would accept my UNENCRYPTED INCOMING connection. If he had "Legacy OFF," then he would completely ignore my UNENCRYPTED INCOMING connection, and the only way we would connect is if he made an ENCRYPTED *OR* UNENCRYPTED OUTGOING connection to me (it would be INCOMING to me). Sorry if that got confusing lol.

Hope this clears it all up (and I also hope I'm right Back me up, Firon? Or correct me?)

EDIT: Changed references to "Enabled, Always" to "Forced" to match the latest beta

-Ares

[hofshi]

This is as clear as it gets. Thanks Ares.

Edit: might be a good idea to copy the post by Ares and paste it into the FAQ. Personally I think that the FAQ is clear enough in its present form, but there were many questions regarding this issue in the forums.

[uusr]

Well I ran some more tests today between the "Disabled" and "Enabled" options against the Chello seeder I mentioned in the post above. Here's how it went;

Both me and the seeder are running uTorrent 141B. I don't know what the remote Chello has there settings set at but I would guess they have it set to "Disabled".

I see a distinct discrepency between the 2 Enabled/Disabled modes here. If the Chello user uploads to me when I'm set to "Disabled", the connection flags indicate "D H" and the transfer rate appears crippled. If the Chello user uploads to me when I'm set to "Enabled", the connection flags indicate "D HE" and the transfer rate is very good.

To confirm this I ran the test a number of times and took snapshots of a bandwidth graph application I had running (Netlimiter). Below are the results to the simple test and a screenshot showing the graphing;

disable    16~    D H
enable    58    D HE
disable    16~    D H
enable    62    D HE
disable    12~    D H
enable    32    D HE
disable     9~    D H
enable    36    D HE

The above just shows how my uTorrent was configured, average transfer rate (guestimate by me) and transfer flags.

Here's a combined image of the Netlimiter bandwidth graph;

http://img146.imageshack.us/my.php?image=graph2ze.gif

Hopefully the image speaks for itself. The thing is whether it might be better for a user to run uTorrent with encryption set to ENABLED rather than DISABLED because as this test shows running as DISABLED between 2 141B clients does not invoke encryption normally so it leaves the potential for the transfer to be manipulated by the network operators. I do not know who in the network chain might be responsible for the (imo obvious) shaping but it appears there is at least some shaping occurring somewhere. If I were to run uTorrent set to DISABLED by default then it would allow this shaping to continue.

What seems like the sensible choice then? Enabled or Disabled?

BTW if anyone's interested and would like to test things for themselves then hit-up the "PocketLinux" Torrent @ http://linuxtracker.org/torrents-details.php?id=1067 and look for the Chello seeder.

[uusr]

@ Switeck

Yeah, that's an interesting possibility; that backbone providers could be manipulating traffic on a per-protocol basis. Maybe they're detecting protocol types and routing through different pipes accordingly, like routing peer-to-peer traffic over non-critical & often congested pipes, etc.

I think it's difficult to say who exactly might be responsible a lot of the time.

[boo]

ya, Ares explaintion of the encryption options should be added to the FAQ

[Fredman]

Well I ran some more tests today between the "Disabled" and "Enabled" options against the Chello seeder I mentioned in the post above. Here's how it went;

Both me and the seeder are running uTorrent 141B. I don't know what the remote Chello has there settings set at but I would guess they have it set to "Disabled".

Trust me . .every chello.nl user with µtorrent 141b has set it to ENABLED. I have a 20/2 mbit conn. which I'm paying a lot for, but Chello shapes my p2p traffic most of the time to 30 kb/s down and 15 kb/s up MAX. I've tested the enabled / disabled thing with a good friend of mine a lot of times. Only with mine and HIS settings to ENABLED the transfer speed went up to 200 kb/s.

Greetz Fredman