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? 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? 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). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think that this document is both cool and useful -- my discuss ballot is because I'd like to better understand how this works.... _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
