TCP Performance

Nick Olsen nick at flhsi.com
Tue Aug 27 15:00:26 UTC 2013


I have done a decent amount of reading on both TCP windowing and Flow 
Control. But I've seen a lot of conflicting data. Some say flow control 
breaks more then it fixes. Where some say it's completely required. 
Currently we do not have Flow control enabled. Our routers do not support 
flow control currently (At least, Not at a configurable level, maybe at the 
NIC hardware wise). The only way we could currently implement flow control 
would be installing a manged switch (with flow control) between the 
router(s) and the Microwave links.
Regarding packet loss. We once again have conflicting data. If you take a 
look at the packet captures. The file download in Orlando (Which rocks 
~800Mb/) shows ~5K retransmits/Dup Acks. However the file download in Cocoa 
(Crossing the wireless) is about 3x that (~16K retransmits/dup acks). The 
same is shown on an intra-network test from server to server.. But only 
when HTTP. Iperf testing shows ~18 errors, Vs ~13K errors when HTTP based. 


Nick Olsen
Network Operations (855) FLSPEED  x106

----------------------------------------
From: "Blake Dunlap" <ikiris at gmail.com>
Sent: Tuesday, August 27, 2013 10:32 AM
To: nick at flhsi.com
Cc: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: TCP Performance

You didn't indicate this, but do you understand how TCP windowing works? 
This conversation can go two very different ways depending on the answer.

To me, it looks like this is what you'd expect, and you need to fix your 
packet loss issues, which possibly might be QoS settings related (but it's 
hard to tell based on the information given).

-Blake

On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen <nick at flhsi.com> wrote:
 Greetings all, I've got an issue I was hoping to put a few more eyes on.
 Here's the scenario. Downloading a file at our Border is multiple orders
of magnitude faster then a few hops out. Using the same 128MB test file, I
tested at two different locations. As well as between them. Using multiple
connections improves throughput, However it's the single stream issue 
we're
looking at right now. All testing servers in question are Centos Linux.
 Orlando Datapath: Cogent>Orlando Border Router (Mikrotik)>HP Procurve
Switch> Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz'
saved [127926272/127926272]
 Cocoa NOC Datapath: Cogent>Orlando Border Router (Mikrotik)>Licensed
Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed
Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed
Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router
(Mikrotik)>HP Procurve Switch>Server Results: 2013-08-26 13:42:25 (398
KB/s) - `128mbfile.tgz' saved [127926272/127926272]
 Orlando-Cocoa NOC Datapath: Orlando Server>HP Procurve Switch>Orlando
Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East
Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s 
Capacity)>Cocoa
Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router
(Mikrotik)>NOC Router(Mikrotik)>HP Procurve Switch>ServerResults:
2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved
[134217728/134217728]
 Now, For the fun of it. I ran Iperf single TCP between our Cocoa and
Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port).
It maxes out the port, Unlike the HTTP test.
 [root at ded01 ~]# iperf -c
208.90.219.18------------------------------------------------------------Cli

ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte
(default)------------------------------------------------------------[  3]
local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ 
ID]
Interval       Transfer     Bandwidth[  3]  0.0-10.0 sec   114 MBytes  
95.7
Mbits/sec

Here's associated packet captures for each transfer. As well as full wget
output and traceroutes for each test. As you can see, The tests crossing
the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm
not sure I'm sold this could show such a huge drop in throughput. Other
then that, nothing really stands out to me as to why these transfers are 
so
much slower. Intra-network iperf testing shows full throughput the whole
way with single connection. As well as UDP testing. One thing to note is
the Iperf testing has far less TCP re-transmit/dup acks then any of the
HTTP testing, Crossing the same Microwave Links and routers.
http://cdn.141networks.com/files/captures.zip
I appreciate any insight anyone might have. Thanks!
 Nick Olsen
Network Operations (855) FLSPEED  x106




More information about the NANOG mailing list