How broad is "maximum upload rate" ?

[Jh00]

Hi there.

First off, please, don't misunderstand my post: it's not (supposed to be) a newbee question.

Here it goes:

I'm not a network guru, but I'm aware that when you are downloading something, you must upload back some "control packets" to keep the information flowing. I suppose that that's why is a bad idea to set maximum upload rate at 0 (zero).

However, I wish to know if these "control packets" are limited by the maximum upload rate too. In other words, when I tell utorrent that my max upload rate is, let's say, 30, I would like to know if utorrent won't, in any circunstance, upload more than 30kb/s in any given moment. For example, these "control packets", DHT information, peer exchange etc. and the upload stream itself would all be covered by the 30kb/s limit.

The reason for this is: I've tested my connection by seeding something and slowly raising my max up rate. For each step, I checked the speed graph for 5 minutes to see if the upload line was constant. I got a top of 35 kb/s, when the line started to go up and down.

Considering that, I would like to know if it would be safe to set my max upload rate at, for example, 34kb/s without hurting my max download speed (I have a cable 2mbit down/ 300 kbit up). If the answer to my question over there is "yes", I presume that it wouldn't hurt it, otherwise I would like some tips on how much should I set my max upload speed. In this scenario, consider utorrent as the only application using the internet in my machine.

The whole idea of this post is to understand how utorrent deals with uploads, so I can share as much as I can.

Thanks in advance! I just love utorrent!

[Ultima]

I do believe µTorrent limits all traffic, including overhead from ACK packets (among other overheads). It doesn't get choked when you upload at the limit since there is still some leeway for ACK packets. It should be fine setting your limit to 34KiB/s, I guess, but you might want to lower it a bit more (so to give some room for other applications)... running the Speed Guide should help you set everything. It sounds to me like your connection speed is somewhere around xx/256k, since xx/384k wouldn't choke at 35KiB/s. Just to be sure, run the Speed Guide like I said -- and be sure to read the instructions.

[alacrity]

ACK belongs to TCP at the Transport Layer. BitTorrent belongs at the Application Layer.

http://en.wikipedia.org/wiki/OSI_model

[Jh00]

So, utorrent would control everything but the ACK packets? Is there a way to calculate how much ACK data I would send for X data received?

@Ultima: I know I could use the speedguide, however, since I'm in S. America, I'm affraid that the results will not be very accurate, because of latency issues and considering that the server used to test it is abroad.

[Ultima]

The DSL Reports page has mirrors for countries around the world... check the link at the bottom of the DSL Reports page.

[kurahashi]

I do believe µTorrent limits all traffic, including overhead from ACK packets (among other overheads)

I'm afraid you are wrong here. I've tested this matter not once and not two and the conclusion is uTorrent does not limit TCP overhead, it only limits the "clean" transfers between peers.

This mean, unfortunately, that while you're downloading more you're uploading more and this can lead to chocking your (usually asymetric) connection.

Therefore, Jh00, you should test how your upload behaves while your download is saturated to the max and choose the last one "stable" value. But you can still set this 34kB/s as alternate upload value while not downloading.

[Ultima]

Meh, dunno (hence the reason I had the word "believe"). I might've misread Firon, DWK, or ludde before -- they probably said BitTorrent overhead or peer communication overhead, and I probably mistook it for general overhead. In that case, I stand corrected.

[Switeck]

Since TCP/IP connection overhead isn't figured into the useage, (as it varies depending on setup too!) µTorrent could be using a LOT more bandwidth than reported if you're allowing 100's of connections at once.

[alacrity]

I believe it is generally accepted that connection overhead equals around 2.5%. So every 100KB upload costs ~2.5KB download.

[BoundSyco]

The number of ack packets (upload speed required) is determined by the window size for the tcp connection. There are four ways of setting your window size, listed and described here:

http://www.microsoft.com/technet/community/columns/cableguy/cg1105.mspx#E2B

If utorrent controls the window size(option #4) then it actually can limit the total upload speed of the connection (because it can calculate how many ack packets are being sent on average).

The rest of TCP overhead is easy to calculate.

ACK packets and TCP overhead is incredibly small compared to data transfer, take this example for instance:

Lets say you have a recieve window of 10KB (10 KiloBytes). This means that for every 10KB of data segments (not including tcp overhead) recieved, you send one ack packet. An ack packet is usually 1 tcp/ip packet with no data: 8 (32bit)words (32 bytes).

The largest tcp packet is 2^16 = 65,536 bytes or roughly 65 KB. There is alot of other things I could say here, but most of it isn't particularly useful. The important thing is that packet sizes are limited by the MTU (maximum transmision unit) which in most cases is usually around 1500 for high bandwidth (cable modem, ethernet, dsl) connections. This means your average tcp/ip packet is going to be 1500 bytes in length (even if the program spits more data at it, it is going to break the the data up into packets of this size to be transmitted over the wire(less) connection).

Lets suppose you are trying to saturate your connection (you want as little overhead as possible) you are going to maximize the size of your packet, so you always transmit 1500 byte packets. With 8 bytes of overhead, you are transmitting 1492 bytes of actual data per packet. So 10KB / 1492 B = about 6.8 Lets say for the sake of ease that for every 7 recieved packets you transmit 1 acknowledge packet.

Ok then; so you have a 2Mb download connection. How long does it take for you to recieve 7 packets (or 10KB data). At 2Mib, you get roughly 2Mb / 8 = 512 KB down per second. Thus, you can download roughly 512/10 = 50 sets of data. Thus, you would send 50 ack packets. (I ignored packet overhead because it is less than 0.005% of the packet).

50 ack packets is 50*32bytes = 1600 B. So your ack packets take about 1.5 KB/s

Thus, if your recieve window is set to 10 KB you should expect to use roughly 1.5 KB/s of your upload in TCP overhead if you are maxing out your download.

[Switeck]

However, there are also the connected but not uploading/downloading ips.

These each receive a keep-alive packet from time to time. (At least once every 15 seconds was the case for the Gnutella network connections, so I doubt this is too much different.)

They also receive information concerning which pieces of the torrent you have as well as requests from your client for them to upload to you. The flags column in µTorrent shows just one way your client communicates with theirs.

Both of those types of messages (keep-alive packets and flags/piece requests) ironically HAVE to have ACK packets of their own. Compound interest, if you will, on something that may never return a KB to you. And if your end never uploads to them, they become FAR less likely to ever send anything to you.

Tit-for-tat, at its worst, becomes nothing for nothing...and everybody loses.

Something to consider if you allow 100's of connections at once.

[Jh00]

Thank you very much guys! This thread solved many doubts I had about what I want to do. I will do some tweakings and calculations and see how things turn out. Thank you again!