The correct way to calculate channel bandwidth

Question

I read several articles on the Internet and I got a pretty good idea of ​​TCP and UDP in general. However, I still have some doubts that, I am sure, are not entirely clear to me.

What is the correct way to calculate bandwidth?

( Can't we just divide Total number of bytes received by total time taken ? )

What is this key feature in TCP that makes it much higher than UDP?

UPDATE:

I realized that TCP uses windows, which are nothing more than many segments that can be sent before they really wait for Thanks. But I doubt that UDP segments are constantly sent, without even worrying about Gratitude. Thus, in UDP there is no additional overhead. Then why is TCP throughput much higher than UDP throughput?

Finally,

It's true?

 TCP throughput = (TCP Window Size / RTT) = BDP / RTT = (Link Speed in Bytes/sec * RTT)/RTT = Link Speed in Bytes/sec 

If so, then TCP throughput is always equal to Know Link speed. And since RTT cancels each other out, TCP throughput is not even dependent on RTT.

I have seen in some network analysis tools such as iperf, throughput label performance testing, etc. that TCP / UDP throughput varies with block size.

How does bandwidth depend on block size? Is the block size equal to the TCP window or the size of the UDP datagram?

Answer 1

How to calculate the throughput?

There are several ways, depending on what exactly you want to measure. They all come down to dividing a certain number of bits (or bytes) by a certain duration, as you mention; which depends on what bits you count or (less commonly) what time points you are considering for measuring duration.

Factors you should consider:

At what level of network stack do you measure throughput?

If you measure at the application level, all that matters is what useful data you transfer to another endpoint. For example, if you transfer a file of 6 KB in size, the amount of data that you calculate when measuring throughput is 6 KB (i.e. 6,000 bytes, not bits, and pay attention to a factor of 1000, not 1024; these conventions are common in the network )

This is usually called goodput and may differ from what is actually sent at the transport level (as in TCP or UDP), for two reasons:

1. Heading overhead

Each layer in the network adds a header to the data, which introduces some overhead due to its transmission time. Moreover, the transport layer breaks your data into segments; This is because the network layer (as in IPv4 or IPv6) has a maximum packet size called MTU , usually 1500 V on Ethernet networks. This value includes the size of the network layer header (for example, the IPv4 header, which has a variable length but usually 20 V long) and the transport layer header (for TCP it is also variable in length, but usually 40 V long). This leads to the fact that the maximum size of the MSS segment (the number of bytes of data without headers in one segment) is 1500 - 40 - 20 = 1440 bytes.

Thus, if we want to send 6 KB of application-level data, we must split them into 6 segments, 4 of 1440 bytes each and one of 240 bytes. However, at the network level, we send 6 packets of 4 of 1,500 bytes each and one of 300 bytes, which in total is 6.3 kB.

Here I did not take into account the fact that the data link layer (as in Ethernet ) adds its own header and, possibly, also a suffix, which additionally increases overhead. For Ethernet, this is 14 bytes for the Ethernet header, an additional 4 bytes for the VLAN tag, then a CRC of 4 bytes and a gap of 12 bytes, for a total of 36 bytes per packet.

If you are considering a channel with a fixed speed of, say, 10 Mbps, depending on what you are measuring, you will get a different bandwidth. Usually you want one of them:

• Good performance, that is, application-level bandwidth if you want to measure application performance. In this example, you divide 6 KB by the transmission duration.
• Link layer bandwidth if you want to measure network performance. In this example, you divide 6 kB + TCP overhead + IP overhead + Ethernet overhead = 6.3 kB + 5 * 36 B = 6516 B by the transmission duration.

Relay Costs

The Internet is a network with maximum effort, which means that packets will be delivered, if possible, but can also be dropped. Dropping packets is adjusted by the transport layer, in the case of TCP; for UDP there is no such mechanism, which means that either the application doesn’t care if some pieces of data are being delivered, or the application itself retransmits over UDP.

Retransmission reduces useful performance for two reasons:

a. Some data needs to be sent again, which takes a lot of time. This introduces a delay that is inversely proportional to the speed of the slowest channel in the network between the sender and receiver (it is also a bottleneck). b. Detecting that some data has not been delivered requires feedback from the recipient to the sender. Due to propagation delays (sometimes called delays; caused by the finite speed of light in the cable), feedback can only be received by the sender with some delay, which further slows down the transmission. In most practical cases, this is the most significant contribution to the additional delay caused by retransmission.

It is clear that if you use UDP instead of TCP and do not care about packet loss, you will certainly get better performance. But for many applications, data loss is unacceptable, so this measurement does not make sense.

There are some applications that use UDP for data transfer. One of them is BitTorrent, which can use either TCP or the protocol they developed, called uTP , which emulates TCP over UDP, but aims to increase efficiency when using multiple parallel connections. Another transport protocol implemented over UDP is QUIC , which also emulates TCP and offers multiplexing of multiple parallel transmissions over a single connection and direct error correction to reduce retransmissions.

I will discuss a bit of direct bug fixes a bit as it is related to your bandwidth issue. A naive way to implement this is to send each packet twice; in case one is lost, the other still has a chance to be received. This reduces the number of retransmissions by half, but also halves your useful performance because you send redundant data (note that the bandwidth of the network or link layer remains unchanged!). In some cases, this is normal; especially if the delay is very large, for example, on intercontinental or satellite channels. Moreover, there are some mathematical methods where you do not need to send a full copy of the data; for example, for every n packets that you send, you send another redundant packet, which is XOR (or some other arithmetic operation) of them; if the excess is lost, it does not matter; if one of n packets is lost, you can restore it based on the excess of one and the other n-1. Thus, you can configure the overhead of direct error correction for any amount of bandwidth that you can save.

How do you measure transmission time

Is the transfer complete when the sender has finished sending the last bit over the wire, or does it also include the time it takes for the last bit to reach the receiver? In addition, does it include the time required to receive confirmation from the recipient, which states that all the data was received successfully and that no retransmission is needed?

It really depends on what you want to measure. Please note that for large gears, one extra round-trip time is negligible in most cases (if you do not communicate, for example, with a probe on Mars).

What is this key feature in TCP that allows it to have much higher throughput than UDP?

This is not true, although a common misconception.

In addition to retransmitting data when necessary, TCP will also adjust the sending speed so as not to cause packet drops due to network congestion. The tuning algorithm has been improved over decades and usually quickly converges to the maximum speed supported by the network (actually a bottleneck). For this reason, it is usually difficult to outperform TCP in bandwidth.

With UDP, the sender has no speed limit. UDP allows the application to send as much as it wants. But if you try to send more than the network can process, some data will be discarded, which will reduce your bandwidth, and also make the administrator of the network that you overload very angry. This means that sending UDP traffic at high speed is impractical (unless the goal is a DoS network).

Some multimedia applications use UDP, but limit the transmission speed on the sender at a very low speed. This is typically used in VoIP or Internet radio applications where very low bandwidth but low latency are required. I believe this is one of the reasons for the misconception that UDP is slower than TCP; it is not, UDP can be as fast as the network allows.

As I said before, there are protocols like uTP or QUIC implemented over UDP that achieve performance similar to TCP.

It's true?

 TCP throughput = (TCP Window Size / RTT) 

Without packet loss (and retransmissions), this is correct.

 TCP throughput = BDP / RTT = (Link Speed in Bytes/sec * RTT)/RTT = Link Speed in Bytes/sec 

This is only correct if the window size is set to the optimum value. BDP / RTT is the optimal (maximum) transmission rate in the network. Most modern operating systems should be able to automatically configure it.

How does bandwidth depend on block size? Is the block size equal to the size of the TCP or UDP window?

I do not see the block size in the iperf documentation .

If you refer to the size of the TCP window, if it is smaller than BDP, then your throughput will not be optimal (because you spend time waiting for the ACK instead of sending more data; if necessary, I can explain in more detail). If it is equal to or higher than BDP, you will achieve optimal throughput.

Answer 2

It depends on how you define Bandwidth. This can usually be one of the following.

• The number of bytes (or bits) sent over a specific period of time;
• The number of bytes (or bits) sent and received at the end of the receiver over a fixed period of time;

You can apply this definition to each layer when people talk about bandwidth. At the application level, the second definition means that the bytes were actually received by the receiving end of the application. Some people call it "good." In the transport layer, say TCP, the second definition means that the corresponding TCP ACKs are received. For me, most people should only be interested in the fact that bytes are really accepted by the end of the receiver. So, the second definition usually means that people mean "Bandwidth."

Now that we have a clear definition of bandwidth (second definition). We can discuss how to properly measure throughput.

Typically, people use TCP or UDP to measure network bandwidth.

TCP: People usually measure TCP throughput only on the sender side. For packets successfully received at the receiver, ACKs will be sent back. Thus, the sender himself will know how many bytes are sent and received at the end of the receiver. Dividing this number by the measurement time, we will know the throughput.

But when measuring TCP throughput, there are two things to note:

• Is the sender side always a full buffer during measurement? those. during the measurement period, the sender must always have packages to send. This is important for the correct measurement of bandwidth. for example, if I set the measurement time to 60 seconds, but my file was completed within 40 seconds. Then there are 20 seconds when the network is actually not working. I will underestimate the bandwidth.

• TCP speed is controlled by the size of the overflow window, the duration of the slow start, the size of the sender window (and the size of the receiver window). A suboptimal configuration of these parameters will underestimate TCP throughput. Although most of the current TCP implementation should have a good configuration of all these functions, for a tester one cannot be 100% sure that all these configurations are optimal.

Due to these limitations / risks of TCP in estimating network bandwidth, quite a few researchers use UDP to measure network bandwidth.

UDP: Since UDP does not send an ACK after packets have been successfully received, people need to measure the bandwidth at the end of the receiver. Or, if the end of the receiver is not easy to get, people can compare the sender and receiver logs to determine bandwidth. But this inconvenience is mitigated by some means of measuring bandwidth. For example, iperf has built-in serial numbers in its custom payload so that it can detect any loss. In addition, a sender report will be sent to the sender to show bandwidth.

Since UDP, by its nature, simply transfers everything that it has to the network and does not wait for feedback. Its bandwidth (remember the second definition) after the measurement will be the actual bandwidth (or bandwidth) of the network.

So, as a rule, the throughput measured by UDP should be higher than that of TCP, although the difference should be small (~ 5% -10%).

One of the biggest drawbacks of measuring UDP throughput is that when using UDP, you must also make sure that the buffer on the sender side must be full. (Otherwise, it will lead to underestimated bandwidth in the form of TCP). This step will be a bit complicated. In iperf, you can specify the send speed using the -b option. Increase the -b value in different test rounds by shifting the measured throughput. For example, in my gigabit Ethernet, I first use -b 100k in the test. The measured throughput is 100 Kbps. Then I do the following iterations to merge the maximum bandwidth, which is the bandwidth of my ethernet.

-b 1m → bandwidth: 1 Mbps

-b 10m → bandwidth: 10 Mbps

-b 100 m → bandwidth: 100 Mbps

-b 200 m → bandwidth: 170 Mbps

-b 180 m → bandwidth: 175 Mbps (this should be very close to real capacity)