From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 286FE5A02E0 for ; Wed, 15 May 2024 17:34:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715787273; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0aJ6DxsZKAFbGUlQdkrbkLuemZYwPEsl5YTqzCcK8Ws=; b=KEKCI/B6F1rQAAxUazBN1r7M93riYnKy/JDom9RW9BCQenEnsenGxBn77sDaF0j2PdweO5 0CnkIRx0XzPUwjwyZx4QwMcQfZQJ9P/YQkkoyV4Df2FbE/J1jt1BuENM8p63xabJ7XJOUp W12AyR8P/0pbW98TJTGHRfXlBWEGY8s= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-360-aswEV7zWNz6WCLiJIvt_7w-1; Wed, 15 May 2024 11:34:31 -0400 X-MC-Unique: aswEV7zWNz6WCLiJIvt_7w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 71D54801211 for ; Wed, 15 May 2024 15:34:31 +0000 (UTC) Received: from fenrir.redhat.com (unknown [10.22.8.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 14FA0561A; Wed, 15 May 2024 15:34:31 +0000 (UTC) From: Jon Maloy To: passt-dev@passt.top, sbrivio@redhat.com, lvivier@redhat.com, dgibson@redhat.com, jmaloy@redhat.com Subject: [PATCH v4 3/3] tcp: allow retransmit when peer receive window is zero Date: Wed, 15 May 2024 11:34:29 -0400 Message-ID: <20240515153429.859185-4-jmaloy@redhat.com> In-Reply-To: <20240515153429.859185-1-jmaloy@redhat.com> References: <20240515153429.859185-1-jmaloy@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true Message-ID-Hash: VKUWC5A2NQ3OIVBA7RECVBMYXPEZM2YA X-Message-ID-Hash: VKUWC5A2NQ3OIVBA7RECVBMYXPEZM2YA X-MailFrom: jmaloy@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: A bug in kernel TCP may lead to a deadlock where a zero window is sent from the peer, while it is unable to send out window updates even after reads have freed up enough buffer space to permit a larger window. In this situation, new window advertisemnts from the peer can only be triggered by packets arriving from this side. However, such packets are never sent, because the zero-window condition currently prevents this side from sending out any packets whatsoever to the peer. We notice that the above bug is triggered *only* after the peer has dropped an arriving packet because of severe memory squeeze, and that we hence always enter a retransmission situation when this occurs. This also means that it goes against the RFC 9293 recommendation that a previously advertised window never should shrink. RFC 9293 gives the solution to this situation. In chapter 3.6.1 we find the following statement: "A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left (SHLD-14). However, a sending TCP peer MUST be robust against window shrinking, which may cause the "usable window" (see Section 3.8.6.2.1) to become negative (MUST-34). If this happens, the sender SHOULD NOT send new data (SHLD-15), but SHOULD retransmit normally the old unacknowledged data between SND.UNA and SND.UNA+SND.WND (SHLD-16). The sender MAY also retransmit old data beyond SND.UNA+SND.WND (MAY-7)" We never see the window become negative, but we interpret this as a recommendation to use the previously available window during retransmission even when the currently advertised window is zero. We use the above mechanism only at timer-induced retransmits. In the case we receive duplicate ack and a zero window, but still know we have outstanding data acks waiting, we send out an empty "fast probe" instead of doing fast retransmit. This averts the risk of overwhelming a memory squeezed peer with retransmits, while still forcing it to send out a new window update when the probe is received. This entails a theoretical risk of redundant retransmits from the peer, but that is a risk worth taking. In case of a zero-window non-retransmission situation where there is no new data to be sent, we also add a simple zero-window probing feature. By sending an empty packet at regular timeout events we resolve the situation described above, since the peer receives the necessary trigger to advertise its window once it becomes non-zero again. It should be noted that although this solves the problem we have at hand, it is not a genuine solution to the kernel bug. There may well be TCP stacks around in other OS-es which don't do this, nor have keep-alive probing as an alternatve way to solve the situation. Signed-off-by: Jon Maloy --- v2: - Using previously advertised window during retransmission, instead highest send sequencece number in the cycle. v3: - Rebased to newest code - Changes based on feedback from PASST team - Sending out empty probe message at timer expiration when we are not in retransmit situation. v4: - Some small changes based on feedback from PASST team. - Replaced fast retransmit with a one-time 'fast probe' when window is zero. --- tcp.c | 32 +++++++++++++++++++++++++++----- tcp_conn.h | 2 ++ 2 files changed, 29 insertions(+), 5 deletions(-) diff --git a/tcp.c b/tcp.c index 4163bf9..a33f494 100644 --- a/tcp.c +++ b/tcp.c @@ -1761,9 +1761,15 @@ static void tcp_get_tap_ws(struct tcp_tap_conn *conn, */ static void tcp_tap_window_update(struct tcp_tap_conn *conn, unsigned wnd) { + uint32_t wnd_edge; + wnd = MIN(MAX_WINDOW, wnd << conn->ws_from_tap); conn->wnd_from_tap = MIN(wnd >> conn->ws_from_tap, USHRT_MAX); + wnd_edge = conn->seq_ack_from_tap + wnd; + if (wnd && SEQ_GT(wnd_edge, conn->seq_wnd_edge_from_tap)) + conn->seq_wnd_edge_from_tap = wnd_edge; + /* FIXME: reflect the tap-side receiver's window back to the sock-side * sender by adjusting SO_RCVBUF? */ } @@ -1796,6 +1802,7 @@ static void tcp_seq_init(const struct ctx *c, struct tcp_tap_conn *conn, ns = (now->tv_sec * 1000000000 + now->tv_nsec) >> 5; conn->seq_to_tap = ((uint32_t)(hash >> 32) ^ (uint32_t)hash) + ns; + conn->seq_wnd_edge_from_tap = conn->seq_to_tap; } /** @@ -2205,13 +2212,12 @@ static void tcp_data_to_tap(const struct ctx *c, struct tcp_tap_conn *conn, */ static int tcp_data_from_sock(struct ctx *c, struct tcp_tap_conn *conn) { - uint32_t wnd_scaled = conn->wnd_from_tap << conn->ws_from_tap; int fill_bufs, send_bufs = 0, last_len, iov_rem = 0; int sendlen, len, dlen, v4 = CONN_V4(conn); + uint32_t already_sent, max_send, seq; int s = conn->sock, i, ret = 0; struct msghdr mh_sock = { 0 }; uint16_t mss = MSS_GET(conn); - uint32_t already_sent, seq; struct iovec *iov; /* How much have we read/sent since last received ack ? */ @@ -2225,19 +2231,24 @@ static int tcp_data_from_sock(struct ctx *c, struct tcp_tap_conn *conn) tcp_set_peek_offset(s, 0); } - if (!wnd_scaled || already_sent >= wnd_scaled) { + /* How much are we still allowed to send within current window ? */ + max_send = conn->seq_wnd_edge_from_tap - conn->seq_to_tap; + if (SEQ_LE(max_send, 0)) { + flow_trace(conn, "Empty window: win_upper: %u, sent: %u", + conn->seq_wnd_edge_from_tap, conn->seq_to_tap); + conn->seq_wnd_edge_from_tap = conn->seq_to_tap; conn_flag(c, conn, STALLED); conn_flag(c, conn, ACK_FROM_TAP_DUE); return 0; } /* Set up buffer descriptors we'll fill completely and partially. */ - fill_bufs = DIV_ROUND_UP(wnd_scaled - already_sent, mss); + fill_bufs = DIV_ROUND_UP(max_send, mss); if (fill_bufs > TCP_FRAMES) { fill_bufs = TCP_FRAMES; iov_rem = 0; } else { - iov_rem = (wnd_scaled - already_sent) % mss; + iov_rem = max_send % mss; } /* Prepare iov according to kernel capability */ @@ -2466,6 +2477,13 @@ static int tcp_data_from_tap(struct ctx *c, struct tcp_tap_conn *conn, conn->seq_to_tap = max_ack_seq; tcp_set_peek_offset(conn->sock, 0); tcp_data_from_sock(c, conn); + } else if (!max_ack_seq_wnd && SEQ_GT(conn->seq_to_tap, max_ack_seq)) { + /* Force peer to send new advertisement now, but only once */ + flow_trace(conn, "fast probe, ACK: %u, previous sequence: %u", + max_ack_seq, conn->seq_to_tap); + tcp_send_flag(c, conn, ACK); + conn->seq_to_tap = max_ack_seq; + tcp_set_peek_offset(conn->sock, 0); } if (!iov_i) @@ -2911,6 +2929,10 @@ void tcp_timer_handler(struct ctx *c, union epoll_ref ref) flow_dbg(conn, "activity timeout"); tcp_rst(c, conn); } + /* No data exchanged recently? Keep connection alive. */ + if (conn->seq_to_tap == conn->seq_ack_from_tap && + conn->seq_from_tap == conn->seq_ack_to_tap) + tcp_send_flag(c, conn, ACK); } } diff --git a/tcp_conn.h b/tcp_conn.h index d280b22..5cbad2a 100644 --- a/tcp_conn.h +++ b/tcp_conn.h @@ -30,6 +30,7 @@ * @wnd_to_tap: Sending window advertised to tap, unscaled (as sent) * @seq_to_tap: Next sequence for packets to tap * @seq_ack_from_tap: Last ACK number received from tap + * @seq_wnd_edge_from_tap: Right edge of last non-zero window from tap * @seq_from_tap: Next sequence for packets from tap (not actually sent) * @seq_ack_to_tap: Last ACK number sent to tap * @seq_init_from_tap: Initial sequence number from tap @@ -101,6 +102,7 @@ struct tcp_tap_conn { uint32_t seq_to_tap; uint32_t seq_ack_from_tap; + uint32_t seq_wnd_edge_from_tap; uint32_t seq_from_tap; uint32_t seq_ack_to_tap; uint32_t seq_init_from_tap; -- 2.42.0