Anti-throttle

[bjs]

My ISP has had a network traffic management in place for a long time. For download it is somehow transparent (if you pass their peak time limit they cut your speed down) and I have no problems with it. But recently I notice that their UPLOAD throttle is quite annoying. During certain time of the day, I could not get any near to my upload line speed! I tried the encryption/uTP settings in uTorrent but it doesn't have any effect. It looks to me they use some intelligent methods to recognise the traffic patterns and then decide to throttle it or not.

There is so much information on p2p traffic shaping on the internet, so I wonder any experts here can point out a few technical papers that are relevant to my problem? Or advise if there are any effective ways of anti-throttling? Many thanks in anticipation!

[anon]

I tried the encryption/uTP settings in uTorrent

Does this mean you've tried bt.transp_disposition=10?

[bjs]

I have been using 15 - it should be quite a while ago after I read quite a lot discussions on it. Now I changed it to 10 as you suggested, but no immediate improvement. I will give it a go for a little longer to see what happens.

Assuming your theory is right, perhaps I should set it as 14 as my ISP doesn't play the dirty tricks on downloading. Actually their download policy is very fair to me: a simple limit and if you are over it then your speed is cut.

# 1 – allows uTorrent to attempt outgoing TCP connections
# 2 – allows uTorrent to attempt outgoing uTP connections
# 4 – allows uTorrent to accept incoming TCP connections
# 8 – allows uTorrent to accept incoming uTP connections

[anon]

Assuming your theory is right, perhaps I should set it as 14 as my ISP doesn't play the dirty tricks on downloading. ...

# 1 – allows uTorrent to attempt outgoing TCP connections
# 2 – allows uTorrent to attempt outgoing uTP connections
# 4 – allows uTorrent to accept incoming TCP connections
# 8 – allows uTorrent to accept incoming uTP connections

Outgoing connections do not equal upload

[n4overclock]

i have the same problem except they don't use constant p2p throttling they limit download at about 4mb/s after midnight and something like 6kbps before that ..when im using a vpn i instantly get over 10mbps

a temporary free solution for you would be using this Swedish vpn provider https://www.relakks.com/mypages/trial/ its quite fast but you should be careful using it on a valuable tracker ..

[anon]

a temporary free solution for you would be using this Swedish vpn provider https://www.relakks.com/mypages/trial/ its quite fast but you should be careful using it on a valuable tracker ..

Does it work right? Last time I used their trial service it disconnected regularly.

[n4overclock]

i have around 70 ms ping to their gateway server and it work wonders.. the only problem i had once is it almost got me banned from btn so now i only use it at rush hours ..

[bjs]

Outgoing connections do not equal upload

Oh, I see what you mean. :)
It seems allowing uTP only doesn't help in my case. Actually even by allowing both TCP and uTP, my traffic is mostly from uTP connection - I guess uTorrent prioritise uTP over TCP and perhaps most uTorrent users with a slightly newish version would end up with more uTP traffics.

@n4overclock, thanks for the advice. I will give it a go. But I am a little worried that the constant country/IP changes may cause problems for some trackers.

[n4overclock]

your best free bet fighting this is deluge using socks v5 on dht and peers only not the tracker.... i don't have time to make a tutorial about this but it got me around 8mbps up from around 7 kbs DL when i was testing on one of asiatorrents

[anon]

SOCKS proxies are nice, the problem is they make you unconnectable.

[n4overclock]

SOCKS proxies are nice, the problem is they make you unconnectable.

im using my real ip for browsing and announcing to the the tracker but the peer connection and dht network goes trough the proxy it some how shows connectable on the peer list for the tracker..

---------- Post added at 05:15 ---------- Previous post was at 03:29 ----------

encryption enabled (not forced) socks5 ON



encryption enabled (not forced) socks5 OFF



even if i force encryption with utorrent and deny legacy connections its still the same results..

[bjs]

im using my real ip for browsing and announcing to the the tracker but the peer connection and dht network goes trough the proxy it some how shows connectable on the peer list for the tracker..

Hmm... I am not sure if would be connectable to your peers even when it shows so on the tracker as they are certainly going through different routes. Actually I don't have problems with downloading as my ISP doesn't throttle it. My concern is uploading, for which perhaps connectability and incoming connections are more important.

Thanks for the advice. I will have a try.

[shoulder]

im using my real ip for browsing and announcing to the the tracker but the peer connection and dht network goes trough the proxy it some how shows connectable on the peer list for the tracker..

Hmm... I am not sure if would be connectable to your peers even when it shows so on the tracker as they are certainly going through different routes.

So it is.
As your announcing with your real ip, the tracker checks your_ip:your_port, which isn't influenced by the proxy used for peer connections.

even if i force encryption with utorrent and deny legacy connections its still the same results..

That's because it's possible for ISP to identify encrypted bittorrent traffic as such.

[n4overclock]

That's because it's possible for ISP to identify encrypted bittorrent traffic as such.

how hard is it for popular clients developers to upgrade for something a little bit more strong aka ccmp instead of rc4

[anon]

My concern is uploading, for which perhaps connectability and incoming connections are more important.

Definitely. A VPN with port forwarding or dedicated IPs would be best here.

how hard is it for popular clients developers to upgrade for something a little bit more strong aka ccmp instead of rc4

Protocol encryption is just a basic workaround.