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

...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 --- 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