[BBLISA] slow wan link

[Daniel Feenberg]

On Wed, 6 Jun 2012, Rob Taylor wrote:

> Hi Daniel.
>
> When you say WAN link,  are you referring to a network link between two
> offices at your company, or do you mean your Internet connection?

10 mbs to the ISP over fiber.

> Also, what speed is this link? When you say WAN, I think T1, T3, etc...
> Can you monitor your gear with SNMP or command line to see what
> performance stats on the gear are? Can you throw in a linux box running
> ntop to see the traffic coming and going? Can you do ttcp test just
> over the link itself?
>
> Some network gear can queue smaller "interactive" packets ahead of
> larger bulk transfer packets, to give better response to some
> applications in heavily loaded situations.

There is a Fortigate between us and a vanilla Cisco router, but I don't 
think any traffic shaping is going on. Ping times are still good with 
large packets (1000 bytes).

Dan Ritter mentioned that I shouldn't trust ping for dropped packets. 
Would the router prioritize ICMP over tcp, so that ping would be fine but 
tcp packets would be dropped? Maybe there is a tcp-ping?

>
> Most of the following suggestions are ways to reduce load/optimize the
> use  on the link.
>
> X-windows is not the most network lite protocol out there. I've seen it
> work well on a lan, but very poorly over a slow/high latency link.

We want to try NX, but it doesn't cooperate with our 2-factor 
authentication.

> If you can, have the users try using VNC, or freenx. Both create a
> virtual X desktop on the target machine, and just shows you a mirror of
> it on your desktop which you can disconnect from and reconnect to at
> will. (They are the gui equivalents of screen or tmux)
> The benefit of that is that instead of getting X updates,  your client
> gets smaller raster updates(like rdp), which works better over slow
> links.
> VNC is not encrypted by default, so keep that in mind if it's going to
> go over an untrusted link.
>
> For web traffic, you could setup a squid proxy on a spare machine on
> the lan side of the link. This can share common web traffic among
> clients.

We don't have many users, just users with big files to transfer, so I 
don't think a cache would have much effect.

>
> If your wan gear can't do that, then you can also at traffic shaping
> gear, which can optimize/prioritize the flow of traffic over the link.
> On a network mailing list that I am on, people have mentioned liking
> Netequalizer, which is a inexpensive transparent traffic shaper.
> It tries to make sure that people don't hog the link by default.

I will look at Netwualizer.

>
> Let me know what you discover.
>

Will do, if we figure it out.

dan feenberg
nber