We increase the speed and quality of work of the network suffering from packet loss
Good day. I decided to share with you my understanding of this issue, and the mechanism of its solution used in Silver Peak optimization WAN devices.
So, the practical majority of modern networks, uses in its basis packet transmission and the IP protocol. Information is transmitted through a network of pieces of information, and usually the size of these pieces varies from 1 byte to 1500 bytes (I mean the payload). On the way through the WAN network, such packets can pass through a great many routers and gateways. You can see some of these transshipment points with the Traceroute utility. But this is not all real transit nodes, for example, you will not see here those nodes through which traffic has passed through the tunnel (MPLS VPN, GRE, etc.). At the same time, with a non-zero probability, any of the transit nodes will currently be heavily loaded, and will destroy your package in order to avoid network overload. And the more such transit nodes, the greater the likelihood of packet loss on the network.
As an example, I will give a picture showing how the percentage of lost packets can change over time on the same communication channel:
')
Theoretically, such a packet is dropped, the thing is quite safe and normal - the special TCP protocol monitors the integrity of the data transfer. But as always, there are nuances. The nuances are that TCP, in case of packet loss, will have to send it through the network again. But in order to make a decision about re-sending, you need to wait for the notification from the receiving party that the next packet has not been received. And here comes to the fore such a network parameter as the signal delay. The longer it is, the longer the transmitting side will be in the dark, and the slower the transfer of information will be.
Below are graphs of the transmission rate of traffic on the delay in the communication channel and the percentage of packet loss. It shows that in fact, the main loss in transmission speed in a channel with a typical delay of 50-100 milliseconds for a WAN occurs at a still seemingly insignificant percentage of losses: 1-2%.
If we talk about applications that work through UDP and are oriented to work in real time, for example, telephony or video conferencing, then they don’t provide for a retransmission mechanism. And if there is a loss, then, whatever one may say, artifacts in the form of “croaking”, “stuttering”, and a periodically crumbling picture come out.
It turns out that you can look at the loss of packages in a slightly different angle, and solve it in a rather elegant way, as did the engineers of Silver Peak. Surely many of you have heard about special coding methods that allow to detect errors, and some of them even correct errors in information. For example, ECC codes and Reed-Solomon codes, first used industrially in the 1970s when CDs appeared. The general meaning of such codes is that they introduce some redundancy, and this redundancy can adaptively adapt to the current characteristics of the channel. Another more obvious example is information protection technology on RAID5 disk arrays, which provides for one redundant disk drive for every 3, 4, 5 or more data disks. In the case of packet transmission, the analogue of disks is the package itself - for every N packets, one redundant one is created.
The trouble is that such technologies, which have the common English name Forward Error Correction (FEC), are usually used only at the physical level of the data transmission channel. And in no way can they eliminate the loss of information associated with network overloads, dynamic rebuilding of topology, etc. Silver Peak engineers implemented the FEC technology at the data link layer, so that between any two Silver Peak devices, a “tunnel” is created, in which a number of redundant packets are supported and adaptively adjusted. The typical topology of the communication channel using this solution and FEC technology is shown in the following picture:
It shows how the device does not transmit to the transmitting side and generates a redundant packet, and the device on the receiving side re-creates, on its basis, another lost packet.
To assess the effectiveness of FEC for eliminating packet loss, you can look at the time of file transfer over the network, with a certain percentage of traffic loss. From the following picture, it is clear that even a small percentage of redundancy makes it possible to increase the file transfer speed several times, but stuttering and cubist-style pictures during a video conference can be relieved to forget:
So, the practical majority of modern networks, uses in its basis packet transmission and the IP protocol. Information is transmitted through a network of pieces of information, and usually the size of these pieces varies from 1 byte to 1500 bytes (I mean the payload). On the way through the WAN network, such packets can pass through a great many routers and gateways. You can see some of these transshipment points with the Traceroute utility. But this is not all real transit nodes, for example, you will not see here those nodes through which traffic has passed through the tunnel (MPLS VPN, GRE, etc.). At the same time, with a non-zero probability, any of the transit nodes will currently be heavily loaded, and will destroy your package in order to avoid network overload. And the more such transit nodes, the greater the likelihood of packet loss on the network.
As an example, I will give a picture showing how the percentage of lost packets can change over time on the same communication channel:
')
Theoretically, such a packet is dropped, the thing is quite safe and normal - the special TCP protocol monitors the integrity of the data transfer. But as always, there are nuances. The nuances are that TCP, in case of packet loss, will have to send it through the network again. But in order to make a decision about re-sending, you need to wait for the notification from the receiving party that the next packet has not been received. And here comes to the fore such a network parameter as the signal delay. The longer it is, the longer the transmitting side will be in the dark, and the slower the transfer of information will be.
Below are graphs of the transmission rate of traffic on the delay in the communication channel and the percentage of packet loss. It shows that in fact, the main loss in transmission speed in a channel with a typical delay of 50-100 milliseconds for a WAN occurs at a still seemingly insignificant percentage of losses: 1-2%.
If we talk about applications that work through UDP and are oriented to work in real time, for example, telephony or video conferencing, then they don’t provide for a retransmission mechanism. And if there is a loss, then, whatever one may say, artifacts in the form of “croaking”, “stuttering”, and a periodically crumbling picture come out.
It turns out that you can look at the loss of packages in a slightly different angle, and solve it in a rather elegant way, as did the engineers of Silver Peak. Surely many of you have heard about special coding methods that allow to detect errors, and some of them even correct errors in information. For example, ECC codes and Reed-Solomon codes, first used industrially in the 1970s when CDs appeared. The general meaning of such codes is that they introduce some redundancy, and this redundancy can adaptively adapt to the current characteristics of the channel. Another more obvious example is information protection technology on RAID5 disk arrays, which provides for one redundant disk drive for every 3, 4, 5 or more data disks. In the case of packet transmission, the analogue of disks is the package itself - for every N packets, one redundant one is created.
The trouble is that such technologies, which have the common English name Forward Error Correction (FEC), are usually used only at the physical level of the data transmission channel. And in no way can they eliminate the loss of information associated with network overloads, dynamic rebuilding of topology, etc. Silver Peak engineers implemented the FEC technology at the data link layer, so that between any two Silver Peak devices, a “tunnel” is created, in which a number of redundant packets are supported and adaptively adjusted. The typical topology of the communication channel using this solution and FEC technology is shown in the following picture:
It shows how the device does not transmit to the transmitting side and generates a redundant packet, and the device on the receiving side re-creates, on its basis, another lost packet.
To assess the effectiveness of FEC for eliminating packet loss, you can look at the time of file transfer over the network, with a certain percentage of traffic loss. From the following picture, it is clear that even a small percentage of redundancy makes it possible to increase the file transfer speed several times, but stuttering and cubist-style pictures during a video conference can be relieved to forget:
Source: https://habr.com/ru/post/147747/
All Articles