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

[David Mazieres <[e-mail]>]

Kyle Rose <[e-mail]> writes:

> I think maybe what Mirja is implying is that it's okay to break TCP
> (i.e., not fall back to unencrypted) if the two peers explicitly set
> their roles locally to the same thing. TCP-ENO-aware applications that
> set the role are assumed to get it right and not set both to A or both
> to B.
>
> Question re: the WG goals: is it in fact okay not to always fall back
> to unencrypted TCP if the applications themselves are aware of TCPINC
> and relying on TCPINC-specific API calls?

So to be pedantic here, we are now assuming a design with three local
states for each side, let's call them NULL, A, and B.  If both sides of
a simultaneous open are NULL (the default) you get unencrypted TCP.  If
one side is A and the other is B, you get TCP-ENO.  In the other 6
permutations, you get complete connection failure.

I don't particularly love that or foresee getting a WG consensus behind
it, but I guess I could live with it.  Moreover, it doesn't really
address any of the "hot" TCP-SO questions at this point, which are:

 1. Does TCP-SO really exist in the wild, and if so under what
    circumstances (NAT, no NAT, etc.)?

 2. If applications of TCP-SO exist, must TCPINC support them
    unmodified, or is it okay to disable encryption in the absence of a
    setsockopt on at least one end of the connection?

 3. If we require a setsockopt to encrypt a TCP-SO connection, is it
    okay to ask applications to break the tie as well?

For my part, I'm beginning to have doubts about 1, but answer YES to 2
and 3.

David