Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Mol]

On Fri, Feb 10, 2012 at 2:21 PM, Todd Goodman <tsg@×××××××××.net> wrote:
> * Michael Mol <mikemol@×××××.com> [120210 13:36]:
>> On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman <tsg@×××××××××.net> wrote:
>> > * Michael Mol <mikemol@×××××.com> [120210 12:51]:
>> > [..]
>> >> That's what I was talking about. Where I work, we use OpenVPN,
>> >> operating in UDP mode. This is after several bad experiences using it
>> >> in TCP mode.
>> >>
>> >> By "UDP mode" and "TCP mode", I mean OpenVPN's connections to other
>> >> OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's
>> >> connections operate over TCP (and thus it gets guarantee'd delivery),
>> >> you can create a situation where a tunneled TCP connection attempts to
>> >> push data faster than your Internet connection can allow because it
>> >> never gets any congestion feedback; OpenVPN was accepting packets
>> >> faster than it could shove them through, and was buffering the rest.
>> >
>> > So obviously OpenVPN wasn't handling congestion appropriately and should
>> > have been using some queueing discipline to discard instead of letting
>> > transmit queues grow unbounded.
>>
>> Sure, that contributed to the problem, and may qualify as a bug. On
>> the flip side, by operating OpenVPN in TCP mode, you're saying you
>> want guaranteed delivery across the link.
>
> Yes, certainly.  And certainly TCP has far more resource requirements on the
> sending side.  However, it also has congestion avoidance built in to it,
> which UDP does not.

And that's perfectly fine, when you're going to be tunneling an entire
IP stack inside OpenVPN. If a tunneled application needs low latency,
low guarantee of delivery, it can use UDP. If a tunneled application
needs guarantee of delivery, it can use TCP. But if the OpenVPN tunnel
is itself using TCP, you lose low latency opportunities, and you deny
your tunneled applications' ability to respond to congestion.

>
>>
>> >
>> > But switching to UDP from TCP just pushes the problem off your OpenVPN
>> > gateway and onto the "outside" network.
>> >
>> > If you're really receiving more traffic than can be sent over the
>> > "outside" network, now you're relying on intermediate routers to "do the
>> > right thing" with your excess UDP traffic and most likely impacting TCP
>> > traffic through the same router.
>>
>> OpenVPN was running on the router on both ends. The sending side was
>> on the lean side of an ADSL modem, plugged directly into the same, so
>> the entire issue was handled locally.
>
> There was no infrastructure between the two routers?  They had a direct
> connection between them?  It would be slightly strange to go through the
> hassle of running OpenVPN in that case...

workstation - ovpn - ADSL 6Mbs/512Kbs - AT&T - ADSL(6Mbs/512Kbs) - ovpn - server

Both sides would be pushing up the weak end of ADSL, and both sides'
local routers would be discarding layer 3 packets that won't fit. AT&T
wouldn't even have seen the excess traffic.

>
>>
>> Even if OpenVPN wasn't running on the router itself, there'd wouldn't
>> *be* excess UDP traffic when running OpenVPN in UDP mode, as
>> congestion management would be behaving properly. so other traffic
>> would not be unduly impacted.
>
> Why do you think congestion management would be behaving properly?  What
> congestion management are you referring to for UDP traffic?

The fact that the tunneled TCP packets and fragments would be dropped,
causing the tunneled connections' relevant TCP stacks to scale back.

>
> The only thing intermediate routers can do in the case of congestion due
> to UDP traffic is to drop.  And depending on the queueing implementation
> they may end up dropping TCP traffic as well.

Which is *fine*, as long as the TCP packets are encapsulated inside
the tunnel, and the tunnel itself is UDP; the connection owners for
the encapsulated tunnels would scale back their throughput
automatically. If the TCP packet dropped is what's carrying the tunnel
itself, then one of the openvpn instances will resend, and the
encapsulated connection's packet will still ultimately reach its
destination.

>
> Almost certainly they'll signal congestion to TCP endpoints with traffic
> through them, hence impacting TCP traffic as well.

Not sure what you mean here.

Michael Orlitsky had a decent, relevant link:
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Though instead of stacking TCP/IP/PPP on top of SSH/TCP/IP, I was
packing IMAP/TCP/IP on top of OpenVPN/TCP/IP.

-- 
:wq