>
> 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
>

Reply via email to