> In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK segment > today. That means even without large SYN options, we can imagine making > TCPINC zero latency. Realistically, doing so will > require a gross hack in > which TCP-ENO compactly encodes timestamp and SACK availability, window > scaling, etc., in lieu of larger options. I don't expect people would be > very happy with something like > that from day one. But we don't want to > shut the door to such an optimization either, in case TCPINC becomes a > runaway success. (We've been careful to leave a bunch of reserved suboptions > in the TCP-> ENO spec just in case we need extra bits for such optimizations.)
I've not followed this thread. But this discussion about long options in SYN, modifying existing TCP options, etc. really scares me. I've always thought TCPINC's objective is to provide *payload* encryption, and negotiating this should IMHO not require any complex option. I am also confused about the actual technical details in this discussion. In my understanding, the SYN-ACK for any modern high-speed TCP stack has to carry MSS (4 bytes), windows scale (3 bytes), and SACK permitted (2 bytes). This means that at most 31 bytes are left (in theory, we have plenty of other TCP extensions consuming parts of it). Also, I believe some middleboxes/firewalls may act upon those options in the SYN-ACK, i.e., they cannot easily be replaced or encoded in a more compact way. As a result, I somehow don't understand how to get a 32 byte value into SYN-ACK without EDO (draft-ietf-tcpm-tcp-edo). And for EDO there are deployment challenges with using it in the SYN-ACK, see the discussion in TCPM. In any case, this sort of discussion on SYN option space IMHO should be taken to the TCPM list. Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
