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