Web and Internet Transport D. Chen Internet-Draft China Mobile Intended status: Informational 18 October 2024 Expires: 21 April 2025 An Updated ACK mechanism based on RDMA draft-chen-tsvwg-updated-ack-00 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. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Chen Expires 21 April 2025 [Page 1] Internet-Draft Network Working Group October 2024 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Updated ACK Mechanism . . . . . . . . . . . . . . . . . . . . 3 3. A New ACK Packet Format . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 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). Chen Expires 21 April 2025 [Page 2] Internet-Draft Network Working Group October 2024 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. Chen Expires 21 April 2025 [Page 3] Internet-Draft Network Working Group October 2024 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: According to the network environment and the size of the packet to be sent, the packet sending rate of the sender is preset, the cumulative acknowledgement time T of the receiver and the cumulative number of received packets N. If the window limit is removed, the sender does not need to adjust the sending rate based on packet loss. Instead, the sender only needs to keep sending packets at the preset sending rate. Within the range of the cumulative acknowledgement time T and the cumulative number of received packets N, the receiver continues to receive packet packets and arranges them according to packet sequence number in the receive buffer. When the preset time T or the accumulated number of received packets N is reached, the receiver triggers the acknowledgement mechanism and sends the received packet sequence number to the sender through an ACK packet. After receiving the ACK packet, the sender checks whether any packet is lost according to the rules. If any packet is lost, the sender resends the lost packet to the receiver. If the sender does not receive an ACK packet within 2T, it considers that the ACK packet is lost and resends the last packet. 3. A New ACK Packet Format TBD 4. Security Considerations 5. IANA Considerations This document has no requests to IANA. 6. Normative References Chen Expires 21 April 2025 [Page 4] Internet-Draft Network Working Group October 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Author's Address Danyang Chen China Mobile Beijing 100053 China Email: chendanyang@chinamobile.com Chen Expires 21 April 2025 [Page 5]