RE: patch for duplicate tcp acks

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

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