Jump to content

! Upload Range Instead of Static Limit


Guest

Recommended Posts

Hi,

I was just thinking that it would be helpful if µTorrent would allow the user to set a range for the upload limit instead of setting a single value.

One way that ISPs detect traffic is to notice when a user is uploading a constant stream. This is fairly reliable because unlike the download rate which fluctuates a lot, the upload rate is usually maxed out by the cap (whether hardware or software) since it's almost always much lower than the download limit. Thus, it's very easy to notice this behavior (just look at a bandwidth graph!)

For example, if a user is uploading at a near constant 20kB/s when they've got a max of 40kB/s, it's obvious that they've got some kind of upload going, but it's capped. There aren't too many legitimate reasons for that (well there are, but P2P is vastly more likely). Then BAM! They throttle you (bandwidth wise for now, physically later).

If however, the app allowed you to set a range, say 15-30kB/s, then the app would alter the limit on a regular basis (preferably that can be tweak-able by the user as well), so that the upload rate fluctuates more like the download rate does. This way, it won't be so obvious that something's going on, and they'll have to use their other tricks to detect P2P activity (then maybe they'll stop throttling legitimate uses that exhibit this behavior as well.)

Link to comment
Share on other sites

That's not the point. I'm not talking about bandwidth limits, I'm talking about P2P throttling. One method of detecting whether traffic is "normal" or P2P is to detect if there is some capped but constant stream coming out. If someone using µTorrent has a steady 20kB/s upload, then it's pretty obvious that they are doing something other than say uploading their website to a host or emailing a video to a friend. If however, the upload stream fluctuates like the download stream does, then that method is useless to them as a detection tool.

The encryption thing doesn't work anymore. It was good for a while, but then ISPs caught on and started traffic shaping. They don't care what's inside a packet anymore, so encrypting it means nothing. They look at the patterns to detect P2P usage, and varying the upload limit is one way to break the pattern and make the traffic look more random.

Or perhaps you have better anti-throttling/anti-pattern tricks in the works?

Link to comment
Share on other sites

Patterns are going to be VERY hard to hide, even with encryption.

20+ incoming connections to the same port, check!

Outgoing connections on ports between ~1000-5000 to ips on random ports, check!

UDP and TCP traffic on the same incoming port, check!

Short connections (handshake, pass a little data, drops because it's a seed) or very long connections (for downloading/uploading lots of data), check!

Encrypted and unencrypted packets on the same port (because even if you're encrypted, some dumb BT client will probably still send you in-the-clear packets so your ISP knows what that port is doing), check!

...sounds a lot like file-sharing of the type BitTorrent uses to me. :P

There's lots more details that can flesh out how BitTorrent acts on a packet-level. Even if you can't READ the packets, there's probably small communication packets that will stand out from larger data (piece of the torrent files) packets. Padding packets with extra bytes to try to "hide" activities won't do much except waste bandwidth.

One huge fault of many file-sharing programs is default settings aren't reasonable. By default, I mean the settings used if NO settings are changed from installing. Probably over 20% of everyone running µTorrent use default settings and are none-the-wiser. These are people using UNLIMITED upload speed setting. I can understand ISPs not liking that! Or those that do read a little and just rush through use Speed Guide settings using their DOWNLOAD bandwidth numbers. Or they try to manually enter really strange combinations of settings.

The tweak-happy people willing to read here and better yet register to post something...are a very tiny minority.

So even *IF* this feature helped, setting it in a useful manner would require so much research that it'd be beyond basically everyone -- me included!

Link to comment
Share on other sites

I'm not sure what your definition of useful is. I was thinking much more simple than that: you could just enter 17-25 instead of just 20. Anyone who bothers to set it to some value could easily enough add and/or subtract a few K to create a range.

Link to comment
Share on other sites

But by that logic, then encryption shouldn't have been included either. In fact, no attempt should be made unless you can cover up everything at once which obviously won't happen. The only way is to tackle one sign at a time which is what I proposed; covering this sign, and then moving on to the next.

Link to comment
Share on other sites

  • 2 months later...

EDIT: It appears this has already been discussed (e.g., http://forum.utorrent.com/viewtopic.php?id=22686 ), but maybe there's some ideas below that are new.

.............................

"Burst uploading" would be a feature designed to thwart anti-p2p ISPs which throttle their user's upload bandwidth when p2p trading is detected.

Details in a moment; first an anecdote: I subscribe to Comcast, which is a quasi-monopoly in my area. I am theoretically able to upload at a maximum rate of 256kbs, but will be throttled to 40-45kbs after about 30-45 seconds of very fast uploading.

I Spy, With My Little Eye, A Chink In Their Armor: Today, I was trading two torrents, one already established and which I manually choked to no more than 20kbs upload, and the other, a new torrent being initially seeded with 512k pieces and no upload rate restriction. For several hours, there were a small handful of peers in the new torrent who would alternately take pieces at very fast rates, and finish receiving them from me before Comcast noticed. Since I was initially seeding, there were regular pauses between piece sends. uTorrent's Speed graph looked like a shark-toothed saw-blade with peaks to 200kbs and valleys where it based at the 20kbs of the other torrent. I was, of course, highly pleased with this situation while it lasted, since the average was well in excess of the normal 40kbs....but eventually more peers showed up, uploading became continuous, Comcast noticed, and I got throttled. I was able to successfully stymie them a couple of times by stopping and restarting the torrent and/or uTorrent, but eventually had to give up.

==//==

The way automatic "burst uploading" could be (easily, methinks) implemented in uTorrent: In Preferences, under Connections (or wherever appropriate, such as the Bandwidth Allocation feature), there would be a field with the following values:

* max upload rate -- (identical to the current "Maximum Upload Rate" setting)

* max upload burst -- (a second kbs setting, equal or higher than MUR)

* burst duration -- (value, in seconds, of how long burst speeds are permitted)

* burst pause delay -- (minimum value, in seconds, between burst sessions)

* lock burst to initial seeds -- (yes/no flag)

Defaults: MUB = MUR, and burst duration = zero (so the feature is "off" by default). Savvy power users, however, will have a handy tool to massage their bandwidth -- In my case, I'd set burst to Unlimited, duration to 10 seconds and delay to 10 seconds, and lock burst mode to initially seeding torrents only.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...