Jump to content

Debate over Protocol Encryption


ev0|

Recommended Posts

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.

I would just like to bring this post to everyone's attention because kurahashi makes some very valid points. In my eyes, he is absolutely right and I couldn't have put it any better myself. :)

The current situation is, in my opinion, far from economical.

Basicly there's a 50% chance of getting an encrypted transmission, depending who initiated it (the PE-enabled or PE-disabled peer).

Please, consider changing this.

Also, from what I've read from developers and I can confirm this myself (p4 2,6ghz), the encrypting takes only very little extra cpu resources.

Link to comment
Share on other sites

  • Replies 105
  • Created
  • Last Reply

@Fredman, thanks for confirming that. :)

So, O.K., Chello restricts the BitTorrent protocol traffic, but I as a user on an ISP that does not shape still need to "Enable" encryption on my side in order to be able to download, or 2-way exchange, data from the affected Chello user because if I don't, when *my client initiated the connection* (outbound connection from "Disabled" to "Enabled" user) then encryption won't be used and so the transfer will be shaped.

I understand that if the Chello user were to initiate the connection into me then the transfer would be encrypted, irrespective of whether I have "Enabled" or "Disabled" set, but if my "Disabled" client initiates connection to the "Enabled" Chello user, then the connection is not going to be encrypted, and therefore shaped.

That seems logical enough to me, and possibly a good enough reason for NON-SHAPED users to want to set their clients to ENABLED, though it appears some people disagree... :-s

*LOL* :D

Link to comment
Share on other sites

@Fredman, thanks for confirming that. :)

So, O.K., Chello restricts the BitTorrent protocol traffic, but I as a user on an ISP that does not shape still need to "Enable" encryption on my side in order to be able to download, or 2-way exchange, data from the affected Chello user because if I don't, when *my client initiated the connection* (outbound connection from "Disabled" to "Enabled" user) then encryption won't be used and so the transfer will be shaped.

I understand that if the Chello user were to initiate the connection into me then the transfer would be encrypted, irrespective of whether I have "Enabled" or "Disabled" set, but if my "Disabled" client initiates connection to the "Enabled" Chello user, then the connection is not going to be encrypted, and therefore shaped.

That seems logical enough to me, and possibly a good enough reason for NON-SHAPED users to want to set their clients to ENABLED, though it appears some people disagree... :-s

*LOL* :D

Ahh finally! Someone's got it all pinned down! Thats exactly what I've been trying to say/prove in the last couple of posts I've made. (I am also a chello.nl peer btw, if you want to do any testing?)

It seems to work the exact same way for Rogers and other shaped peers/ISP's.

Not only shaped users wuold benefit from PE Enabled.

But it also applies to non-shaped users, because as long as you have PE Disabled, we (shaped peers) are sending you shaped traffic! (slow upload from our p.o.v... slow download from yours)

Link to comment
Share on other sites

@Falcon4

Yes, I am aware of your previous posts in the other thread and I already knew that you do understand the situation and have been trying to clarify.

edit: Sorry, you didn't provide any false information. I misread your post. :(

I just felt uusr pinned down exactly the situation as it is right now in his post above so that's why I quoted him in specific.

Link to comment
Share on other sites

Ahh finally! Someone's got it all pinned down!

I wouldn't go that far, I barely know what I'm talking about myself... :P

Thats exactly what I've been trying to say/prove in the last couple of posts I've made.

Yeah I see that. I think you summed it up well by saying "Basicly there's a 50% chance of getting an encrypted transmission, depending who initiated it (the PE-enabled or PE-disabled peer)." This is what I think too.

Not only shaped users wuold benefit from PE Enabled.

But it also applies to non-shaped users, because as long as you have PE Disabled, we (shaped peers) are sending you shaped traffic! (slow upload from our p.o.v... slow download from yours)

Agreed. I'll more-than-likely be configuring my own uTorrent client to always run as "Enabled" and "Allow incoming legacy connections" here for these reasons.

Testing sounds like a good idea!! .. That way we can prove as shaped (chello.nl) users that it only works with both clients set to enabled.

I think I've already proved it to myself here during the tests I ran here a couple of days ago (with the Chello user on the PocketLinux torrent) though I could test it some more if needed.

Just as splintax said in that thread... "Gah. Why is it that people find PE so hard to understand?"

I don't know but there are quite a lot of different combinations of settings and states to take into consideration I think (Enabled, Disabled, Forced +/- Allow Legacy versus inbound & outbound connections, etc, etc). ;)

Link to comment
Share on other sites

How about the shaped connection replying encrypted if it senses a µTorrent version that supports it? Then that version could then always use encryption with that connection.

It shouldn't matter who intiates the connection, only that one can use encryption and the other side will follow suit if it supports encryption. The only exception to this is if force legacy mode is on or of course older versions (and different BT clients) that don't support encryption.

If one side is set to always use encryption and the other side is set to force legacy mode...then the debate should be:

1.which one overrides

2.or should the connection just be dropped?

Link to comment
Share on other sites

My idea about the whole situation is this:

In the final release there is no need for an option to switch between anything. It should be set to enabled and allow incoming legacy connections. That way everyone benefits from the PE without sacrifising anything.

This way encrypted, so non-throttled, traffic will be possible at all times with µtorrent and other cliënts using the same encryption. Still connections with peers using other cliënts will be possible as well.

Chello.nl throttles as you might know but offers uploadspeeds of 1 and 2 megabits. In the near future even more. So with PE enabled the whole world can benefit from these fairly high speeds. At this moment only chello.nl members benefit from them.

This seems to me as an even somewhat understated reason to have PE always enabled.

Why not? There are no drawbacks......

Link to comment
Share on other sites

My useless input is as follows...

as the bandwidth costs rise for them...

You're kidding, right? BW costs are falling, and will continue to fall.

illegal torrents

Careful there, torrenting is not illegal. Further, in my country (speaking of music alone) I am entitled to download music. I pay for that right through fee's when I (and any other canuck) buys media/hard drives... etc.

Right now Bram is interested in 'legitimatizing' BitTorrent as a means of distributing legal content and has been given a lot of money to do so. I don't think he wants anything messing that up. He's part of the whole corporate thing now, if he had any links to the community he'd understand that it is a real problem for a lot of people, and it's only going to grow.

And thats really it, isn't it? Soon (not soon enough) you will see major studio releases, TV shows.. and major bands release using the BT protocol. ISP's can whine all they want, but, they better get off theri a** or be left in the dust.

For just a little info on how badly the US has been screwed over by the teleco's, read here...

http://muniwireless.com/community/1023

I've been with my cableco over 25 years. They've made quite a bit of money off me. Now that I am finally, able to fully utilize what I pay for... they want to crap all over me?

Bah.. bah I say! :D

Link to comment
Share on other sites

@Tonne: The reason that it is an "option" is because some ISPs don't just throttle bittorrent packets and that's it, they throttle EVERYTHING at the slighest hint of a bittorrent packet. So basically, if one little bittorrent packet goes out from your machine, your entire connection is crippled to <5KB/s. This is why some need Forced and no incoming legacy connections.

-Ares

Link to comment
Share on other sites

Just incase some people are interested, here are my findings with the new µTorrent encryption, me and my friend did some tests from his Internet at college on campus...

Him using µTorrent Beta 1.4.1 421 and me using BitComet 0.61: About 6 kB/sec max

Him using BitComet 0.61 421 and me using BitComet 0.61: About 2-6 kB/sec max

Him using µTorrent Beta 1.4.1 421 and me µTorrent Beta 1.4.1 421: About 140 kB/sec max

All I can say is great work on the new encryption. Can't wait till it's out in final for µTorrent and Azureus! :D

Thank you!!!

Link to comment
Share on other sites

"Enabled" as a default may happen for 1.5, but not likely. I'd expect it with a later release. ludde doesn't want to unless there's a majority of PE-enabled clients out there.

That implies that there is a downside to "Enabled" - but the messages in this thread imply that there is no downside to "Enabled".

Does ludde feel there is a downside to "Enabled", and if so, what ?

NOTE that I see lots of utorrent 1.3 and even earlier ones in my peer lists for torrents, so if any official release version has "Disabled" as a default, then we will be seeing disabled peers using that version for months if not years. Many people take a "If it ain't broke, don't fix it" attitude toward updates - they don't do it if everything works fine.

SO, it would be better for ludde to decide what is best for 2007 and 2008, and put that default in the next version.

Link to comment
Share on other sites

"Enabled" as a default may happen for 1.5, but not likely. I'd expect it with a later release. ludde doesn't want to unless there's a majority of PE-enabled clients out there.

The question is: Does uTorrent "wants" to follow the herd, or lead it ?

It should be effecting the swarm by trying to make PE users - the majority, and not wait until they are...

Link to comment
Share on other sites

^Good point.

However, follow this very simple future thread:

noob 1: "Why does utorrent connect so slowly???"

noob 2: "Because everything is encrypted and you might be connecting to people that don't support it"

noob 1: "But why is it encrypted?"

noob 2: "Ask the people in [this thread]."

Being able to enable it for people that are "shaped" solves about 80% of their problems. Since most people are already connectable, the very fact that future µT versions will support encryption solves most shaping problems, since everyone will, in fact, basically have it on by default.

There's no real logical reason why we need to shove it down people's throats. If someone with it enabled tries to connect with someone disabled, they'll get it encrypted (BOTH WAYS).

This discussion really has been done to death. It should just be released with the CAPABILITY first, then later, after hearing people's feedback, see if it should be enabled by default in future versions.

It's that simple, really. ;)

edit: BTW, I just ended up upgrading one of my friends to the beta - just goes to show how short a range this beta has reached so far, so there's *really* not a good testing area right now. It needs to be released. Really. Seriously. :P

Link to comment
Share on other sites

^Good point.

....

This discussion really has been done to death.

I agree (about done to death...) . But it will be *very* interesting to see the "global effect" of fast-spreading new algorithm...

BTW - I wonder - how does Az (our partner in PE, remember?...) going to do this ? As a default ?

Also - you can always turn it off, right ?

Link to comment
Share on other sites

i was experimenting with bitcomet's encryption and i noticed 3 states of the feature

1. Auto

2. Always

3. Disabled

it's clear what 2. and 3. do.. what Auto does (i think so..) is starting to connect to peers with encryption disabled (super-fast connect) and downloads data.. in the meantime it offers encryption while it is downloading and starts encrypting data with certain peers.. in the result u connect as fast as possible and the encryption doesn't bother u.. if this is possible to happen ludde could even improve it - it makes no sense to offer encryption to ABC, bittornado, bitcomet or other clients which do not support utorrent's encryption..

Link to comment
Share on other sites

Is encryption started after you get peer's client ID? If not, than connecting non µT/Azureus without trying encryption first, would be impossible i think.

And if it would start connecting without encryption, it should connect ~50% of max peers per torrent and then start connecting only encrypted connections (like now "Enabled" works).

Link to comment
Share on other sites

Tried to sum those 3 pages up:

SHAPED USER: INCOMING, encryption decided by other side, ALWAYS ACCEPTED

OUTGOING, encryption enabled to avoid isp shaping

NORMAL USER: INCOMING, encryption decided by other side, ALWAYS ACCEPTED

OUTGOING, encryption probably disabled.

SHAPED -> NORMAL - Fine, encrypted session.

SHAPED -> SHAPED - Fine, both use encryption.

NORMAL -> SHAPED - initiates a non-encrypted session, can be detected by ISP.

NORMAL -> NORMAL - true unencrypted connection, visible to ISP.

Two points about NORMAL -> SHAPED:

1) Can avoid ISP detection for the SHAPED USER if legacy is turned off?

(the question is if the ISP can still notice the header even if the connection was refused)

2) When the ISP for the SHAPED user throttles his connection, the NORMAL user suffers aswell. Should NORMAL users enable encryption themselves, then?

One point id like to get agreement on, is that enabled ALWAYS is ONLY for heavily shaped users (those whose ISP totally DROPS connections when detected, etc).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...