[NCLUG] Re: DSL Throttling or General Congestion?

[John L. Bass]

Hi DJ,

At times more than 2/3's of the CWX membership has tele-communted using 
VPN's back to work, so it's always been a priority to figure out how to 
make them work as well as possible in our coop - one of the nice parts 
about ownership and operation of your own network.

In our experience, packet loss is the number one problem that causes 
VPN's to drop out. They just do not seem to handle very much packet loss 
before they give up on the connection. This is the primary reason CWX 
has always managed it's network to minimize packet loss, so that most of 
our members have minimal problems with VPN's and VoIP services. Because 
of oversubscription, the worst loading patterns happen at times, but we 
try to keep it at a minimum.

Our primary solution is holding peak bandwidth down to a fraction of our 
upstream bandwidth. We current limit bandwidth to 768kbps, with a 
4.3mbps upstream feed from three T1's. This means we can have 5-6 
concurrent traffic bursts without overrunning the routers and radio 
buffers, thus injecting packet loss to throttle the connections 
(dropping VPN's and causing broken VoIP speech).

The alternative model is to allow everyone 4.5mbps access to the 
internet, and just letting packet loss throttle everyone (with horribly 
unstable VPN's and VoIP). We have tried this several times along the 
way, and it didn't take long to reach concensus that it doesn't work for 
our membership.

It's always been interesting to try and balance those that want a stable 
network for VPN access to work, with those that just want an all you can 
eat fast connection to the internet. We generally send the vocal latter 
to LP Broadband, cable, or DSL if they have a choice. The gamers were 
the first to eat the CWX network alive, and it didn't take long to clamp 
that abuse. Along the way it's also been P2P users, and a few other not 
so bandwidth sharing friendly uses. Otherwise, the majority get the best 
stability we can with this less than optimal technology.

You might be VERY vocal to your clients providers about the difficult 
problems your clients are having with VPN access. It might provide some 
balance to the very vocal P2P and gaming users that demand all you can eat.

John

DJ Eshelman wrote:
> YAR
>
> That's a much better way of saying it, but I'm pretty sure we're 
> saying the same things.  You can have all the bandwidth in the world 
> you want- but with the sheer unbelievable amount of network traffic 
> that makes up the internet- far beyond what any of the architects 
> could have possibly imagined, it makes sense.
> Add to that NAT... what a mess.
>
> I guess another good discussion would be, does IPv6 do anything to 
> address this?  I've never found a practical reason to play with it.
>
> I'd just love to find a way to make my clients more happy with me, and 
> figuring out a better way to do VPNs over a DSL would be a good start :)
>
> -DJ
>
> John L. Bass wrote:
>> Hi DJ,
>>
>> Bandwidth and latency are two very different beasties, and they are 
>> NOT co-dependent. Consider that an information stream to the moon 
>> band back can exist at 100mbps both up and down in a pipeline that is 
>> roughly 385,000,000 meters each way. The speed of light is roughly 
>> 299,729,458 m/s, so the round trip delay (flight time latency) of 
>> 2.58 seconds, with data happily streaming along at 100mbps.
>>
>>
>> DJ Eshelman wrote:
>>
>>> It's also why VPN connections are so difficult to use practically, 
>>> but what I'm finding is that I can't always convince my clients to 
>>> put in a leased circuit (a p2p T-1 from Fort Collins to Greeley, for 
>>> example, typically has an 8ms latency whereas an internet-based DSL 
>>> connection averages 70-180ms (cable was worse at 130-2000ms, testing 
>>> both from a Level3 Internet T-1 line).  Add the overhead of either 
>>> IPSec or PPTP for your VPN and you've got major latency issues.  And 
>>> in my world- having to deal with Windows/CIFS for the majority of 
>>> what my clients are doing- my problems are huge because CIFS is an 
>>> extremely chatty protocol that goes over TCP/IP for most of it's work.
>>>
>>> So now to why I'm even addressing this to the group:  I've been 
>>> trying to find open source solutions to get around these latency 
>>> issues (packeteers and such) and haven't had much luck.  Anyone else 
>>> out there dealing with these issues/have any ideas?