[VPN] IPsec performance just 55% of WAN bandwidth

[Ryan Malayter]

I'm going to check out ttcp and etherreal... It might take a few days to
get it all tested, though, since I can't take down the CPN tunnel during
business hours.

-----Original Message-----
From: Dana J. Dawson [mailto:djdawso at qwest.com] 
Sent: Thursday, July 17, 2003 2:36 PM
To: Ryan Malayter
Subject: Re: [VPN] IPsec performance just 55% of WAN bandwidth


Ryan,

Well, I think we can rule out a TCP Windowing problem.  I've heard that
Windows 
is supposed to have a better sliding window algorithm, but reading
Microsoft's 
tech support pages leaves me less than convinced.  We've had other
customers 
with higher speed circuits with longer RTT's run into this problem and
even with 
their fully up to date W2K servers their TCP window size stayed at
17,520, so 
maybe it's a more subtle thing than I've managed to understand.

Have you tried any other applications?   There's a generic TCP
throughput 
testing tool called "ttcp" that you can run on virtually any platform,
but you 
need it on both ends since it runs in client/server mode.  Because it
doesn't 
use any disk data it can be a more accurate tool for measuring TCP
throughput. 
I've also heard rumors about different versions of FTP having
performance 
quirks, such as significantly better performance in one direction than
the other 
(i.e. doing a "put" is way faster/slower than doing a "get").

Finally, and this is probably the most likely cause, are you seeing any
packet 
loss during your transfers?  If you have a network analyzer and can
sniff one of 
  your file transfer sessions, if you see any retransmissions from
either end 
that means there was a dropped packet.  It doesn't take very many
dropped 
packets to dramatically slow throughput, since TCP stops when it fills
the 
Window and it has to wait for packet timeouts.  There's a very good free
tool 
called "ethereal" (http://www.ethereal.com) that also runs on many
platforms 
that you can use to sniff your sessions.  The capture filters can be a
little 
obtuse, but simple ones are relatively easy (such as "host 1.2.3.4" or
"port 21 
or port 20").  It might be a bit tedious, but if you look at the delta
times 
between packets you can usually spot where the retransmissions are
because the 
times are unusually large.  If you then look at the TCP sequence numbers
on the 
delayed packets you'll probably see a few repeated sequence numbers that
are 
duplicates from a packet or two from just before the delay.

I hope this helps.  Let me know if you have any more questions you think
I might 
be able to help with.

Dana

-- 

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."