Shulou(Shulou.com)06/03 Report--

What are ACK, NACK and REX in network communication? I believe that most people do not understand, in order to let you better understand, the editor summed up the following content, do not say much, let's look down together.

ACK:Acknowledgement, which is a kind of positive feedback, in which the receiver sends a message to the sender after receiving the data.

NACK:Negative Acknowledgement, on the other hand, is a kind of negative feedback, in which the receiver notifies the sender only when the data is not received.

REX:Retransmission, retransmit, when the sender learns that the data is lost, it resends a copy of the data.

Question 1: how does the receiver determine whether the packet is lost?

Solution: numbering, each packet is marked with a sequence number (Seq number), and if the receiver finds that the sequence number jumps / is missing, it can determine that the packet is lost.

This is why a sequence number field is defined in the packet header of the TCP protocol (see the red mark in the figure):

To expand, let's take a look at the definition of the packet header of the UDP protocol:

As you can see, UDP header does not use any fields to identify the serial number (Seq number), so UDP is a transport protocol that does not care about packet loss at all.

Question 2: how does the sender confirm that the packet has been lost?

There are several common solutions, which are briefly introduced here without going into details.

1. Stop and wait agreement

The sender sends only one packet at a time and starts a timer. If the timer expires and still does not receive the ACK of the packet, the packet is considered lost and the packet is retransmitted. If an ACK is received, reset the timer and send the next packet.

Problem: the judgment and transmission efficiency of packet loss is very low.

two。 Continuous ARQ Protocol & sliding window Protocol

The sender maintains a sending window of a certain size, and all packets located in the sending window can be sent continuously without waiting for the other party's ACK confirmation.

The receiver usually adopts the cumulative acknowledgement mode, that is, it does not have to send ACK to each packet one by one, but after receiving several packets in succession, it sends ACK to the last packet that arrives sequentially, indicating that this packet and all previous packets have been received correctly.

Accumulate the shortcomings of the confirmation mode: under the network with serious disorder, the efficiency is very low, and some packets that have been sent but not delivered in order must be retransmitted.

Improved scheme: selective retransmission (Note: KCP/SRT protocol is implemented): for sequential packets, send cumulative acknowledgement; for hopping packets, the sender of ACK; retransmits only the really lost packets.

3. Fast retransmission

The transmission protocol using ACK mechanism usually retransmits the packet after the ACK timeout of a packet at the sender, which is not timely enough.

Fast retransmission: if the receiver receives a packet with a hopped sequence number, it immediately sends the ACK (repeat acknowledgement) of the last consecutive packet to the sender. If the sender receives three consecutive repeated acknowledgements, it is considered that the next packet of the ACK has been lost, and the lost packet is retransmitted immediately.

4. NACK

The receiver periodically notifies all unreceived packet serial numbers to the sender through a feedback message for retransmission.

The improvement: the frequency and bandwidth consumption of feedback packets are reduced, and at the same time, the sender can be notified in time for packet loss retransmission.

Question 3: the calculation rule of retransmission timeout?

RTO: retransmission timeout (Retransmission Timeout), which is the most important parameter used by the sender to determine packet loss and perform retransmission.

Obviously, it should be a value that varies with the RTT (round trip time) transmitted over the network. Ideally, the value of RTO should not be less than RTT (the shortest time from the packet sent to the other party's ACK to arrive). In fact, RTT changes very frequently, and the RTT may be different for each transmission. If you rudely set RTO = RTT, it will certainly lead to excessive retransmission.

Therefore, the RTO calculation method adopted by TCP protocol is:

1. Based on multiple RTT measurements, a smoothed RTT estimate is given: SRTT (Smoothed Round Trip Time).

2. RTO = SRTT + some coefficient (threshold to prevent jitter)

3. Further, the system level sets the lower limit of RTO to 100ms or 200ms to prevent outliers

4. Furthermore, for the RTO of a retransmitted packet, a Backoff algorithm is added, for example, RTO = 2 RTO for each retransmission to reduce the frequent retransmission of a packet.

Note: with regard to the Backoff strategy of retransmission packet RTO, KCP has been proved by experiments that the Backoff coefficient of RTO with 1.5 times is better than that with 2 times.

Question 4: how long will the packet of the sender be cached?

In order to achieve retransmission, the sender must cache the transmitted packet locally, and when it needs to be retransmitted, the packet can be taken from the cache queue for retransmission.

For the transport protocol of the ACK model (such as TCP), you can delete the cache after receiving the ACK of the other party, so if it is the transport protocol of the NACK model, how to update and clean up the cache queue?

1. Scheme 1: based on RTT and NACK time interval

Assuming that the current RTT (network round trip time) is the feedback interval of rtt ms,NACK is x ms, then the minimum survival time for a packet in the send cache queue should be:

Cache time = 2 * rtt + x

Assuming that the NACK feedback packet received after this time does not indicate that the packet is missing, it can be deleted. Of course, similar to the reasons involved in RTO, rtt changes frequently, so it is not safe to rely solely on this theoretical value to delete the cache. It is recommended to increase some redundancy.

two。 Plan 2: based on business scenario

For real-time audio and video communication scenarios, there are certain requirements for delay, so there is no need to retransmit data more than 1 second. Or, assuming that the GOP of the video is 2s, you can keep a maximum of 2s of packets in the cache queue.

Question 5: how often does the receiver send a nack request?

Suppose the receiver sends the NACK request immediately after finding that the sequence number of the packet jumps. Because the UDP packet may arrive out of order, this scheme will lead to too many invalid retransmission requests.

A more reasonable solution is to send a NACK request at a specified time in each interval (for example, WebRTC uses 10ms), with all the packet loss serial numbers for this period of time.

Question 6: which lost packets are placed in the nack request queue?

The queue of retransmission requests at the receiver should also have a certain mechanism. Not all packet losses must be retransmitted, such as:

1. The current audio playback has reached the time point when timestamp is x, actually in timestamp

< x 的所有丢失的音频包都不应该再请求重传了，视频也是如此。 2. 作为 SFU 中转服务器，它没有播放时间的概念，因此方法 1 并不适用，但是可以参考发送端缓存的逻辑，假设 GOP 是 2s，则对比最新的 packet 时间戳，丢失的数据包时间在 2s 之前的数据，则没有必要再申请重传了。 补充一点，作为 SFU 中转服务器，可能会遇到下述情况，即：收到客户端的 NACK 请求的数据包不再自己的 cached packet list 里面： SFU 作为客户端上行的接收端，发现丢包也跟普通的接收端一样，定时主动地向源头发送 NACK 请求；反过来，SFU 作为客户端下行的发送端，收到 NACK 请求后，如果发现不在 cached list，则标记一下，一旦收到源头的重传，则第一时间转发到下行。 问题 7：如何防止某个数据包频繁的 nack 请求 ？ 参考 WebRTC 的实现，有如下防止策略： 1. 当一个丢失的包被 NACK 请求重传了至少 N 次（如：10次）后依然没有成功收到，则应该放弃了（很可能发送端也已经没有这个数据包的缓存了） 2. 考虑到重传请求在发送端的响应时间及网络 RTT，接收端应该确保在一定时间周期内不要频繁地发送对同一个数据包的 NACK 重传请求。（如：WebRTC 选择的时间周期是 5 + RTT * 1.5），即：在这个时间周期内不再重复发送同一个数据包的 NACK 请求。 3. 当 nack reqeust list 里面的数据包太多了（比如：超过 1000），则应该考虑清理一下（网络太弱了），对于视频的话，直接发送 IDR request，重新申请新的 GOP 数据。 问题 8：重传包的优先级？FEC 包是否需要重传 ？ 考虑到丢包 ->

Retransmission has delayed the arrival time of packets, so the priority of retransmission packets should be higher than that of ordinary packets, and of course, there should be a strategy of decreasing gradually according to the priority of the number of retransmissions.

FEC packets are not needed and are of little significance. The purpose of FEC is to reduce the number of redundant packets added by retransmission. It is not fatal to lose them. We only need to retransmit more valuable packets.

How is the NACK message of the question 9:RTCP protocol defined?

The definition of the NACK message is defined in the [rfc4585] document.

The feedback packet header of RTCP is defined as follows. FMT and PT determine the type of message, and FCI is the specific payload of this type of message:

The format of the NACK feedback message specified by the protocol is as follows: (multiple FCI can be attached, and their length can be marked by the length field of header):

The design here is clever, it can carry multiple consecutive packets at a time in the case of packet loss:

PID (Packet identifier), which is the sequence number of the lost RTP packet

BLP (Bitmao of Lost Packets), which indicates the loss of the next 16 packets by masking

After reading the above, do you have a general understanding of ACK, NACK and REX in network communication? If you want to know more about the content of the article, welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.