On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman <t...@bonedaddy.net> wrote:
> * Michael Mol <mike...@gmail.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.

>
> 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.

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.

-- 
:wq

Reply via email to