[PATCH 4/4] tcp: On partial send (incomplete sendmsg()), request a retransmission right away

[Stefano Brivio <sbrivio@redhat.com>]

...possibly with an updated window value. As we're discarding the
remaining data, we'll need to receive it again. If we don't request
a retransmission immediately, we'll see an apparent gap in the
sequence, and request a retransmission on the next data batch or
segment, but we're just wasting time like that. In packets:

28686   0.000007 88.198.0.164 → 93.235.151.95 16118 TCP 55414 → 47080 [ACK] Seq=80501 Ack=141 Win=65536 Len=16064 [TCP segment of a reassembled PDU]
28687   0.000012 88.198.0.164 → 93.235.151.95 16118 TCP [TCP Window Full] 55414 → 47080 [ACK] Seq=96565 Ack=141 Win=65536 Len=16064 [TCP segment of a reassembled PDU]

on this second data segment, we have a short sendmsg(), and

28688   0.000026 93.235.151.95 → 88.198.0.164 54 TCP 47080 → 55414 [ACK] Seq=141 Ack=90721 Win=32128 Len=0

consequently acknowledge it, without requesting a retransmission,

28689   0.000006 88.198.0.164 → 93.235.151.95 8866 HTTP HTTP/1.1 200 ok  (text/css)

so the server proceeds sending a bit more, but

28690   0.000016 93.235.151.95 → 88.198.0.164 54 TCP [TCP Dup ACK 28688#1] 47080 → 55414 [ACK] Seq=141 Ack=90721 Win=32128 Len=0
28691   0.000000 93.235.151.95 → 88.198.0.164 54 TCP [TCP Dup ACK 28688#2] 47080 → 55414 [ACK] Seq=141 Ack=90721 Win=32128 Len=0

we'll throw that data (from frame #28689) away, and finally request
a retransmission as we spotted the gap now.

Request a retransmission as soon as we know we'll need it, instead.

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
---
 tcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tcp.c b/tcp.c
index 5a7a607..ae5e7a1 100644
--- a/tcp.c
+++ b/tcp.c
@@ -1876,7 +1876,7 @@ eintr:
 	}
 
 out:
-	if (keep != -1) {
+	if (keep != -1 || partial_send) {
 		/* We use an 8-bit approximation here: the associated risk is
 		 * that we skip a duplicate ACK on 8-bit sequence number
 		 * collision. Fast retransmit is a SHOULD in RFC 5681, 3.2.
-- 
2.43.0