> On 14. Aug 2023, at 20:45, Paul Wouters <[email protected]> wrote: > > On Mon, 14 Aug 2023, Aseem Choudhary wrote: > >> 1. Yes, you're correct there is still reordering potentially happening >> between the endpoints of the tunnel. However, the intention >> behind using the subspace is to limit the potential reordering of packets at >> the tunnel endpoints. By assigning packets to specific >> subspaces based on factors such as CPU core or QoS, the aim is to manage and >> mitigate the reordering within each subspace, thereby >> improving the utilisation of multiple cores and QoS classes at the endpoint. >> The reordering happening in between the endpoint is >> less easily controllable and just like with using an SA today, would be >> handled by the replay window of each subspaces but they >> don’t need to be very big. > > But if you already bind subspaces to a CPU/core, why not just a whole IPsec > SA per core :-)
You can find some reasons in https://datatracker.ietf.org/doc/draft-mrossberg-ipsecme-multiple-sequence-counters/. For me the largest advantage is having a simpler failure semantic (either all sub-SAs fail or none), lower overhead and the clear strategy of SPI allocation, which eases NIC steering. Michael
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
