RE: patch for duplicate tcp acks

["Charlet, Ricky" <ricky.charlet%hp.com@localhost>]

Got some test results.

The test we ran was to transfer a 10k file repeatedly, sequentially for 2 minutes. The test bed we have has 100Mb ethernet links and achieves 81Mb throughput without my Device Under Test inline and achieves 49Mb throughput with my Device Under Test.  I count this as a success for the patch as this fits within my expectations for the proxy app I'm building.

Doing a human scan through the resultant pcap (I scanned very quickly and covered about 50% of the data) shows no dup acks, no window resize events, and no unexpected flow events of any kind.

Wireshark  Statistics: TCP stream graph: Window Scaling graph --  show no change for the duration.
Wireshark  Statistics: TCP stream graph: round trip time graph -- show variance between .00004 and .00007 seconds (seems ok to me)
Wireshark  Statistics: TCP stream graph: throughput graph -- settles in the first 1/4 second to a flat line.
Wireshark Analyze: Expert Infos -- shows 0 errors / 0 warnings. 

I can upload the 523MB pcap file somewhere if anyone is curious and would point me to an open repository.



--
Ricky Charlet



-----Original Message-----
From: tech-net-owner%NetBSD.org@localhost [mailto:tech-net-owner%NetBSD.org@localhost] On Behalf Of Charlet, Ricky
Sent: Monday, April 27, 2015 9:12 AM
To: Thor Lancelot Simon; tech-net%NetBSD.org@localhost
Subject: RE: patch for duplicate tcp acks

Hi Thor,

	It will take me a day to answer your question. At the moment, I have only linux VMs on over taxed VM servers to play with in my lab and I notice no performance problem here (though I am unable to drive any real performance stress). But I'll try and ask some co-workers with 'real' performance test gear to give this a run. 

	But, in the meantime... Why do you presume this patch would lead the peer into fast retransmit? Note that with this patch, I am observing that I have stopped double acking most data and am now single acking it.

	Note: my use case is a slight departure from normal... I'm trying to build a tcp proxy. 

   [server]-------------------[proxy]---------------------[client]
                                     A            B

	Where interface A is a proxy client and interface B is a proxy server. But I don't see why my proxy client side would behave differently than a 'normal' client, especially during bulk data flow.

	On the other hand, the patch (from freebsd) and it's comment make perfect sense. It's a "don't ack stuff that we have already acked, even in the presence of window scaling" patch. 


--
Ricky Charlet

-----Original Message-----
From: Thor Lancelot Simon [mailto:tls%panix.com@localhost] 
Sent: Saturday, April 25, 2015 10:09 AM
To: Charlet, Ricky
Cc: tech-net%NetBSD.org@localhost
Subject: Re: patch for duplicate tcp acks

On Fri, Apr 24, 2015 at 09:44:23PM +0000, Charlet, Ricky wrote:
> Howdy,
> 
>         I was suffering duplicate tpc acks.  It seems trivial to duplicate.... Any time I receive a non-zero len tcp packet, I ack it twice.  Note that I'm using a window scale of 3 and that may or may come into play.

Presumably this sent the stack on the far end into fast retransmit at least 50% more often than it "should".  Did you actually see any performance problems associated with this?

I'm pretty sure I've seen this problem in the past, but at the time concluded that it wasn't worth investigating because it seemed to have only the minor negative impact of cluttering up my packet traces.  Which is not to say it should not be fixed!

Thanks!

Thor