Feature request: Parallel TCP connections

[vehlwn]

Do you intend to implement parallel websocket tunnel connections? This can improve performance of TCP network in use cases with active load.

[erebe]

Hello,

I am not sure to understand what you mean :O

[vehlwn]

I suggest flag --count for wstunnel client which creates multiple websockets streams to the wstunnel server. These streams are connected to the same UDP allocation (in UDP mode) and all of them can be evenly used as tunnel transport for the same client.

[erebe]

You mean something like ?

 -c, --connection-min-idle <INT>
          Client will maintain a pool of open connection to the server, in order to speed up the connection process.
          This option set the maximum number of connection that will be kept open.
          This is useful if you plan to create/destroy a lot of tunnel (i.e: with socks5 to navigate with a browser)
          It will avoid the latency of doing tcp + tls handshake with the server [default: 0] 

If yes, it already exists in the CLI. The option already pre-establish N connection to the server, so new tunnel can use them.

[vehlwn]

connection-min-idle

This is not exactly what I want. This option only sets size of a TCP connection pool on bb8::Pool struct. I ran wstunnel client with option -c 10 and when I send data over UDP proxy I see only one websocket HTTP handshake in tcpdump. All my data is being sent over one specific TCP stream. I expected multiple websocket streams to carry proxied data.

[erebe]

ha, I understand better, thanks for the clarification.

UDP proxy will use 1 TCP/websocket connection per client. A client is determined by its source IP and port.

So as long as it is the same client that send UDP packets, it will use only 1 connection. If you have multiple clients, it will use multiple transport connection (TCP/websocket)

If this is your point, there is no benefit to load balance a single client over multiple TCP streams, because:

• You increase the risk for packet loss, out of order transmission, ...
• Each connection, need to increase its TCP window scaling separately, so for throughput it will be slower to warmup.

[vehlwn]

You increase the risk for packet loss, out of order transmission

It should be a problem for higher level protocols because WireGuard works at L3.

[erebe]

(at L4, not L3)

Yes, but this is not without caveat. Even if the protocol can manage it, this usually means more jitter/latency and/or less throughput, as you have to recover from the situation.

Take an example at TCP, you can suffer packet loss, that's fine, but it will reduce your RTT/ping or your throughput. (TCP window scaling is based on packet loss)

[vehlwn]

(at L4, not L3)

If you mean UDP sockets, than you're right. But as a network tunnel WG operates at L3 like OpenVPN, which is pointed in the WG whitepaper.

Take an example at TCP

Yeah, I didn't think about TCP proxy. This feature only makes sense for UDP proxy because of it unreliable and unordered nature.

[vehlwn]

--connection-min-idle

Moreover, this option does not work well when wstunnel server is behind a nginx reverse proxy. Nginx has client_header_timeout option defaulted to 60 s. This causes additional overhead for wstunnel client to reestablish TCP and SSL connections.

[erebe]

Indeed, but this still does provide some speed-up establishing a new tunnel, as even with the client_header_timeout at 60s, the client is more likely to find an already established cnx than not. Regarding the churn/downside of opening/destroying/re-opening cnx after 60sec, it is not really an issue as it is mostly io/wait time.

I am closing the ticket, as I don't think, or not convince, that load balancing UDP packets across N tcpstream will bring anything. Feel free to fork the project to toy with your idea or re-open the ticket with a clear case with benefit & caveats