Jan:
> The only thing you can do, is to run something like Traffic Control (tc)
> on the link to prioritize low latency traffic compared to bulk downloads
Yes, I thought about it... the problem is that I usually transfer files
with scp and work over ssh, so it won't be as easy as simply prioritizing
one port over another... but prioritizing based on a packet size seems
doable.
Greg:
> The universal sign of a congested link is latencies going up by, easily,
> an order of magnitude, and little or no packet loss. [i.e. 30ms to
> 300ms, or even more] Once a connection reaches very high levels of
> utilization, latencies increase dramatically.
>
> So, the fact that OpenVPN does similar things seems unremarkable to me.
> [But perhaps I missed something more in the thread that does make it
> more remarkable...]
The problem is that my link is never "100% full", as ping times over the
Internet to the same host (and from the server to other, TCP and UDP
connected clients) during this "100% full load" are normal or only
slightly larger. I suspect (but haven't tested it yet) that if I used
another instance of OpenVPN to handle low-latency traffic, it would work
fine despite other instances being fully loaded.
Now I remember that definitely it worked this way when I had two machines
on the same network, connected over TCP. When I fully loaded the
connection from one client to the server, it was impossible to work
remotely and ping was huge, but the second connection (another machine,
same network) was mostly unaffected and still had both low latency and
plenty of bandwidth available.
Gert, Jan:
> I just re-ran the test and in one direction I've got the latency spikes
> under control (ping time < 70 ms). This is achieved by adding
> "--sndbuf 32000" on the client and "--rcvbuf 36000 --tcp-queue-limit 8"
> on the server.
Great, it helped! Now the ping time jumped from ~30ms to ~350ms, but it's
acceptable. Thank you! I'll experiment with these options to further
increase throughput.
David:
> Port sharing is a feature for the server side to "hide" OpenVPN behind
> an existing SSL/TLS based service (typically https). So packets which
> carries an OpenVPN signature will be processed by the OpenVPN process.
> Anything else will be sent to the provided IP address and port and the
> OpenVPN process will just act as a proxy.
>
> This happens on _all_ packets - OpenVPN packets and anything else, not
> just some or just during the initial handshake.
Strange. Are you sure about it? What would be a reason for this with TCP?
With UDP I perfectly see why (despite port-sharing being a TCP-only
feature), but with TCP? Once a connection is established and it's known
that it was an OpenVPN client thas has connected?
This seems consistent with this code from socket.c (stream_buf_added()):
#if PORT_SHARE
if (sb->port_share_state == PS_ENABLED)
{
if (!is_openvpn_protocol (&sb->buf))
{
msg (D_STREAM_ERRORS, "Non-OpenVPN client protocol detected");
sb->port_share_state = PS_FOREIGN;
sb->error = true;
return false;
}
else
sb->port_share_state = PS_DISABLED;
}
#endif
To summarize:
- if port sharing state is ENABLED
- if the protocol is not openvpn, we set state to FOREIGN
- if the protocol is openvpn, we set state to DISABLED
So it seems it works only on a first data packet, and I guess that states
are:
- ENABLED - we don't know yet if we're port-sharing, decision is to be made
- FOREIGN - we know that the first packet wasn't openvpn one, so from now we're
forwarding
- DISABLED - we know that the first packet was our, so from now we don't forward
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
