Re: [tcpinc] Simultaneous open tie breaking

[[e-mail]]

Tero Kivinen <[e-mail]> writes:

>> This is doable, though adds complexity to implementations.  Should this
>> tie-breaker be sent by every active opener (and therefore consume option
>> space), or do you imagine that applications intending to use
>> simultaneous open set an option to include the tie breaker?
>
> I think tcpinc charter says we must work with unmodified applications,
> so I think the default needs to be send it, but allow API call to
> disable it. 

Well, it would be nice to have some evidence that always sending the
tie-breaker would make things work with unmodified applications.  I'm
not saying such applications don't exist, but I think we are debating
the point with insufficient data.

> Also as tie-breaker is only needed in the simultaneous opens, and
> simulatenous opens with NATs in the middle are not that common.

Again, we need some evidence here.  As far as I can tell, it's not even
possible to make simultaneous open work reliably *without* NATs or at
least stateful firewalls (that are likely to modulate sequence numbers
and timestamps) on both ends, because otherwise you risk RST segments.
Also, there's really no reason applications would use simultaneous open
without NATs.  I may be wrong, in which case I would love for someone to
explain how applications use simultaneous open without NATs.

Now you are asserting that simultaneous open is not common *with* NATs.
You may be right.  But also we may both be right, in which case the
conclusion is that simultaneous open just isn't really used period, so
let's not add a lot of complexity or option space to deal with something
that doesn't happen.

>> Before settling on something, I'd like to get a sense of whether people
>> think it's okay to ask applications to signal their intent to use
>> simultaneous open, or whether it's important for TCP-ENO to enable
>> encryption for existing, unmodified applications that use simultaneous
>> open.  Those two options put us down different paths.
>
> By our charter, I think we need to work with unmodified applications,
> but we can provide API to allow optimizations and other things later.

But for that we need an example application.  Otherwise, we can argue
about whether simultaneous open should work with or without NATs, with
or without sequence number modulation, etc., but we are basically
designing in the dark.  I mean if we are giving up on NAT anyway, then
we could break the tie with port numbers and IP addresses.

I don't mind something simple like dedicating one bit to simultaneous
open in case that's someday useful.  But if we start to add a lot of
complexity or consume a lot of option space, I don't think we can
justify that in the abstract--we need to look at real applications.

David