Re: [GNUnet-developers] GNUnet VPN/EXIT performance over wifi and loopback

[Christian Grothoff]

Hi!

On 08/08/2015 06:37 PM, Daniel Golle wrote:
> Hi Christian,
> 
> I'm hoping to really reach everyone interested this time in this
> email ;)
> 
>> > Hi!
>> > 
>> > The cipher is a variant of Axolotl, so repeated ECDHE on Curve25519,
>> > SHA-512 key ratcheting for each message, and Twofish+AES for symmetric
>> > encryption.  This (kind of) encryption is done TWICE, once at the link
>> > layer, and then also end-to-end.
> Thanks for the info, that's the precise answer to the question I was
> hoping for.
> 
>> > 
>> > Comparing loopback performance of an encrypted system with cleartext is
>> > IMO totally useless -- you're just measuring the CPU speed for the
>> > ciphers, and in our case they're rather expensive.  Not to mention on a
>> > real network, I'd imagine bandwidth/latency to be the critical factor,
>> > not CPU speed.
> Well, it helped to get a general impression of the performance to be
> expected, especially when comparing with the results below.
> (the results on an actual MIPS SoC look very similar to what I sent
> before)
> 
> So these are the results when running iperf3 between two routers
> connected via WiFi (IBSS mode).
> 
> address@hidden:~# iperf3 -c 10.82.1.2
> Connecting to host 10.82.1.2, port 5201
> [  4] local 10.82.2.2 port 53015 connected to 10.82.1.2 port 5201
> [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> [  4]   0.00-1.01   sec  2.30 MBytes  19.2 Mbits/sec    0   49.5 KBytes       
> [  4]   1.01-2.00   sec  2.68 MBytes  22.6 Mbits/sec    0   72.1 KBytes       
> [  4]   2.00-3.00   sec  2.46 MBytes  20.6 Mbits/sec    0   77.8 KBytes       
> [  4]   3.00-4.00   sec  4.42 MBytes  37.1 Mbits/sec    0    112 KBytes       
> [  4]   4.00-5.01   sec  3.88 MBytes  32.4 Mbits/sec    0    124 KBytes       
> [  4]   5.01-6.00   sec  4.53 MBytes  38.2 Mbits/sec    0    139 KBytes       
> [  4]   6.00-7.00   sec  5.12 MBytes  43.0 Mbits/sec    0    214 KBytes       
> [  4]   7.00-8.00   sec  6.67 MBytes  56.0 Mbits/sec    0    277 KBytes       
> [  4]   8.00-9.02   sec  6.88 MBytes  56.3 Mbits/sec    0    277 KBytes       
> [  4]   9.02-10.00  sec  5.88 MBytes  50.6 Mbits/sec    0    277 KBytes       
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-10.00  sec  44.8 MBytes  37.6 Mbits/sec    0             sender
> [  4]   0.00-10.00  sec  44.5 MBytes  37.3 Mbits/sec                  receiver
> 
> iperf Done.
> 
> Now with gnunet-vpn in between the two (connected over the same single
> wireless hop as above, using UDP transport):
> 
> address@hidden:~# iperf3 -c 10.11.155.173
> Connecting to host 10.11.155.173, port 5201
> [  4] local 10.11.10.1 port 42761 connected to 10.11.155.173 port 5201
> [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> [  4]   0.00-1.00   sec  42.4 KBytes   347 Kbits/sec    0   14.1 KBytes       
> [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    6   9.90 KBytes       
> [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   9.90 KBytes       
> [  4]   3.00-4.00   sec  22.6 KBytes   185 Kbits/sec    0   12.7 KBytes       
> [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   12.7 KBytes       
> [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   14.1 KBytes       
> [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   17.0 KBytes       
> [  4]   7.00-8.00   sec  55.1 KBytes   452 Kbits/sec    0   21.2 KBytes       
> [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   25.5 KBytes       
> [  4]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    0   29.7 KBytes       
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-10.00  sec   120 KBytes  98.5 Kbits/sec    6             sender
> [  4]   0.00-10.00  sec  66.5 KBytes  54.4 Kbits/sec                  receiver
> 
> iperf Done.

Interesting, I wonder if the 0-throughput periods are because of
1) CADET crashes (did it ever?)
2) the CORE issue you mention below, or
3) something entirely different

> Given the loopback results, I was expecting something better here as
> well :(
> 
> The only hint of anything potentially going fundamentally wrong are
> repeating error messages on the log:
> Aug 08 17:35:51-003724 cadet-p2p-5380 ERROR  core wait time 1133613 µs > 1 
> second

Yes, that's a diagnostic for a known issue I didn't yet have time to
investigate.

> As the throughput is very bursty, my first assumption was that buffer
> bloat is also one of the problems we are hitting here.
> Looking at the results, Dave Tath suggested to simultanously measure
> both, bandwidth and latency in order to detect bufferbloat.
> Hence it would be nice if gnunet-vpn could carry at least basic
> ICMP (echo-request, echo-reply) in addition to the setup UDP and TCP
> redirects.

Eh, I think in principle ICMP is supported, ICMP IPv4/IPv6-PT is limited
to where reasonably closely matching ICMP message types exist. But you
should be able to use ICMP over the VPN as-is. The only thing you cannot
do is run an "ICMP service".

However, enabling an ICMP tunnel and getting a suitable exit policy
might be tricky...

One method to do this *could* be to setup a TCP or UDP tunnel and then
use the same VPN IP address.  At least ICMP replies will definitively
work that way (or did when I last tested it), but I don't see why ICMP
PING shouldn't work just as well (as long as the exit knows how to deal
with the packet...).  Anyway, the logic in gnunet-daemon-exit suggests
that for ICMP it tries to re-use existing TCP/UDP rules, just ignoring
the ports...

Please let me know if you can't get it to work quickly, in that case
I'll probably try to find time at the camp to investigate...

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature