> If we are going to add another round of exchanges anyway, though, why > not do the tie-breaking there? We could keep the single b bit as is > (for applications that want to work it out), and then add a > variable-length tie-breaking phase. E.g., > > A->B: SYN ENO<Z, Y> > B->A: SYN ENO<X, Y, Z> > A->B: ACK ENO<Breaker 0x29892a863ce5> > B->A: ACK ENO<Breaker 0xdb636b5918a2>
Why not dump b entirely and just always require an extra round trip for simultaneous open? It seems to be enough of an edge case that, given the options, I'd rather not optimize for it (and also not spend a disproportionate amount of time debating optimization of something that is such a long-tail, and practically degenerate, use case). > 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. IMHO, all applications should be able to benefit from TCPINC's protection against passive eavesdropping without any changes. Kyle _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
