1 |
* Michael Mol <mikemol@×××××.com> [120210 13:36]: |
2 |
> On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman <tsg@×××××××××.net> wrote: |
3 |
> > * Michael Mol <mikemol@×××××.com> [120210 12:51]: |
4 |
> > [..] |
5 |
> >> That's what I was talking about. Where I work, we use OpenVPN, |
6 |
> >> operating in UDP mode. This is after several bad experiences using it |
7 |
> >> in TCP mode. |
8 |
> >> |
9 |
> >> By "UDP mode" and "TCP mode", I mean OpenVPN's connections to other |
10 |
> >> OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's |
11 |
> >> connections operate over TCP (and thus it gets guarantee'd delivery), |
12 |
> >> you can create a situation where a tunneled TCP connection attempts to |
13 |
> >> push data faster than your Internet connection can allow because it |
14 |
> >> never gets any congestion feedback; OpenVPN was accepting packets |
15 |
> >> faster than it could shove them through, and was buffering the rest. |
16 |
> > |
17 |
> > So obviously OpenVPN wasn't handling congestion appropriately and should |
18 |
> > have been using some queueing discipline to discard instead of letting |
19 |
> > transmit queues grow unbounded. |
20 |
> |
21 |
> Sure, that contributed to the problem, and may qualify as a bug. On |
22 |
> the flip side, by operating OpenVPN in TCP mode, you're saying you |
23 |
> want guaranteed delivery across the link. |
24 |
|
25 |
Yes, certainly. And certainly TCP has far more resource requirements on the |
26 |
sending side. However, it also has congestion avoidance built in to it, |
27 |
which UDP does not. |
28 |
|
29 |
> |
30 |
> > |
31 |
> > But switching to UDP from TCP just pushes the problem off your OpenVPN |
32 |
> > gateway and onto the "outside" network. |
33 |
> > |
34 |
> > If you're really receiving more traffic than can be sent over the |
35 |
> > "outside" network, now you're relying on intermediate routers to "do the |
36 |
> > right thing" with your excess UDP traffic and most likely impacting TCP |
37 |
> > traffic through the same router. |
38 |
> |
39 |
> OpenVPN was running on the router on both ends. The sending side was |
40 |
> on the lean side of an ADSL modem, plugged directly into the same, so |
41 |
> the entire issue was handled locally. |
42 |
|
43 |
There was no infrastructure between the two routers? They had a direct |
44 |
connection between them? It would be slightly strange to go through the |
45 |
hassle of running OpenVPN in that case... |
46 |
|
47 |
> |
48 |
> Even if OpenVPN wasn't running on the router itself, there'd wouldn't |
49 |
> *be* excess UDP traffic when running OpenVPN in UDP mode, as |
50 |
> congestion management would be behaving properly. so other traffic |
51 |
> would not be unduly impacted. |
52 |
|
53 |
Why do you think congestion management would be behaving properly? What |
54 |
congestion management are you referring to for UDP traffic? |
55 |
|
56 |
The only thing intermediate routers can do in the case of congestion due |
57 |
to UDP traffic is to drop. And depending on the queueing implementation |
58 |
they may end up dropping TCP traffic as well. |
59 |
|
60 |
Almost certainly they'll signal congestion to TCP endpoints with traffic |
61 |
through them, hence impacting TCP traffic as well. |
62 |
|
63 |
Todd |