[OpenWireless Tech] openvpn bandwith throttling?

["Andy Green (林安廸)"]

On 12/02/2012 12:16 PM, the mail apparently from Christian Huitema included:
>> Here's a suggestion... in vpn-only case the APs all issue the same BSSID
> and have
>> the same logical connection in NetworkManager or whatever.
>> Just set it to 500 there and 500 in all the compatible APs.  The cost of
> running
>> too low a mtu is just the ratio of UDP/IP headers to data increases, so
> efficiency
>> takes a little hit.  But all those problems mentioned above disappear.
> 
> The IPv6 minimum MTU is 1280 bytes. Settling on 500 would be somewhat
> suboptimal.

Yes, I pulled 500 from my experience with running over a 3G network in
Taiwan.  Really that is not the general idea for this, which would be
WLAN AP on ADSL typically.  So "a number low enough to not make trouble
on the kind of deployment targeted", if 1280 is below any reasonable
troublemaking threshold it's certainly better than 500.

The point would be to eliminate the drawbacks John pointed out by
mandating the mtu number at one we know won't find problems on 99% of
the networks.

UDP + IPv4 header is 28 bytes, so the overhead numbers on a full packet
of data are

1500: 1.87%
1280: 2.19%
 500: 5.60%

In fact often the traffic is not bulky enough to reach the full packet
size, acks going around or ssh session traffic etc is sent out as it
happens and not coalesced.  So often the UDP packets are little ones
anyway at much higher header overhead regardless of the mtu.  But for
bulk traffic the extra overhead will show up.

> But really, John is right. VPN Is not free. We should not assume tunneling

Yes, it is not "free of hassle", although it can be "free as in beer"
and "free as in FOSS".

> by default, as "tunneling in the middle" results in all kinds of operational
> problem. VPN does work OK if the VPN starts from the client. VPN from the AP
> is likely to cause serious reliability issues. John experienced that with
> Linux, but we had pretty much the same experience in Windows Networking,
> with all kinds of weird failure happening when routers decided to restrict
> the packet size below what was advertised by the first hop link. We saw the
> exact same problems with PPPoE. The host will connect to a web service, and
> declare in TCP an MTU of 1500 bytes, as advertised on the local Ethernet
> connection. The connection will proceed because HTTP GET is a short packet,
> but the web server will try to actually send with the MTU of 1500, the
> packet will be dropped by the DSL/PPPoE router, the ICMP will either not be
> sent or be dropped by a firewall, and the connection would fail.
> 
> It is one of those theory and practice things. In theory, MTU discovery
> works and you can use whatever tunneling you want. In practice, not so much.

Agreed but these particular problems will be hoovered up by mandating a
low mtu on both sides.

VPN-in-the-middle I don't find convincing for other reasons.  If my AP
comes with a checkbox to allow safe public use, I can control total
bandwidth usage and throttle to a limit that matches my upstream
connection, I can see myself allowing it because those address the
concerns I would have, that it'll get me in trouble; it'll suck all my
bandwidth allowance; it'll get in the way when I need to do bulk transfer.

If I have to sort out a VPN account with my own credit card that I have
responsibility for, tying my identity to whatever the public does with
my link, that's potentially more risky to me than letting them use my IP
directly.  If I get in trouble with my ISP or law enforcement in my
country from what clients did that's very bad, but I'm not sure getting
letters from law enforcement in the vpn host country that you may not
speak the language of etc, or the company you are responsible for gets
the letter instead, is much better or truly will keep the problem away
from you.

-Andy