Re: Piggyback the final ACK of the three way TCP connection establishment with the data

[Rick Jones <rick.jones2@hp.com>]

On 03/21/2012 04:38 PM, Vincent Li wrote:
> Hi,
>
> I happen to see this link
> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02020743/c02020743.pdf
> and

That dates to March of 2008.

> tcp_delay_final_twh_ack:
>              Piggyback the final ACK of the three way TCP connection
>              establishment with the data by delaying the final ack by
>             10ms.
>
>             0: Send the final ACK as soon as the SYN+ACK packet
>                 arrives from the remote host.
>
>             1: Delay the sending of the final ACK by 10ms. If
>                 there is data available to be sent with in the
>                 next 10ms, piggyback the ACK for the SYN.
> [0-1] Default: 1

I guess that was to allow the client's ACK of the server's SYN|ACK of 
the client's SYN to be piggybacked with the client's initial request. 
Probably did nice things on either netperf TCP_CRR, or some 
connect()-heavy workload.    Probably not a good thing for those 
applications where the accept()ing side sends first...

> It appears this feature is not available in kernel tcp implementation,
> is it trivial to make a custom patch to make this feature available?
> can someone give a hint on how to make a patch for this?
>
> We had a situation that we want to make linux kernel tcp stack behave
> this way so we can reproduce another issue at hand.

Unless some other stack has that feature, why not simply use an HP-UX 
system directly?

rick jones