Internet-Draft Network Working Group October 2024
Chen Expires 21 April 2025 [Page]
Workgroup:
Web and Internet Transport
Internet-Draft:
draft-chen-tsvwg-updated-ack-00
Published:
Intended Status:
Informational
Expires:
Author:
D. Chen
China Mobile

An Updated ACK mechanism based on RDMA

Abstract

This document proposes a new ACK mechanism for the technical gaps of RDMA used in wide-area network data transmission. The new ACK mechanism, which gets rid of the limitation of sliding window size setting and RTT measurement, can further improve the effective throughput of network transmission.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 21 April 2025.

Table of Contents

1. Introduction

The existing retransmission mechanisms for packet loss mainly include the following three: timeout retransmission, fast retransmission and selective retransmission (SACK). Timeout retransmission sets a period of time after data is sent. If no ACK response is received within this period, the data is retransmitted, whether the sent packet or ACK response is lost. In this mechanism, the timeout RTO should be set to slightly greater than one RTT (Round-Trip Time latency). And due to network fluctuations, RTO should also be a dynamically changing value. After the sender sends several packets and the receiver receives three identical ACK packets, fast retransmission retransmits the lost packet segment before the timer expires. The SACK method adds a SACK part to the TCP header field. The SACK part can send the received data information to the sender. In this way, the sender can know which data has been received and which data has not been received. This can solve the efficiency problem of fast retransmission to a certain extent (for example, if 2, 3, and 4 packets are lost in a row, quick retransmission alone requires nine ACK times, but with the SACK option, the sender knows which packets are lost and can complete the process through one retransmission).

In the above methods, if each data is sent for a confirmation response, when the previous packet received the response and then sent to the next, the network transmission efficiency will be very low. Therefore, TCP introduced the sliding window mechanism, there is a window field in the TCP header, which tells the other side how long the free buffer I currently have for receiving data. For the sender, subtract this value from the length of the data that has not received the ACK response, which is the data that can be sent directly at present. After receiving the ACK packet, continue to slide the send window backwards.

The three classical retransmission modes of packet loss all depend on the setting of RTO and window size. However, as mentioned above, the setting of RTO is related to RTT, and RTT is related to network status, so it is difficult to achieve accurate setting of RTO. If the RTO is too large, the sender will have to wait for a long time to discover that the packet segment is lost, which reduces the throughput of connection data transmission. On the other hand, if the RTO is too small, although the sender can quickly detect the loss of packet segments, it may mistake some packet segments with a large delay as lost, causing unnecessary retransmission and wasting network resources. The size of the sliding window also has a great impact on network performance. If the sliding window is too small, the confirmation information needs to be transmitted frequently on the network, which will occupy a large amount of network bandwidth. If the sliding window is too large, the network with high utilization rate and easy packet loss will need to send repeated data for many times, which also consumes network bandwidth.

In order to meet the data transmission requirements of wide-area high-throughput networks, improve the network bandwidth utilization as much as possible, improve the effective throughput rate of the network, solve the problems such as the sensitivity of the go-back-N packet loss retransmission algorithm used by RDMA to packet loss, and the maintenance of the receiving window by the traditional SACK, this document plans to improve the existing packet retransmission mechanism. A time-counting dual-dimensional packet loss retransmission mechanism (T/C-SACK) is proposed.

2. Updated ACK Mechanism

This document proposes a time-counting dual-dimensional packet loss retransmission mechanism (T/C-SACK), which decoups the sending rate from packet loss retransmission, and removes window-less. The receiver triggers the packet loss retransmission notification according to the preset time or the number of packets received.

The mechanism proposed in this paper enables the sender to continuously send packets according to the preset transmission rate without being limited by the sliding window size, which solves the problem of bandwidth consumption caused by unreasonable window size setting and can improve the effective throughput of network transmission.

The flow of the new ACK mechanism proposed in this document is as follows:

3. A New ACK Packet Format

TBD

4. Security Considerations

5. IANA Considerations

This document has no requests to IANA.

6. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

Author's Address

Danyang Chen
China Mobile
Beijing
100053
China