Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[John Leslie <[e-mail]>]

Scharf, Michael (Michael) <[e-mail]> wrote:
> To: David Mazieres <[e-mail]>...
> 
>> 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 <[e-mail]>