Re: [tcpinc] TCP's treatment of data in SYN packets

[Derek Fawcus <[e-mail]>]

On Wed, Jul 27, 2016 at 02:45:11PM -0700, David Mazieres wrote:
> 
> Basically I'd like to ensure that ENO conflicts as little as possible
> with future use of data in SYN segments.

My understanding of what TCP _allows_ (absent FO) is that one can send
data in the SYN,  it can be ACK'ed in the SYN-ACK,  but there may be
some text indicating it is not to be delivered to the receiving
application unless and until the 3whs completes.

Implying that a passive opener which chose to ack such data bytes would
have to buffer such data until the handshake completes;  but I'm not
aware of any stack which actually works that way. (Due to DOS attack).

So I'd expect it would probably be safe to start defining some new
expectations / constraints for use of such data in SYN segments.

However,  one could envisage say a user space TCP stack (for a SERVER)
which supported the following sequence:

        CLIENT                                         SERVER

   1)   SYN-SENT     --> <SYN, data1> -->             SYN-RECEIVED

   2)   ESTABLISHED  <-- <SYN, ACK(data1), data2> <-- ESTABLISHED

   3)   FIN-WAIT-1   --> <FIN, ACK(data2)> -->        CLOSE-WAIT

followed by the rest of the normal close sequence.

i.e. something slightly similar to T/TCP but without trying to optimise
the close sequence,  while still allowing a request-response exchange
to be done in 1-RTT if all goes well.

DF