Jump to content

Torrent-friendly ISPs frown at uTorrent and uTP


tim716

Recommended Posts

unfortunately, not all ADSL users are rich enough to afford this nice ~6-10M:1Mbps upload connection . Some have to do with a modest 1-2.5M:256Kbps upload connection, *AND* can give uTorrent only 25-35K of it.

Those users were (and still are) doing fine with largest packets using TCP, and can still do find using largest packets with uTP. It's only a matter of a design decision and possibly a bit less congestion control.

*AND* uT did try to partially "take care" of users with low caps in this release:

-- 2010-05-13: Version 2.0.2 (build 19648)

- Change: disable net.calc_overhead by default to improve speeds for users with low caps

It's time to improve speed/PPS for them too when using uTP and it's speed limiter as well!

Link to comment
Share on other sites

  • Replies 90
  • Created
  • Last Reply

That may look harsh, but... Every ISP using SOHO-grade hardware on their backbones simply must think it over and start upgrading its network or sell it to someone who can cope with the upgrade. If you can't provide the service... hell, just don't provide it. Give this opportunity to the one who can.

I agree that there was issue with <576 byte frames with UtP (576 is obviously minimum MTU and there is no need to go below), but it's currently fixed.

Those guys filtering UtP are just plain pain in the *ss for users, and for themselves too. I do think that UtP needs some simple protocol obfuscation, like XORing all the headers with a prefix 32-bit key. This will spoil most of the filtering attemps.

Link to comment
Share on other sites

There are facts that you, ALexAT83, cannot just ignore. uTP is not just there, it has a purpose - improving congestion. I'm not sure I've ever seen a test/post showing that it does that. Now, leaving this aside, there is a price we all pay - higher PPS and higher overhead. This means that equipment (poor as it is) suffer, but also - you just wait for your downloads to complete - longer than with TCP!

>but it's currently fixed.

It's not. Using an upload speed limit (for lower caps packages) - you get back to 215 bytes UDP packets (at the same time TCP is still using 1500B size) . Using more upload slots (same total speed) - you get even higher overhead . uTorrent is also not obeying the setting for minimum uTP packet size. Do I want to pay this price ? Is this what you call fixed ? I think I don't!

Most are not bugs, it's by design, and there is a need to improve that design.

Link to comment
Share on other sites

A D-Link DIR-300 router is one of the worst common routers on the market. It is below what should be acceptable performance and is only fit to be mentioned when something surprisingly works on it.

No, really you are wrong. DIR300/NRU uses powerful Ralink RT305x SoC (MIPS at 380MHz), and I don't know what means 'fast router' for you if this is 'slow'.

And there are many other routers (and ADSL modems in non-bridge mode) that are much weaker, but are common for user's usage. For ex., DIR-100 (). Or miscellaneous ADSL routers like Huawei, D-Link 2500, etc.

And I already mentioned above about TCP fragmentation offloading, which really helps for SOHO routers to transfer tens megabits of traffic even with weak CPU. For uTP this feature, of course, is absent - so load on CPU will be highly increased.

AlexAT83

If you think that you can start war, and war can be winned by you - you are wrong. If user's action will be qualified as (D)DoS attempt (which really does uTorrent 2.0 at February - when pps grows by more than 30% during two weeks, and even our country-wide top-provider, with expensive Cisco hardware has big troubles with speed at evening prime time) - provider will use radical methods. And there are enough methods to stop flooding from bad clients for ANY kind of encrypting. For ex., limiting UDP (or full) PPS to 200-500 pps per user, or according to their speed. Or filtering announce requests from bad clients. Or something else.

And, of course, nobody from users cries about small speed after uTP filtering - alternatively, speed rises and becomes stable.

Link to comment
Share on other sites

DreadWingKnight

Typical TCP data packets size - ~1.1-1.2kB (statistical data from working border shaper that does incoming/outgoing traffic prioritizing). uTP data packets may be in some cases much smaller.

Also I mentioned TCP fragmentation offloading mechanism in NIC - IMHO it plays prime role in fact that when uTorrent 2.0 'DDoS' started, our border's load at prime time increased from ~50% CPU to approx 100% (so grows twice) when PPS grows by ~30%. And UDP traffic wasn't domination traffic type at that time - it just rises enough high.

P.S. IMHO it'll be good if developers will check (on weak systems like Atom as routers with and without NAT, or on legacy systems, but with good NIC with offloading - to see effect with enough small loads, not hundreds of MBits) all improvements that will decrease network loading and data overhead - at least before putting it in stable builds. Because uTP, that shall decrease network load, really increases it - from it's first implementation till current.

Link to comment
Share on other sites

What makes uTorrent, if another packet within the connection will be droped?

If the user reaches the threshold rate, the overhead packets will be droped. It does not matter that it uses to limit the rate shaping or polycing.

TCP in this case behaves differently than uTP. If the remote side starts to lose packets, the transmitting side starts to send them more slowly. uTP begins to reduce the size of packets: (

Just think if packets are lost, it means it is either a bad line, or reached the threshold speed. Why reduce the size of the package?

Link to comment
Share on other sites

OK, I answer one little Question:

Have utorrent+uTP test on ISP with number of users more then 20000 and uplink more then 20Gbit?

Where online < 30% torrent users and each user has average speed = 10/10Mbit (speed is change dynamically for every one minute and every user)?

speed is change dynamically for every one minute and every user - that's mean that utilization of uplink is 80-95% At any time and NO PRIME TIME by design...

You can download at 20 PM with speed 4/4Mbitps and at 6 AM with speed 100/100Mbitps, but utilization of uplink is 80-95% At any time

1 minute ago

user 1

825258834.png

user 2

825258420.png

Link to comment
Share on other sites

I think an idea in a one of previous messages with special DNS record for controlling uTP function (and may be some other functions in client software - ipv6 for example) is the best way for resolving this problem.

Technical way can be similar to bep 0022 (BitTorrent Local Tracker Discovery Protocol http://www.bittorrent.org/beps/bep_0022.html ) iterative queries using TXT record for ex.

By default (if there is no record) uTP is enable, until network administrator puts a record.

Link to comment
Share on other sites

DreadWingKnight

I can't provide statistics by packet size - by variety of reasons:

1) I don't know how to actually separate uTP (especially uTP data frames) from other UDP packets - game, voice, etc (which takes now not much, but enough hign pps - >10% of overall with enough small packets);

2) now I have blocked uTP due to uplink speed issues and trouble with other TCP/UDP traffic that was noticed at first uTP encounter (actually we couldn't use all of our 350 MBits - on 300 MBits in/out we had troubles with single-connection speed, and this wasn't caused by our hardware - CPU usage on border was below 40%). And, according to growing PPS at the same rates and decreased average packet size on border after 2.0.1 uTorrent release, I decided to block it also, before that time when I (and users with SOHO routers) will have real headache from it.

Sorry, but I (and many other providers too) don't want to be a beta-testers of feature that once caused big troubles (really - can be classified as DDoS) and looks like it'll cause troubles again after enabling. I prefer to disable it at least till it will become free of noticed troubles, and have happy clients that achieve declared speed - on Speedtest and in torrents.

And also I don't want to explain clients why their SOHO routers like DIR-100, that perfectly works for long time, *suddenly* in one day becomes "very slow and old", and how client (that sometimes really can't understand from first time why he/she must connect to VPN/PPPoE before he/she can use internet) can fix this in uTorrent's options. And I can't answer in this case for reasonable client's question: "Why my neighbor, that use such router on provider N, hasn't any troubles, but I must tune uTorrent after each Windows reinstalling? What wrong with *your* network?"

P.S. Why you really don't test new features in laboratory before putting them to public? You can't simulate 'ISP' with weak softrouter (some Atom with good NIC under *BSD/Linux), with 10 clients beyond it in different subnets, and with tracker somewhere in this network; and look CPU load of router under different conditions? And after this - make traffic policing for some clients (packet drops if rate becomes higher than declared - actually policier usually used by uplink providers) and look how torrent will handle this?

Link to comment
Share on other sites

1) I don't know how to actually separate uTP (especially uTP data frames) from other UDP packets

If you're actually blocking them then this is a lie. You need to know how to identify uTP from other UDP packets in order to be able to block them. If you can do the identification to block, you can do the identification for statistics.

The ISPs in this thread are the only ones that have reported such issues to us, and they are restricted to .ua and .ru regions.

Sorry, but I (and many other providers too) don't want to be a beta-testers of feature that once caused big troubles (really - can be classified as DDoS) and looks like it'll cause troubles again after enabling. I prefer to disable it at least till it will become free of noticed troubles, and have happy clients that achieve declared speed - on Speedtest and in torrents.

Considering where the problems are restricted to right now, this uncooperative attitude means that the problems won't get fixed.

Link to comment
Share on other sites

If you're actually blocking them then this is a lie. You need to know how to identify uTP from other UDP packets in order to be able to block them. If you can do the identification to block, you can do the identification for statistics.

AFAIK blocking is simplier then counting just because only "session startup" packets are blocked by the signature.

The ISPs in this thread are the only ones that have reported such issues to us, and they are restricted to .ua and .ru regions.

IMO this is specific for telecommunication in xUSSR.

For many years xUSSR Internet access was traffic-accounted (subscriber pays for Mbytes of traffic), then last 2-4 years it rapidly morphs to bandwidth-accounted, but infrastructure can't grow as quick as subscriber's needs.

Most "last-mile" networks in xUSSR are based in software routers (Linux, FreeBSD and NetBSD) and Asian hardware (China, Taiwan brands).

Backbone networks are "richer", most of them are Cisco and Huawei based, but even in 2010 most of towns and cities (outside of Moscow and St.Peterburg region in Russia, or Kiev in Ukraine) have total Internet bandwidth 100Mbps and lower (for 50-100K citizens).

Link to comment
Share on other sites

DreadWingKnight

You don't ask 2-questions !!!

1.

Have utorrent+uTP test on ISP with number of users more then 20000 and uplink more then 20Gbit?

Where online < 30% torrent users and each user has average speed = 10/10Mbit (speed is change dynamically for every one minute and every user)?

Why you really don't test new features in laboratory before putting them to public? You can't simulate 'ISP' with weak softrouter (some Atom with good NIC under *BSD/Linux), with 10 clients beyond it in different subnets, and with tracker somewhere in this network; and look CPU load of router under different conditions? And after this - make traffic policing for some clients (packet drops if rate becomes higher than declared - actually policier usually used by uplink providers) and look how torrent will handle this?

You have done laboratory tests?

And have uTP design features for 100-1000mbit/s unblocked ETTH network customers? Some tests?

Now We have less then 100 people who has 1000mbit/s connection with Internet throw switches like DGS-3100-48 and IPoE.

2.Why when all work VERY GOOD on 1.8.X and older version and user's have high speed, now they have many problems, and ISP have many problems?

Had you use broadcast (I don't remember may be it's name was BorgChat) chat in Microsoft Network?

When We have local networks less then 1-2000 of customer it's work. But when number of customer grew to >3000 in network traffic consist of 40 and more percents of broadcast. Many ISP blocked Netbios and gave alternatives like Bittorrent and DC++.

Why route protocol for Internet is unicast and not broadcast and not fast as Ospf? Because not everything is solved by increase speed or CPU MHZ or number of borders...

PS:

After February We have to increase number of BRAS from 8 to 20 to serve same traffic. Now developer's of utorrent can know that they connect with Global Warming :(

PSPS:

Someone think that you changes in utorrent like DDOS and You think opposite that ISP have to grew with their networks, but if now 50% of mail is spam - many mail provider block spam, and you say upgrade yours equipment to serve.

There are too many objective points of view, but - something happend after release of utorrent 2.0 with default enable uTp....

Link to comment
Share on other sites

If you're actually blocking them then this is a lie. You need to know how to identify uTP from other UDP packets in order to be able to block them. If you can do the identification to block, you can do the identification for statistics.

Yes, I can block uTP negotiation or control packets. But I don't block all uTP packets at all. And I use signatures that other people found (yes, when they are compared to uTP standard they looks like black magic because they looks meaningless - but they works) - now I have more important tasks than 'bicycle invention' with new uTP signatures.

The ISPs in this thread are the only ones that have reported such issues to us, and they are restricted to .ua and .ru regions.

De-facto in this regions uTorrent is synonym for 'torrent client', and primary type of traffic is torrent traffic (for ex., from 350MBits download there is only 90 MBits for lower ports - web, ftp - and much less for other game/voice traffic; for upload - situation is worse). Also in regions primary traffic consumers are home users, that are connected via thick channels (typically - synchronous 2/2M for generic user, and 10+M for enthusiasts) without pps or connection count limiting. Also these users usually buy cheapest routers (D-Link DIR-100 for network or DIR-300 for WiFi net, or even TPLink one) - so dying router will cause uTP packet storm for ISP.

Considering where the problems are restricted to right now, this uncooperative attitude means that the problems won't get fixed.

Do you really think that beta-testing must be performed only on the production systems instead of laboratory environment that will simulate situation? Especially if I know fact that I can't instantly abort experiment when network quality falls down below acceptable values - because after enabling uTP negotiation blocking load will be decreased very slowly (during 6-12 hours)?

Link to comment
Share on other sites

I wonder if it's easier to filter uTP traffic than to just ask us to fix the problem in the client. As far as I know, nobody that works for an ISP has contacted BitTorrent Inc. about this problem (I've mostly heard about it through 2nd or 3rd hands).

There definitely is a problem with packet sizes in 2.0. In 2.0.1 we doubled the default packet size to 600 bytes. Eevery 10 seconds the packet size is doubled (and saturated at the MTU), if the transfer rate is high enough.

For low transfer rates, packet sizes remain small, since that's an indication of congestion, and we want to add as little as possible to the congestion. If the transfer rate is small enough, the packet size will halve (down to a minimum of 150 bytes).

Since these reports have started to surface, these are the things we have done to mitigate the problem:

1. Double the default packet size

2. Make the packet size depend on the aggregate upload rate, and not just the per-stream upload rate.

These changes made the packet sizes much higher for most connections. They still stay propotional to your transfer rate.

The issue Rafi is referring to is that if you set a global upload rate limit, that will also cap the packet size. This is not a trivial problem to fix though. One potential solution to it would be to have an option to not rate limit uTP connections (since they rate limit themselves).

If somebody with first-hand information about this thinks that we need to do more, please contact me at arvid@bittorrent.com, I am the maintaner of our uTP implementation and I can make changes with a very short turn-around.

Link to comment
Share on other sites

arvid

About blocking - when source of troubles was detected, 'magic signature' was found by people by some days (if you look on nag.ru topic - from starting topic till first signature attempt lasts only one day); and of course bugfix request in this case will bring some result not so fast... But situation requires fast reaction (for ex., when in february at Saturday I optimized iptables filters & removed shaper on border to decrease load - we planned to upgrade it during week, due to new hardware testing - I expected that border will live at this week OK, because in weekend evening maximum there was approx 15% free CPU time; but actually it suddenly died at next Thuesday - when load must be much smaller; so we decided to upgrade border earlier by emergency case; we think that it's caused by activity of new users; just after upgrade we look at forums, and saw that this is caused by uTP - and after blocking it PPS decreased from 72kpps to 50..55 at evening peak, and channel usage grows); so it isn't strange that people preferred to block source now instead of waiting till developers will do this. Why nobody sends this bug later - I don't know.

About congestion control - I have question: why uTorrent starts to decrease packet size instead of increasing intervals between packets when congestion is detected??? This will kill SOHO routers (algorithm is simple: router becomes 'saturated' by long packets; uTorrent start to decrease package size at higher rate, and router dies; all peers disconnects, router brings to life, uTorrent starts connection sequence and situation replays), and cause saw-like traffic & load for ISPs.

IMHO it'll be good to decrease packet size only when there are high losses of long packets (for ex., at 1400byte packets, and much lower losses on 700bytes at same bps), and control flow speed by changing interval between packets. Because 'congestion' means not only bytes-per-second link overflow, but also packets-per-second overflow of hardware, which actually will be killed in this cause by that congestion control algorithm.

Also, if you mentioned laboratory testings - do you check how uTP willl load softrouter comparing to TCP?

Link to comment
Share on other sites

> arvid: I wonder if it's easier to filter uTP traffic than to just ask us to fix the problem in the client

I'm not sure what you call those posters (ISPs/DOHO-router-owners/low-bandwidth-subscribers/me...) reporting the issues here for ages. I guess you simply do not have the time to read those *requests* and/or Firon keeps you in the dark. But blaming the users for not asking you for help ? that's just unfair :(

Your implementation has issues, and you, guys/arvid, just do nothing to resolve them. All in the name of congestion control. As least give a link to a test that demonstrates this with 2.02!

> 1. Double the default packet size

you doubled the lousy 200 bytes size ? great. But not good enough though, as you can see. You still halved the optimal size - MTU. Optimal - at least speed/overhead/PPS - wise.

> 2. Make the packet size depend on the aggregate upload rate

great too. It just doesn't work. I hope you went looked at the link in my previous post ? Here it is again

http://forum.utorrent.com/viewtopic.php?id=76330

>made the packet sizes much higher for most connections. They still stay proportional to your transfer rate.

Sorry, Not good enough. People with low upload bandwidth (with or without SOHO routers) do not need small UDP packets, just because difficulties with your UDP speed limiter. Especially when TCP still uses MTU size. If its a problem for you as you say, and my suggestion (that Greg thinks you do implement) is not a valid one, just do not limit UDP at all. And do it as default behavior (at least at low speeds) , and not as an option.

About not obeying the not dynamic size setting http://forum.utorrent.com/viewtopic.php?pid=463418#p463418: Again, because of speed limiter issues ? Is this another bug that you've missed ?

Did you have a look at all at the issue of not pacing packets ? using 16K packets ?

The bottom line here is - PLEASE do maintain uTP and fix it. People here will gladly help you test it. No more options are required. You might not like it, but there is a need for MTU sized packets as a default ("8") to resolve most of the issues in this thread and many others.

You have to set a goal for yourself of getting at least the same performance out of uTP as with TCP, and in all aspects/connections (overhead, PPS , time to download and so on). If you will not get it done soon - people will just vote against uTorrent/uTP and stop using it. And ISPs will vote against it by just baning uTP :(

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...