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
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
