My initial impression here is that any protocol stacks that provide the same transport services, and thus can be raced as candidates, need to be equivalent. It ends up being a bit tautological. The description in the architecture explains what combinations are allowed based on preference—if you don't require reliability, then a UDP protocol stack is equivalent to a message protocol over TCP. If you do require reliability, then those aren't equivalent.
Thanks, Tommy > On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel <phil...@tiesel.net> wrote: > > Hi, > > as time did not permit to discuss all open issues in the session today, I’ll > take them to the list as proposed. > This issue is based on Github issue #305: > https://github.com/ietf-tapswg/api-drafts/issues/305 > > Following the architecture draft, only protocol stacks that are equivalent > can be safely raced. What should happen if selection properties result in a > candidate set that includes protocol stacks that are not intuitively > equivalent? > > > Resolution Proposals: > > a) Define Protocol Stack Equivalence more rigorously. A possible way to do > this would be to say two stacks are equivalent with respect to the > applications’ requirements if both fulfil all require properties specified by > the applications and do not violate any of the prohibit properties. > > b) Generate some kind of Error Event for configurations with unlike protocol > stack candidates. (May need a definition of "unlike”). > > c) Do nothing and close the issue. > > > AVE! > Philipp S. Tiesel > > -- > Philipp S. Tiesel > https://philipp.tiesel.net/ > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
