> > 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 <s...@ytti.fi> wrote: > On Wed, 6 Sept 2023 at 17:10, Benny Lyne Amorsen > <benny+use...@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 >
