Hi, thanks for your review!
On Fri, Apr 26, 2024 at 02:38:27PM -0700, Warren Kumari via Datatracker wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-ipsecme-multi-sa-performance-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Be ye not afraid -- see > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > on > handling ballots, especially DISCUSS ballots... > > A DISCUSS is a request to have a discussion, and this is especially true in > this case, because my mental model is somewhat hazy here... > > The document talks about negotiating multiple "Child SAs with the same Traffic > Selectors". In my mental model, this looks sort of analogous to multiple > parallel paths. The document doesn't seem to discuss how implementations > should > share traffic across these "paths" -- should it do something like ECMP and > hash > <something, e.g 5-tuple> to try and keep packets in a flow tied to the same > CPU? Yes, packets of the same flow are tied to the same CPU. Modern NICs do a 'RSS hash' (RSS - Receive Side Scaling) over the headers and pin packets to CPUs based on the hash. Usually the NIC does this hashing based on L3/L4 headers by default. Until now, IPsec implementations had to disable this feature because this creates reorder if different inner flows match the same Child SA. With this draft, each CPU has its own Child SA, so that reorder problem goes away and we can use the RSS hash for IPsec. Also in the other direction, when receiving IPsec we had before just one Child SA per Traffic Selector. So all packets had the same SPI and could not be parallelized using a RSS hash. Now, each CPU has its own Child SA and with that its own SPI what makes RSS hasing possible. We were asked to leave out 'implementation details', so the draft does not say much about that. > Or is this something that is done automatically by the OS already (e.g > because the existing L3 logic would just view these as parallel links) and it > already knows what to do? Or is this something that IPSEC implementations > handle themselves? Or is my mental model so broken that my question doesn't > even make sense? Your mental model seems to be quite OK. > The document also says that "if an implementation finds it needs to encrypt a > packet but the current CPU does not have the resources to encrypt this packet, > it can relay that packet to a specific CPU that does have the capability to > encrypt the packet, although this will come with a performance penalty.". > Cool... but does this lead to the potential of out of order packets? Is that > what the "this will come with a performance penalty" is implying (in which > case > I'd suggest being a bit more explicit). The cited sentence has to be reworded, it is missleading. 'Not having the resources' means here 'there is currently no Chlid SA installed on that particular CPU'. To avoid packet loss, packets can be redirected to a different CPU until the SA comes up. Just move packets to a different CPU if the current CPU is overloaded would indeed introduce uncontrolled reorder. Maybe the sentence can be reworded like this: "if an implementation finds it needs to encrypt a packet but the current CPU does not have a CPU specific Child SA to encrypt this packet, it can relay that packet to another CPU that does have a Child SA in place to encrypt the packet, although this will come with a performance penalty." Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
