Three way TCP handshake : can we avoid the third packet ?

Three way TCP handshake : can we avoid the third packet ?

[Eric Dumazet]

Hi

I discovered today that some TCP stackes are able to initiate TCP 
sockets with 2 packets "only".

The third packet (ACK packet) is just delayed and integrated into the 
data packet.

11:07:15.551507 host1.11906 > host2.80: S 1522618044:1522618044(0) win 
64240 <mss 1452,nop,nop,sackOK> (DF)

11:07:15.551523 host2.80 > host1.11906: S 751859039:751859039(0) ack 
1522618045 win 5840 <mss 1460> (DF)

11:07:16.112451 host1.11906 > host2.80: P 1:92(91) ack 1 win 65340

11:07:16.151800 host2.80 > host1.11906: . ack 92 win 5840 (DF)

It seems to be valid (host2 is linux in this tcpdump output), and saves 
one packet.

Is it possible to achieve the same thing with linux 2.4/2.6 ?

A magical setsockopt() thing like TCP_CORK, TCP_QUICKACK, after the 
socket() call and before the connect() ?

Thank you
Eric Dumazet

Re: Three way TCP handshake : can we avoid the third packet ?

[Eric Dumazet]

Following this discussion on netdev, sorry to bother you again :)

Currently, linux cannot easily avoids the third packet (ACK only) of TCP 
handshake, for connections initiated from linux side.

The send(socket, data) is denied (EAGAIN) if the socket is in NODELAY 
mode and socket not yet connected  (connect() done , but not in 
ESTABLISHED state).

So basically, a daemon willing to avoid the third packet must use one 
thread for each outgoing pending connection, seting the socket in 
blocking mode and blocking in send()/write() syscall. In my case, I 
would need about 1000 threads :(

Could we just delay (say up to 200ms) the ACK packet the tcp stack sends ?

If the application uses send() or write() a short time after the 
established state is notified, then the ACK could be suppressed.

This way, every application could benefit from this.


Thank you
Eric Dumazet

Eric Dumazet wrote:
> Henrik Nordstrom wrote:
> 
>> On Tue, 21 Sep 2004, Eric Dumazet wrote:
>>
>>> I discovered today that some TCP stacks were able to initiate TCP
>>> sockets with 2 packets "only".
>>>
>>> The third packet (ACK packet) is just delayed and integrated into the
>>> data packet.
>>
>>
>>
>> The TCP standard even allows you to have data in the SYN packet if you 
>> like. There however needs to be an exchange of three packets before 
>> the connection is considered established. The SYN flag is just like 
>> "octet 0" in the data stream of from sending direction. SYN + data is 
>> just that. As having data in the SYN or SYN+ACK packets is very 
>> uncommon not all TCP stacks are prepared to handle this and is 
>> therefore not recommended.
>>
>> All should handle a data payload in the ACK packet I think however, 
>> but there may obviously be some odd ones which does not.
>>
>>> Is it possible to achieve the same thing with linux 2.4/2.6, for 
>>> connections initiated by us ?
>>
>>
>>
>> Looking at the kernel source... seems to be the case if you simply 
>> initiate a non-blocking connect and then queue some data to be sent on 
>> the connection while the connect is taking place. Testing.. yes this 
>> does work.
>>
>>    set non-blocking
>>    connect
>>    set blocking
> 
> 
> Thank you for the hint. But the "set blocking" makes me nervous, since I 
> need to be sure not to block at write()/send() time...
> 
>>    write
>>
>> Regards
>> Henrik
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Three way TCP handshake : can we avoid the third packet ?

[Eric Dumazet]

Well... I discovered I can use this trick, with a NODELAY socket :

int defaccept = 1 ;
setsockopt(sockfd, SOL_TCP, TCP_DEFER_ACCEPT, &defaccept, sizeof(int)) ;
connect(sockfd, ...) ;
...
select()/poll()/epoll();
...
send(sockfd);

This way, the third packet (pure ACK) is not sent.

But I suspect this trick could be illegal in next kernel versions ... :(

Eric

Eric Dumazet wrote:

> Following this discussion on netdev, sorry to bother you again :)
> 
> Currently, linux cannot easily avoids the third packet (ACK only) of TCP 
> handshake, for connections initiated from linux side.
> 
> The send(socket, data) is denied (EAGAIN) if the socket is in NODELAY 
> mode and socket not yet connected  (connect() done , but not in 
> ESTABLISHED state).
> 
> So basically, a daemon willing to avoid the third packet must use one 
> thread for each outgoing pending connection, seting the socket in 
> blocking mode and blocking in send()/write() syscall. In my case, I 
> would need about 1000 threads :(
> 
> Could we just delay (say up to 200ms) the ACK packet the tcp stack sends ?
> 
> If the application uses send() or write() a short time after the 
> established state is notified, then the ACK could be suppressed.
> 
> This way, every application could benefit from this.
> 
> 
> Thank you
> Eric Dumazet
> 
> Eric Dumazet wrote:
> 
>> Henrik Nordstrom wrote:
>>
>>> On Tue, 21 Sep 2004, Eric Dumazet wrote:
>>>
>>>> I discovered today that some TCP stacks were able to initiate TCP
>>>> sockets with 2 packets "only".
>>>>
>>>> The third packet (ACK packet) is just delayed and integrated into the
>>>> data packet.
>>>
>>>
>>>
>>>
>>> The TCP standard even allows you to have data in the SYN packet if 
>>> you like. There however needs to be an exchange of three packets 
>>> before the connection is considered established. The SYN flag is just 
>>> like "octet 0" in the data stream of from sending direction. SYN + 
>>> data is just that. As having data in the SYN or SYN+ACK packets is 
>>> very uncommon not all TCP stacks are prepared to handle this and is 
>>> therefore not recommended.
>>>
>>> All should handle a data payload in the ACK packet I think however, 
>>> but there may obviously be some odd ones which does not.
>>>
>>>> Is it possible to achieve the same thing with linux 2.4/2.6, for 
>>>> connections initiated by us ?
>>>
>>>
>>>
>>>
>>> Looking at the kernel source... seems to be the case if you simply 
>>> initiate a non-blocking connect and then queue some data to be sent 
>>> on the connection while the connect is taking place. Testing.. yes 
>>> this does work.
>>>
>>>    set non-blocking
>>>    connect
>>>    set blocking
>>
>>
>>
>> Thank you for the hint. But the "set blocking" makes me nervous, since 
>> I need to be sure not to block at write()/send() time...
>>
>>>    write
>>>
>>> Regards
>>> Henrik
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-net" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
> 
> 

Re: Three way TCP handshake : can we avoid the third packet ?

[Henrik Nordstrom]

On Tue, 12 Oct 2004, Eric Dumazet wrote:

> Following this discussion on netdev, sorry to bother you again :)
>
> Currently, linux cannot easily avoids the third packet (ACK only) of TCP 
> handshake, for connections initiated from linux side.
>
> The send(socket, data) is denied (EAGAIN) if the socket is in NODELAY mode 
> and socket not yet connected  (connect() done , but not in ESTABLISHED 
> state).

This is my observations as well.

> So basically, a daemon willing to avoid the third packet must use one thread 
> for each outgoing pending connection, seting the socket in blocking mode and 
> blocking in send()/write() syscall. In my case, I would need about 1000 
> threads :(
>
> Could we just delay (say up to 200ms) the ACK packet the tcp stack sends ?

What would this do to the initial RTT measurements?

>From what I can see the RFCs only allow for delayed ACKs in response to a 
data segment. Not sure if this includes SYN (or FIN).

Regards
Henrik