Tero Kivinen <[email protected]> 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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
