From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 4CDEE5A026F for ; Mon, 25 Sep 2023 08:59:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1695625154; bh=xQg98SgtdxOKU1C7tN4A+uG43Kb0WUrfIqq55xKMmSk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l4uUjEO+JQ0sKCncdEutwAiYP94ADnOR80JqJGIb7dFvIbhkF6NPo8SiYCPdI4rjk F/2Du/pH75uNDM+NoscnGjpn3WF46zM3ZwVkY9kXQfNEcBk2UMmTjBBOaiIGeRfGEh KY1ctaQtn10iyQwSUT05n7QqjHBTa0khbhmQefqY= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4RvDJ20lWfz4xKl; Mon, 25 Sep 2023 16:59:14 +1000 (AEST) Date: Mon, 25 Sep 2023 15:54:11 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH] tcp: Always send an ACK segment once the handshake is completed Message-ID: References: <20230922220637.59045-1-sbrivio@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PppwImrwdgWD/3yO" Content-Disposition: inline In-Reply-To: <20230922220637.59045-1-sbrivio@redhat.com> Message-ID-Hash: KJQHFCATR267T7JKTEEGMKOFWGLLZIU4 X-Message-ID-Hash: KJQHFCATR267T7JKTEEGMKOFWGLLZIU4 X-MailFrom: dgibson@gandalf.ozlabs.org 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 CC: passt-dev@passt.top 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: --PppwImrwdgWD/3yO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 23, 2023 at 12:06:37AM +0200, Stefano Brivio wrote: > The reporter is running a SMTP server behind pasta, and the client > waits for the server's banner before sending any data. In turn, the > server waits for our ACK after sending SYN,ACK, which never comes. >=20 > If we use the ACK_IF_NEEDED indication to tcp_send_flag(), given that > there's no pending data, we delay sending the ACK segment at the end > of the three-way handshake until we have some data to send to the > server. >=20 > This was actually intended, as I thought we would lower the latency > for new connections, but we can't assume that the client will start > sending data first (SMTP is the typical example where this doesn't > happen). >=20 > And, trying out this patch with SSH (where the client starts sending > data first), the reporter actually noticed we have a lower latency > by forcing an ACK right away. Comparing a capture before the patch: >=20 > 13:07:14.007704 IP 10.1.2.1.42056 > 10.1.2.140.1234: Flags [S], seq 17970= 34836, win 65535, options [mss 4096,nop,wscale 7], length 0 > 13:07:14.007769 IP 10.1.2.140.1234 > 10.1.2.1.42056: Flags [S.], seq 2297= 052481, ack 1797034837, win 65480, options [mss 65480,nop,wscale 7], length= 0 > 13:07:14.008462 IP 10.1.2.1.42056 > 10.1.2.140.1234: Flags [.], seq 1:22,= ack 1, win 65535, length 21 > 13:07:14.008496 IP 10.1.2.140.1234 > 10.1.2.1.42056: Flags [.], ack 22, w= in 512, length 0 > 13:07:14.011799 IP 10.1.2.140.1234 > 10.1.2.1.42056: Flags [P.], seq 1:51= 5, ack 22, win 512, length 514 >=20 > and after: >=20 > 13:10:26.165364 IP 10.1.2.1.59508 > 10.1.2.140.1234: Flags [S], seq 41659= 39595, win 65535, options [mss 4096,nop,wscale 7], length 0 > 13:10:26.165391 IP 10.1.2.140.1234 > 10.1.2.1.59508: Flags [S.], seq 9856= 07380, ack 4165939596, win 65480, options [mss 65480,nop,wscale 7], length 0 > 13:10:26.165418 IP 10.1.2.1.59508 > 10.1.2.140.1234: Flags [.], ack 1, wi= n 512, length 0 > 13:10:26.165683 IP 10.1.2.1.59508 > 10.1.2.140.1234: Flags [.], seq 1:22,= ack 1, win 512, length 21 > 13:10:26.165698 IP 10.1.2.140.1234 > 10.1.2.1.59508: Flags [.], ack 22, w= in 512, length 0 > 13:10:26.167107 IP 10.1.2.140.1234 > 10.1.2.1.59508: Flags [P.], seq 1:51= 5, ack 22, win 512, length 514 >=20 > the latency between the initial SYN segment and the first data > transmission actually decreases from 792=B5s to 334=B5s. This is not > statistically relevant as we have a single measurement, but it can't > be that bad, either. >=20 > Reported-by: cr3bs (from IRC) > Signed-off-by: Stefano Brivio Reviewed-by: David Gibson > --- > tcp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/tcp.c b/tcp.c > index 76b7b8d..39844eb 100644 > --- a/tcp.c > +++ b/tcp.c > @@ -2562,7 +2562,7 @@ static void tcp_conn_from_sock_finish(struct ctx *c= , struct tcp_tap_conn *conn, > * dequeue waiting for SYN,ACK from tap -- check now. > */ > tcp_data_from_sock(c, conn); > - tcp_send_flag(c, conn, ACK_IF_NEEDED); > + tcp_send_flag(c, conn, ACK); > } > =20 > /** --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --PppwImrwdgWD/3yO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmURIHwACgkQzQJF27ox 2GcGfxAAlX31/pfC+QEHQf3mBpf4Lk7tkkGhYKvl87Sgmr51BPw87Ieo4S45c38m DmtXUpfD1iNM7oLzlXEkBJxisAeX6lNv8+Uthf86fvCfFxmS+6GKntQ6NYq1FFfu YGM8cM6fXSWTjhb95ekEcwdAJuZgUlkqY+QUe18+b/d9OWTrj22qm7UUkIorv1gC wVAEXqZ6YPhuwk1OkOxwJ6dveP7M6rUaZwqkQkyAq/TNZKoYvkiAr+XUsOP+/AZI QDkI/+o3iPL/OOvobDDa5+2yA58HbelT9IVF3IDju5eUhiZXhQ1iBj9A4fJAi3fo 5snLBTXqp6EkTRFeYMrh0VW8XdLRSwX/t+yRpNODEmM8c8lzhGkHDTZlhqbxgxiL WjmDe/MojYrHiMwGIQsw55Rt79fWujAAlgm/6AA04VFnUMxxISCoZj+xSqvGCTIq 828N28MQR5yL7LgVFFhOFJCforsnHSSKjWM52xeBO8h81WFI1dpoehqx08SDdSAO lLeqkIVvazDTw1JSNdpK9gdxf9qyXUwpoo+D4z3HyUbX9hQL0a5AyxT88s/lRAKo jAy0QEDk0JkQOfayncAWHdIlZL9GvbFWNiEgWclVb/8AQuQmAPaH5I1qlxGhNIzZ Xy1pCBQaerqJWRTZ8igl/PInc0jc39ur9RNHHyxO/nrphMtbdvo= =TkOL -----END PGP SIGNATURE----- --PppwImrwdgWD/3yO--