Latency effect on VPN throughput

[barconoida]

Dear All,

We currently have VPN tunnel accross a 1Mbps internet connection between 2 Loactions which are 400msec latency apart. On file transfer between locations we get not more then 400kbps speed. Is it limited due to latency figure. I refered to the below derivation of tcpip throughput which says :

Mathis, Semke, Mahdavi & Ott in Computer Communication Review, 27(3), July 1997, provides a short and useful formula for the upper bound on the transfer rate:

Rate <= (MSS/RTT)*(1 / sqrt{p})

where:

Rate: is the TCP transfer rate or throughput

MSS: is the maximum segment size (fixed for each Internet path, typically 1460 bytes)

RTT: is the round trip time (as measured by TCP)

p: is the packet loss rate.

By calculating with is on 0.5% packet drop and 400msce latency , throughput theoritically we cann't expect better than 400kbps levels.

Is it correct ? is there a way to incraese throughput on same network.

Rgds

RB

[aacole]

Your file transfer is FTP not TFTP?

Have you tried applying compression on the transform set?

As the RTT is so high a bit of extra delay introduced by compression may be offset by the extra data you can send, as long as the data is compressible.

Are you getting packet loss (TCP retransmissions or duplicate ACKs) on the link? If so this will limit the throughput as your TCP sessions will probably go into slow start frequently which will reduce the average throughput.

[barconoida]

speed test is on TCP and not on UDP.

I have not tried any VPN paramter change. I tried some TCP and UDP test with "iperf" , if I run parallel sessions of transfer each runs at 300kbps and with four such sessions full bandwidth of 1Mbps is consumed. This makes the assumption confirm that there is ome TCP limitation such as latency / packetdrop.

Any way to see that single session throughput incraeses on VPN.

Rgds

[aacole]

There was an article in the IP Journal that described some possible performance improvments to high latency links by expanding the TCP window. Depends on your host OS if this is a tweakable parameter?

But also, if you get packet drops this could make the situation worse not better.

The article is here:

http://www.cisco.com/web/about/ac123/ac147/ac174/ac196/about_cisco_ipj_archive_article09186a00800c8417.html

You should be able to flood the link with UDP traffic, this is the recommended way to test the upper limits for bandwidth. However that dosent mean you would get better throughput with TFTP as I think the TFTP server sends one packet then waits for an ack before sending the next, so it will be slower than FTP.

Try compression, may offer an improvement, and its an easy step to apply add `comp-lzs' to your transform sets.

If your using 7200 with SA-VAM-2 this is done in hardware, not sure about the lower spec routers IPSec acclerator boards.

I've got a customer who is complaining of this problem also, so am interested in getting an improvment.

Andy

[roluce]

One item that you should probably concider is the effect of out of order traffic on TCP streams. If there is a significant amount of reordering on a slower line, TCP might initiate fast-retransmits.

TCP fast-retransmits can significantly slow down overall throughput in some situations (low bandwidth lines in particular).

Packet reordering is common on some Internet backbones.

I'd normally expect a bit more throughput on systems that are only 400ms apart. What is the TCP window size on the systems you are using to do the TCP transfer? Roughly: Throughput = 1000/RTT*TCP Window (minus percentage for drops and out of order)

Rob

[aacole]

I found this article on setting up windows 2000 and 2003, gives a bit more information on the TCP window options and selective ACK's.

The improvments should be realised on high bandwidth links with high latency.

[barconoida]

Dear aacole,

This is not going to help as we have hundreds of machines behind the PIX's and the referred solution mean changes windows parameters on all these. Best would be somesthing which could be done on PIX / WAN level.

Rgds

[jackko]

just a quick question, what model of pix are we discussing here.

[barconoida]

PIX 506 , When a PIX encapsulates a packet all the previous parameter such as windows size are hidden , does pix to pix communication is packet by packet on ack .. if so it will adversly effect the throughput of windows session.

rgds

[jackko]

just wondering if the issue is related to the pix outside interface speed and duplex settings, as pix506 outside interface supports only 10full.

e.g.

pix(config)# int e0 100f

ethernet0 can only be set to 10baseT, 10full or auto.

to verify, do a "sh int" and look for the item "collisions" and "deferred".

e.g.

pix# sh int

interface ethernet0 "outside" is up, line protocol is up

Hardware is ixxxx9 ethernet, address is xxxx.xxxx.0216

IP address 10.203.7.1, subnet mask 255.255.255.0

MTU 1500 bytes, BW 10000 Kbit half duplex

6009629 packets input, 854937826 bytes, 0 no buffer

Received 42104 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4436203 packets output, 618069410 bytes, 0 underruns

0 output errors, 17086 collisions, 0 interface resets

0 babbles, 0 late collisions, 12206 deferred

1 lost carrier, 0 no carrier

input queue (curr/max blocks): hardware (128/128) software (0/2)

output queue (curr/max blocks): hardware (0/8) software (0/1)