All of these were resolved in -06 Paul
Sent using a virtual keyboard on a phone > On Mar 20, 2024, at 15:33, Roman Danyliw <r...@cert.org> wrote: > > Hi! > > Thanks for the quick response. Below is a bit more editorial back-and-forth > for small number of issues. All of the other discussion removed from the > thread made sense for the future -06 that can go to IETF LC. > >> -----Original Message----- >> From: Paul Wouters <p...@nohats.ca> >> Sent: Wednesday, March 20, 2024 12:26 AM >> To: Roman Danyliw <r...@cert.org> >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05 >> >> Warning: External Sender - do not click links or open attachments unless you >> recognize the sender and know the content is safe. >> >> >>> On Tue, 19 Mar 2024, Roman Danyliw wrote: >>> >>> I performed an AD review of draft-ietf-ipsecme-multi-sa-performance-05. I >> have a mostly editorial feedback below: >>> > > [snip] > >> And answering that: >> >> Most IPsec implementations are currently limited to using one >> hardware queue or a single CPU resource for a Child SA. Paralyzing >> the packet encryption can be done, but there is a bottleneck of >> different parts of the hardware locking or waiting to get their >> sequence number assigned for the packet it is enrypting. The >> result is that a machine with many such resources is limited to >> only using one of these resources per Child SA. This severely >> limits the throughput that can be attained. For example, at the >> time of writing, an unencrypted link of 10Gbps or more is commonly >> reduced to 2-5Gbps when IPsec is used to encrypt the link using >> AES-GCM. By using the implementation specified in this document, >> aggregate throughput increased from 5Gbps using 1 CPU to 40-60 >> Gbps using 25-30 CPUs. > > Maybe s/Paralyzing the packet encryption/Running packet steam encryption in > parallel/ > > Also. s/enrypting/encrypting/. > > Otherwise, LGTM. > > [snip] > >>> ** Section 4. Is this section normative? Why are RFC2119 key words used in >> an example? >> >> Why do you say this is an example? It is the Implementation Considerations >> section telling you to do or do not some things? > > ==[ snip ]== > There are various considerations that an implementation can use to > determine the best way to install multiple Child SAs. Below are > examples of such strategies. > ==[ snip ]== > > I inferred this text to be non-normative and only examples because the second > sentence said these were "examples". Maybe just drop that second sentence to > eliminate confusion? > >>> ** Section 6. >>> Peers SHOULD be lenient with the maximum number of Child SAs they >>> allow for a given TSi/TSr combination to account for corner cases. >>> >>> What does “lenient” mean here? >> >> "account for corner cases" as explained further done? >> >> Eg one should not use a hard max of 4 when one runs on a 4-CPU system. > > Consider if "flexible" is what you want here instead. > > Roman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
