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

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 <rdd@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 <paul@nohats.ca>
>> Sent: Wednesday, March 20, 2024 12:26 AM
>> To: Roman Danyliw <rdd@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