From nobody Tue Jul 18 04:03:59 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R4lgk2qpWz4ns13 for ; Tue, 18 Jul 2023 04:04:02 +0000 (UTC) (envelope-from mason@blisses.org) Received: from yangtze.blisses.org (yangtze.blisses.org [144.202.50.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4R4lgk01VHz4K8L for ; Tue, 18 Jul 2023 04:04:02 +0000 (UTC) (envelope-from mason@blisses.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blisses.org header.s=default header.b=ZCpswUFY; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 144.202.50.44 as permitted sender) smtp.mailfrom=mason@blisses.org; dmarc=pass (policy=quarantine) header.from=blisses.org Received: from contoocook.blisses.org (contoocook.blisses.org [68.238.57.52]) by yangtze.blisses.org (Postfix) with ESMTP id 8EE9F1775CF for ; Tue, 18 Jul 2023 00:04:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=blisses.org; s=default; t=1689653041; bh=qLjeTnHbKOm98YjaMkYpPo43xp3MzdDaKXiHU4GAISY=; h=Date:From:To:Subject:From; b=ZCpswUFYb0eY/dTzfcwmNal6amwBzxxZymh9RC2Cm6EggEg4mvQQGUE3QIpZjCNfk Z8mm5y69Tm5Bf9xZNW66LYwSoYpJ7o9syRylsM2gv99dakEnD6hpImnzy5wluSaQm2 uSMQJp25XQEgY4phUgCaaBmdVp3iIgtZDHqS/7SwgYo1CkjwqS4bS0Ov9FbJ85M1rX OTAryhBSmgou0dGDv3678QBQzq4hi8U0x2hfZHNJ7tJo11gJ7bIqE4YeytyJkrqDi8 2xJGoF1NhI1Pv1rU37WTphPb18c0UrdnIy8wkQDoOiZpkQaZKKPJFavXbzm+XrjtpF o2jrdnMjvyaJw== Date: Tue, 18 Jul 2023 00:03:59 -0400 From: Mason Loring Bliss To: freebsd-net@freebsd.org Subject: ACK filtering? Message-ID: List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IsH90HeIADRPm5aW" Content-Disposition: inline X-Spamd-Result: default: False [-6.00 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[blisses.org,quarantine]; RCVD_IN_DNSWL_MED(-0.40)[144.202.50.44:from,68.238.57.52:received]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[blisses.org:s=default]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; ASN(0.00)[asn:20473, ipnet:144.202.48.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[blisses.org:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4R4lgk01VHz4K8L X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N --IsH90HeIADRPm5aW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm likely going to have to move to an Internet connection with asymmetric bandwidth soon, and I want to be proactive with the firewalling to avoid the connection choking on itself. There's a fair amount of documentation out there for bumping the priority on acks with pf and altq, and that seems reasonable, but is there anything equivalent I can do with ipfw? I'd prefer ipfw if possible, but I'll switch if I need to. Second, in researching the topic, because it's been some time, I encountered the notion of ACK filtering. Here's a link: https://lwn.net/Articles/758353/ =46rom that link: The last major component of CAKE is ACK filtering. A stream of data flowing in one direction over a TCP connection will generate a corresponding stream of acknowledgment (ACK) packets heading the other way. The ACK traffic is much smaller than the actual data, but it can still reach problematic levels on asymmetric links like those found in many home links. Much of that data will be redundant: if an ACK packet for the first 10,000 bytes is immediately followed by an ACK for the first 20,000 bytes, the first can often be dropped with no ill effect. Since CAKE maintains per-flow queues of packets, it is relatively easy for it to tell when a newly queued ACK packet makes an earlier one redundant. Some care must be taken, though, to only drop ACK packets that contain no other data, or bad things will happen. The ACK filtering also will not touch packets that contain unknown headers; that is an attempt to avoid protocol ossification that could break future extensions. I'm not seeing anything talking about ACK filtering in FreeBSD. It seems like the best of both worlds would be higher-priority ACK packets outbound, but with those that can be safely discarded discarded. Have I simply missed the documentation, or does this concept not exist as such right now in FreeBSD? (How about in OpenBSD?) It seems like the concept has been batted about for a while: https://dl.acm.org/doi/10.5555/646461.693587 --=20 Mason Loring Bliss mason@blisses.org Ewige Blumenkra= ft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scen= e I --IsH90HeIADRPm5aW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmS2Dy4ACgkQnrJXcHbv JVXNOBAAmxX7npLnxQ7MzSqP/11HQmUis0o7vFCpLB8zconw0G7sf+73BrbGaYGw Yfze+i4WZxy5knSew20gYMvsmRIpC8E5Z1C3Opvfuhps9YK8u+9O17mUxM2Bwo1r KmEGAk8dMsTI8jBJMxuwKrFYLzRoeuOHUG2rXistVFCSy6ukIsnkg1jqQqCLEdA0 gwlVWK/TZMbszWXa5bEatCQeV5oovdj85uF0/Cj+qkDH0oJKI1eLierHP1NAAUXl utyjcOOCzLtn4RFgkYJbl6hpoAurM8EMJcBRDFbSpDVDdTDtO9YJAfcrcyxY3Aoa h98gBGaq/aDf+W+2zQdXk1IlsNpL0965FXIS2q91WR2gBbCOzrETAA7ZmttqV4s3 lC5evmsJaR8zlYA7leLYQ+kVQ74Mcfgpf/5zuImOZTWZCAyScY+Zxjq3KlR2VPC0 c2+OapQcmoSdiX2/7R6jCDVI9Ubmmxmf+ULiV6ejPQobcxkZpEKoH3NiYYz4y5t9 gBApAQZTL4ADWQOF8bZbNTL8XSb7x/2n9oSIex+daCQyWCbjcNCU3aYz8vmm+twn PNJWeplLbuLzAP+B4VqC+6W5Ud81aEF2XEwJRQLpYAwAMfR6X+psG2FtvNy8+TtZ hQlKC57cwVKxNHMn+M1EOTAk2U/wiw9zeDi1+uRs7Y6oX2pyZ5c= =0Ka8 -----END PGP SIGNATURE----- --IsH90HeIADRPm5aW--