On Tue, Apr 30, 2024 at 6:02 AM, Steffen Klassert < steffen.klass...@secunet.com> wrote:
> 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. > Excellent, thank you. This is a nice, and helpful, explanation…. > We were asked to leave out 'implementation details', so the draft does not > say much about that. > That makes me sad, but Ok…. > 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." > Ah, yes, this makes sense now — I had understood it as "if the current CPU does not have any spare resources (e.g because it is super busy being a Quake server or trying to render a picture of a kitten)...". Your proposed changes fixes this… I will go clear my DISCUSS, and thank you very much for the tutorial. W > Steffen >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
