FAQ network

Network speed: what you should know before asking questions

by Froenchenko Leonid, <a href="lfroen@gmail.com">lfroen@gmail.com</a>

Preface

The purpose of this document is to clarify different issues regarding network speed that pops up from time to time in amule forum. Generally speaking, there're several reasons for questions about "amule & network":

• Speed reported by amule doesn't match provider given rate
• Pour performance of amule itself or another network application on same computer
• What are key factors influencing network performance while amule is running

Intended audience for this document are users who want to get better understanding of network functionality in general and in practical implication to amule functionality.
This page, however, is not to be seen as comprehensive general purpose "Network FAQ".

Network speed - how match is it ?

While talking about network speed, people are using "bps" units, which mean "bit per second". The reason for bit rather that byte is pretty match historical, but also have engineering motivation behind. This motivation comes from the fact, that not all networks in the world are transferring bytes.
There's also convention to use capital "B" in "Bps" when speed is marked in "bytes per second". However, this convention is not widely accepted. Particularly, organizations like IETF and IEEE are stick to original "bps".

Prefixes

Since invention, networks made quite a progress, and now we have networks that transfers thousand and millions bits more bits per second. For marking those speeds, prefixes "kilo", "mega", "giga", "tera" etc. are used. It is common mistake to think that values of those prefixes are same as in computer science, i.e. powers of 2. The truth is, that for historical reasons, prefixes in networking have decimal base, and not binary.

Prefix	meaning in computers	meaning in networks	difference, %%
K (kilo)	2^10 = 1024	10^3 = 1000	2%
M (mega)	2^20 = 1,048,576	10^6 = 1,000,000	5%
G (giga)	2^30 = 1,073,741,624	10^9 = 1,000,000,000	7%
T (tera)	2^40 = 1,099,511,627,776	10^12 = 1,000,000,000,000	9%

As you can from table above the error in calculation is about 5% when prefix is incorrectly interpreted. Please, note, that speed, that provider tells you is "speed in network", i.e. calculated on decimal base.
For example when provider tells you that your link is "ADSL 256/128" you should understand that he means 256000/128000 bps. Which means, that you have 64000/16000 bytes per second speed in your link.

Protocol overhead - what is it about

When amule is running, it constantly "talks" with other "mules" and servers. This data exchange is needed to identify itself, request information about available sources and files, perform searches and so on. Since this information have no use for user itself, it's called "overhead" i.e. inevitable addition to the data you actually want to upload or download. Amule calls this "connection overhead". However, the number amule presents, includes only size of actual data that amule itself sending to the network stack. Later, this data is sent down to the net with more overhead - now of network protocols. How match is it - lets see in the next section.

Network overhead

First of all - we're talking about IPv4 network. Once upon a time, there was only one type of IP network. Now there's 2 - IP version  4, the old we all know; and IP version 6 - the new one. ED2K protocol by design, is unable to talk over IPv6 network, so users who have it (in Japan and China for example) will not be able to connect "as is". Using IPv4 means, that each packet (TCP, UDP, ICMP) will have IPv4 header. The minimum size of this header is 20 bytes. Header can have optional parts (each 4 bytes) and it's up to your provider  - for example my add 1 option dword.
When talking to other thing on ed2k network, amule uses wide known TCP protocol. UDP also used, but in match smaller scale. As reader might know, TCP is reliable protocol, i.e. it's guarantied that data sent from one side will arrive on the other or error will be reported. In order to achieve this, TCP send its own data to addition to actual transfer. This data includes TCP client initial negotiation, checksums, sequence numbers and acknowledgments. All this in TCP header which is added to each packet sent. Size of this header is 20 bytes minimum. While being small overhead for large bulk transfer, it can take significant part of bandwidth when small amounts of data are being exchanged. This is exactly what happens on source discovery part of amule. Our client is trying to establish connection and negotiate with large number of other clients. Doing this, amule opens new TCP connections all the time. The amount of those connections is controlled by "Maximum number of connections in 5 seconds" setting in preferences. Typical number is about 100. Each TCP connection results in at least 3 packets traveling the net - one is SYN packet, i.e. connection request, and one ACK or RST when connection is accepted or refused, and SYN+ACK to establish session. There's more overhead of DNS queries when address is resolved, retries when host doesn't reply and so on.

On low level:

After passing TCP and IP layers, packets going down to network interface driver. The kind of this driver is depends on the way your computer is connected to internet. For simplicity sake we will assume that this computer is connected toISP directly, i.e. you have no LAN (or switch or router) between. Common setups that I'm aware of:

1. Analog modem, connected to telephone line (ISDN modem falls in this category too)
2. Cable modem, connected through ethernet, ISP gives you IP address through DHCP
3. Cable modem, connected through ethernet, ISP requires you to configure PPPoE or PPTP tunnel
4. ADSL modem, connected through ethernet. You must have PPPoE or PPTP tunnel
5. Variation of above - modem connected to PC by USB. 

In each of above setups have there're different protocols in work, and different headers added to transmitted packets. But, there's important thing to note: ethernet frames traveling between cable/ADSL modem and PC doesn't reach ISP. And consequently not counted in rate calculations. PPPoE and PPTP headers, on the contrary does reach ISP. Whether or not your particular provider includes them in rate calculations I obviously have no idea. For this reason I will exclude those headers from my calculations. If you think that your ISP includes it, add 4 bytes to the size of each packet.

Example:

Let's see how match network overhead we have on typical network. Our connection is cable modem connected with ethernet link to PC directly (no router between). In this setup we have IPv4 packets sent over ethernet.
Lets say we have 10 new connection opened each second, and all accepted (successfully established TCP session). This alone have (I'm counting data going up - from my computer to the net):

10 connection * 2 packets * (20 bytes of TCP + 20 bytes of IPv4) = 800 bytes. 

This mean that we starting with  1.16*8 Kbps of "invisible" overhead caused by the very way the network works. Now, let's assume that after each connection is established our amule sends something to other side and waits to receive an answer.

10 connections * (1 packet of data + 1 ACK)*(20 bytes of TCP + 20 bytes of IPv4) = 800 bytes. 



Total of 800 bytes + 800 bytes = 1600 bytes per second = 6400 bps = 6.4 Kbps

What we have here is 6.4 Kbps of network overhead alone. Taking into account that amule have another data to send (uploads) and it is not the only network application running we will have following picture. Most chances that your link to provider is not that fast.  Amule will try to open 10 connections per second and will try to upload on specified speed. Operating system will share available bandwidth between those and between amule and other network applications (browser for example). Actual results will vary depending on specific OS settings.

ACK bottleneck

In all calculations above there was one assumption - zero download. But, downloading is what the amule was build for. So, let's examine how the overhead above affect downloading speed. The answer is in TCP protocol. When TCP sending data, it requires from other side to acknowledge the reception. So, if client A sending data to client B by TCP, B have to send to A special ACK packets which tells B "ok, I've got it". If, however, A doesn't receive ACK packets in time, he will assume that either packet is lost. So, without going deeply into TCP specification: if B fails to send ACK to A, as a result A will transmit slower.
Now let's see situation in amule. We saw in previous chapter, that uplink stream is congested by connections requests and uploads. As a result, there's good chance that ACK packet for file we downloading will not be sent on time. Remote party will notice and will slow down. This is one more reason why upstream better not be too congested.

Is there something I could do ?

OK, now when you understand while your network is so slow while amule is running you would search a way to fix it. The answer in 2 words: "rate limit". The first thing you should do is to assign realistic rate limits in amule itself. If you have 128 Kbps uplink rate, don't set amule upload limit to 16 (kilobytes per second) just because 128/8=16.
Better, but far more complicated solution is to use QoS and packet scheduling services of your OS. For example, you can give higher priority to ACK packets to solve above "ACK bottleneck" problem. The QoS topic, however, is beyond scope of this article.

Router (switch, home network):  is there any difference ?

When cable coming from your ISP is connected to some switching or routing device, which in turn is connected to several PC's, bandwidth is shared between them. So, having N computers connected, ideal device would simply provide each one of them with 1/N of total bandwidth. Situation may vary in the real life, and your particular device may have different idea about fairness. Since you're not going to have hardware specs about your router chipset, the only advice here is "try and see yourself".