VPN Tunnel Effeciency

AES should be faster than 3DES.

QOS should help, IF you're saturating your line with other traffic as well.

Barry

Yep, for that database application which is taking some time to respond between clicks, the biggest issue is packet latency.

Which is why QoS can help IF you are saturating your line.

Compression will generally help (and you've already got it on) and at worse, only make things just a tiny bit slower (should generally not be noticiable and at best can double your effective throughput).

Different compression algorithms won't make much of a difference at the speeds you're talking about.

Probably the biggest difference you can make in your apps responsiveness is to run the app closer to the server (preferably on the same local network) and then pipe the display to wherever you are using remote desktop or VNC.

You database app probably makes tons of small calls to the server to generate a small bit of visible output. Over a network connection with some latency, this will slow things down considerably if the application was not designed with this use case in mind.

Yea my thoughts are that they dont have VPN in mind with this app.  It is a total pain because they are telling the client that they have this running all over and they done have these issues there, and they point at the connection as the problem EVERY time.  I am now faced with either improving it or proving to them, the client, that it is truly their software that is the issue.

I have thought of putting local PC's on the network and allowing them to attach to it and use it in the manner that you spoke of.  

Anyway, how would you go about proving that it is their application.  Is there a program you would use to monitor the traffic flow?

Thanks again,
RR

Your best tool in this case would be your standard packet sniffer, like [url=http://www.wireshark.org]Wireshark[/org].

Comparing the packet traces generated by the application when running over a VPN and when running locally should quickly reveal the issue.

BTW, when they blame the connection as the problem, are they blaming the latency, bandwidth or packet loss of the connection as being the problem?

Please try to disable compression as today more than twice the cpu power is needed to compress the data than to encrypt it. 
If you are into faster response time, a lower latency is what you need. 

the maximum communication between these two devices is approximatley 600kbit/s per seconds, which comes down to 75 kByte per second. 

What kind of bandwidth does your application need?

thx Gert

Please try to disable compression as today more than twice the cpu power is needed to compress the data than to encrypt it. 
thx Gert

FeatureRequest for new versions:
some new IPSec-Policies
-> Astaro2AstaroVeryFast
-> Astaro2AstaroVerySecure
-> Astaro2AstaroAsUsual
-> Astaro72Astaro6Default
-> Astaro72Astaro5Default
...

[:)]

Gregor Kemter

Gert, I am checking on what the requirements are.  The problem I am running into is that the company that makes the software is NO help.  They keep saying that "they have it working fine else where".  Well, we are not investigating that part now.

Drees, They are blaming the latency.  The time between clicks is what they are really upset about.  I talked to them again today and they are looking at T1 lines now.  Unless we figure out if this is a problem that can be fixed via a slow connection I dont see how a T1 will help much.

I will look at the packet sniffer and see if I can figure out where the packet loss is coming from.

Thanks again for all your help.
RR

Please try to disable compression as today more than twice the cpu power is needed to compress the data than to encrypt it. 
If you are into faster response time, a lower latency is what you need.

Gert, I highly doubt that compression is adding any significant amount of latency to the VPN connection. Certainly no more than a couple milliseconds. In my experience, in general if we are dealing with compressible content, the benefit of compressing content outweighs it's drawbacks - unless we are dealing with LAN speeds, which at ~600 kbps (maximum upstream in both directions) isn't even close. However if you get close to saturating that pipe, expect network latencies to jump to at least a quarter second. I have seen network latencies jump to well over half a second with a single TCP connection saturating the upstream of a Cable or DSL line.

Drees, They are blaming the latency.  The time between clicks is what they are really upset about.  I talked to them again today and they are looking at T1 lines now.  Unless we figure out if this is a problem that can be fixed via a slow connection I dont see how a T1 will help much.

What kind of ping times are you getting between endpoints?

If you want to test Gert's theory that compression slows things down, go ahead and run 100 pings through the VPN with and without compression. Add some payload to the ping packets so the compression has something to do. I highly doubt you'll see any significant difference.

I will look at the packet sniffer and see if I can figure out where the packet loss is coming from.

Packet loss? That is very different than latency, which what I think you meant there.

Please try to disable compression as today more than twice the cpu power is needed to compress the data than to encrypt it. 
If you are into faster response time, a lower latency is what you need.

Gert, I highly doubt that compression is adding any significant amount of latency to the VPN connection. Certainly no more than a couple milliseconds. In my experience, in general if we are dealing with compressible content, the benefit of compressing content outweighs it's drawbacks - unless we are dealing with LAN speeds, which at ~600 kbps (maximum upstream in both directions) isn't even close. However if you get close to saturating that pipe, expect network latencies to jump to at least a quarter second. I have seen network latencies jump to well over half a second with a single TCP connection saturating the upstream of a Cable or DSL line.

Drees, They are blaming the latency.  The time between clicks is what they are really upset about.  I talked to them again today and they are looking at T1 lines now.  Unless we figure out if this is a problem that can be fixed via a slow connection I dont see how a T1 will help much.

What kind of ping times are you getting between endpoints?

If you want to test Gert's theory that compression slows things down, go ahead and run 100 pings through the VPN with and without compression. Add some payload to the ping packets so the compression has something to do. I highly doubt you'll see any significant difference.

I will look at the packet sniffer and see if I can figure out where the packet loss is coming from.

Packet loss? That is very different than latency, which what I think you meant there.