Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05

[Roman Danyliw <[e-mail]>]

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 <[e-mail]>
> Sent: Wednesday, March 20, 2024 12:26 AM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]
> 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