Scharf, Michael (Michael) <[email protected]> wrote: > To: David Mazieres <[email protected]>... > >> In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK >> segment today.
It's always possible to fit _one_ thing in -- what's hard is fitting all the things folks consider "necessary". We've come late to this dance. :^( We should expect a lot of pushback putting that much in SYN-ACK until there is a Proposed Standard for expanding the SYN-ACK option space. >> That means even without large SYN options, we can imagine making TCPINC >> zero latency. "Zero latency" isn't the right target, IMHO. We should be advocating for low latency by alieviating buffer-bloat latency overall; and designing a default-case where we're not negotiating in the originating SYN: merely allowing for negotiation later. Until TCPM gets a "round tuit" and increases option space at least for the SYN-ACK, we're facing an almost insurmountable obstacle to deployment. >> 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 strongly advise against going there. Deployment would take forever! >> 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. Ah! Youthful optimism! It's refreshing to see it! >> (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 wonder if we _have_ a shared goal there... > 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). (In _many_ cases, timestamp is automatically included, in order to disambiguate over-large bandwidth-delay-product and error-correction algorithms trying to avoid packet loss. This _is_ of course a terrible design; but we seem to be stuck with it for at least five more years.) > This means that at most 31 bytes are left (in theory, we have plenty of > other TCP extensions consuming parts of it). +1 > 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). That really _is_ a non-starter. If we want negotiation in the SYN-ACK, we need to push the TCPM group to publish _some_ Proposed Standard. (Myself, I'd rather avoid the need for negotiatting in our first Proposed Standard: deployment of draft-ietf-tcpm-tcp-edo is going to be too slow for what I thought our target deployment to be. :^( > And for EDO there are deployment challenges with using it in the SYN-ACK, see > the discussion in TCPM. Seriously, we SHOULD follow (and participate in) the TCPM discussion. > In any case, this sort of discussion on SYN option space IMHO should be > taken to the TCPM list. I suspect we need to continue the discussion here; but recognize that multi-byte TCP options simply won't be available without TCPM action. :^( -- John Leslie <[email protected]> _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
