[Jool-list] BIB-less NAT64

[Alberto Leiva]

It's strange that the third stream pushed the SIIT further when the NAT64
was already at 100% it the second stream. I'd have expected the load to be
the same since the NAT64 could not, in theory, send the SIIT any more
packets. Or am I misunderstanding something?

Also, I'm really stumped that you managed to peak using only two streams.
This should render all database lookups practically instantaneous. If this
is the case then... yeah. I guess there's not much I will be able to do
from code.

But we'll see.

On Fri, Sep 15, 2017 at 12:18 PM, Alan Whinery <whinery at hawaii.edu> wrote:

>
> Sort of a digression, but since Alberto referred to Linux router
> performance --
>
> After I got the Jool/Jool v6-only NAT64/bitw-464CLAT scenario working, I
> tried some file transfers at 100 Mbps to v4-numeric addresses, so it was
> hitting both boxes (VMs, actually).  Watching the software interrupt load
> with top, I was getting around 10% load on the first 100 Mbps stream and a
> second stream pushed NAT64 to 100% load on SI, while CLAT was only doing
> about  30%, third stream 100% NAT64, 90% CLAT.
>
> Attached PDF is what I wrote when I still remembered, about increasing
> cores and spreading CPU affinity to mitigate.
>
> The point being that there are things to be understood about Linux router
> performance, in tandem with NAT64/SIIT performance. For one, rolling in the
> right off-loading, coalescence, etc, as well as CPU affinity to tune the
> box like a router, rather than as a host. This stuff is might be a problem
> well before you get to the network scale that has been tested with TRex.
>
> On 9/15/2017 5:49 AM, Alberto Leiva wrote:
>
> Thank you!
>
> > One thing I have been wondering about is if the TRex side gets confused
> and Jool is actually ok. If that is the case then I apologise!
>
> Well, who knows. I'm thinking that, if a normal Linux router would pass a
> similar test but a NAT64 Linux with Jool doesn't, then there should in
> theory be something that can be done.
>
> > What would be the best way to check that? Massive pcaps?
>
> I will compile a version with a bunch of timestamp tracking and see if we
> can get some conclusions out of it.
>
> Working...
>
> On Fri, Sep 15, 2017 at 5:24 AM, Sander Steffann <sander at steffann.nl>
> wrote:
>
>> Hi,
>>
>> > Okay, guys. Prototype ready. I didn't test a gazillion connections, but
>> as far as basic functionality goes, it looks stable. Don't quote me on
>> that, though.
>> >
>> > Experimental branch in fake-nat64, in case anyone wants to try it out:
>> https://github.com/NICMx/Jool/tree/fake-nat64
>>
>> Sorry, it still collapses :(
>>
>> I recorded a small test here: http://www.steffann.nl/sander/
>> Fake%20NAT64%20collapse.mov
>>
>> The behaviour is really strange. One thing I have been wondering about is
>> if the TRex side gets confused and Jool is actually ok. If that is the case
>> then I apologise! What would be the best way to check that? Massive pcaps?
>>
>> Cheers,
>> Sander
>>
>>
>
>
> _______________________________________________
> Jool-list mailing listJool-list at nic.mxhttps://mail-lists.nic.mx/listas/listinfo/jool-list
>
>
>
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail-lists.nic.mx/pipermail/jool-list/attachments/20170915/7419dec8/attachment.html>