For example Juniper offers true per-packet, I think mostly used in
high performance computing.

At least on MX, what Juniper calls 'per-packet' is really 'per-flow'.  

On Wed, Sep 6, 2023 at 10:17 AM Saku Ytti <saku@ytti.fi> wrote:
On Wed, 6 Sept 2023 at 17:10, Benny Lyne Amorsen
<benny+usenet@amorsen.dk> wrote:

> TCP looks quite different in 2023 than it did in 1998. It should handle
> packet reordering quite gracefully; in the best case the NIC will

I think the opposite is true, TCP was designed to be order agnostic.
But everyone uses cubic, and for cubic reorder is the same as packet
loss. This is a good trade-off. You need to decide if you want to
recover fast from occasional packet loss, or if you want to be
tolerant of reordering.
The moment cubic receives frame+1 it expects, it acks frame-1 again,
signalling loss of packet, causing unnecessary resend and window size
reduction.

> will never even know they were reordered. Unfortunately current
> equipment does not seem to offer per-packet load balancing, so we cannot
> test how well it works.

For example Juniper offers true per-packet, I think mostly used in
high performance computing.

--
  ++ytti