> On Dec 3, 2019, at 3:10 AM, Steffen Klassert <[email protected]>
> wrote:
> On Mon, Dec 02, 2019 at 10:57:59AM -0500, Christian Hopps wrote:
>>
>> Technically though, attaching a packet ID to the fragments to allowing
>> sending them in any order saves only a little on code complexity (i.e., not
>> using an ordering queue) on the sender side;
>
> I hoped to avoid such an ordering/serialization queue as I fear
> this will become a bottleneck. With the current design, I don't
> see how to do this without a queue. I know, it is an implementation
> detail, but implementation matters too :)
Absolutely.
>> however, it seems to add a disproportionate amount of complexity to the
>> receiver/reassembly (which could e.g., be aggregating VPN server).
>
> Yes, if you know that the next fragment comes with the next ESP
> packet, things are much easier. So we have the complexity either
> at the sender or the receiver side, not so sure what performs better.
FWIW, we will have some implementation/operational experience here to look at,
as a WG, prior to making any final choices. I'm currently working to code this
for running over a 100G link in a whitebox setup, and I will report back to the
WG when we have some numbers. :)
Thanks,
Chris.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
