[VPN] 3Des Connectivity -ftp
Dana J. Dawson
djdawso at qwest.com
Mon Jan 13 17:17:14 EST 2003
This sounds like it might be a TCP Window Size issue. The maximum theoretical
throughput of any single TCP session (such as an FTP file transfer) is limited
by the Round Trip Time (RTT) and Window Size. Because of the way TCP windowing
works, the sender needs to be able to transmit data continuously at the line
rate for at least the RTT if it's going to fully utilize the available
bandwidth. Thus, the maximum theoretical throughput of any single TCP session
can be stated by this formula:
BPS = WIN_SIZE / RTT
where BPS is measured in Bits per Second, WIN_SIZE is the minimum of the Receive
Window size on the receiving host and the Send Window size on the transmitting
host in bits (it's usually measured in bytes, so be careful with this one), and
RTT is the Round Trip Time in seconds. You can use "ping" to estimate the RTT,
but since you really only want the RTT for a single bit, using a small packet
size is good enough.
The variable you usually have any control over is the Window Size, and in most
systems you can it (them actually, but usually you'll set both the Send and
Receive to be the same) up as high as 1 GBytes by using the TCP Window Scaling
option. The default for most systems ranges between 8 KBytes and 32 KBytes,
with recent Microsoft Windows OS's defaulting to just above 17,520 Bytes, and
older versions (NT and before) defaulting to 8760 Bytes. So, if you do the
above math, with a 340 msec RTT and a Window Size of 16 KBytes, the maximum
theoretical throughput of any single TCP session is 385506 bits/sec, or about 47
KBytes/sec (where "K" = 1024). Note that this number includes all overhead,
such as packet headers, so the actual throughput seen by an application will be
lower. The effects of encryption would contribute to the latency, so make sure
you measure the latency across the VPN so you can factor that in.
Also, I've heard that some implementations of FTP transfer files significantly
slower in one direction than the other. That is, a "get" is faster or slower
than a "put". It might be worth trying transfers in both directions to see if
this is a factor.
If your throughput rates are significantly slower than the theoretical numbers,
you could also be seeing fragmentation and/or packet loss. Fragmentation
problems are common with VPN's because additional headers are added as part of
the VPN processing. This is a problem because virtually all hosts today use
"Path MTU Discovery" by default to determine the maximum packet size that will
avoid fragmentation. As part of this, every packet get sent with the DF (Don't
Fragment) bit set, so if fragmentation is necessary the packet gets dropped,
which results in a retransmission and slower throughput. Unfortunately, not all
VPN implementations deal with PMTU Discovery and fragmentation in an ideal way,
so a lot of packets can get dropped. To work around this you can set the MTU of
the end hosts down to 1400 or so and that should allow enough room for the IPSec
headers and still keep the total packet size under the magic 1500 number.
I hope this helps - good luck!
Dana
MR wrote:
> Hi ,
>
> We have a customer who has a VPN connectivity to France . Its a 3-DES
> IPSec VPN router to router. He has an FTP server behind the router at
> France end. The latency is around 340 to France, but he is getting a
> very slow FTP speed. Though he has a 1Mbyte connectivity locally here
> and 10mb at France end , speed is very poor. From any internet site , he
> gets good speed upto 90kbyte/sec .
>
> LAN ----- Router ------ { Internet }------- Router - LAN(FTP Server)
> 1Mb 10Mb
>
> Would like to know whether 3Des affect the performance in any way. Or
> this could be bandwidth related factor. Kindly do get back to me for
> more info.
>
> Rgds
--
Dana J. Dawson djdawso at qwest.com
Senior Staff Engineer CCIE #1937
Qwest Communications (612) 664-3364
600 Stinson Blvd., Suite 1S (612) 664-4779 (FAX)
Minneapolis MN 55413-2620
"Hard is where the money is."
More information about the VPN
mailing list