Protocol stacks that are not equivalent

[MaxF12]

Per the architecture draft, only protocol stacks that are equivalent can be safely raced. What is the expected behavior if selection properties are set in such a way that the resulting candidate set includes protocol stacks that are not equivalent? Would the selection properties simply be treated as invalid?

[gorryfair]

To me "equivalent" relates to either candidate would provide the set of functions needed.

At the risk I don't answer your question: My take is that one can always define policy and API properties that produce a useless outcome. It's not the job of a TAPS system to validate these (although someone may like to try that as a separate sanity checking tool); in just the same way that someone can write code that doesn't implement an algorithm.

The goal is rather that if this specifies "sensible" properties and policy you get the required outcome. You may get no connection or something unexpected if the request is not well-founded.

[MaxF12]

Right, so if an application chooses to provide properties that allow both TCP and UDP the implementation would race those two which would result in a default win for UDP, is that correct?

[mwelzl]

I agree, and I'd say the answer to your question is yes. Of course, later you may find that UDP doesn't really work on the path for the given port, and then it would be great to have an open TCP connection available to fall back to.

[philsbln]

I guess we should define "equivalent protocol stacks" a little less rigorous in the architecture document. For an application that does not care about message boundaries, and reliable transport and has its own congestion control, protocol stacks with TCP and UDP may indeed be equivalent with respect to the application's requirements.

This would require to rewrite 1. of the enumeration in Section 4.2.3 which could use a second look anyway, because it mixes up application requirements in sense of interface behaviour and application protocols that directly depend on specific transport protocols beneath, which is what PR #327 is all about.

[britram]

See also mailing list discussion in July 2019.

[theri]

We also need to say here what "equivalence" means for security.
Right now, Security Considerations says "As described above in Section 4.2.3, if a Transport Services system races between two different Protocol Stacks, both MUST use the same security protocols and options."
I think if we consider equivalence as "you can use whatever stack that satisfies the things that the application requested", this should also apply to security.
Now that the application has to explicitly select a security protocol, I think it should also be allowed for the application to say that multiple security protocols are fine. Like, allow applications to say "Use TLS 1.3 if available, but if not, TLS 1.2 is also fine" (instead of failing).

[tfpauly]

Fixed by #389