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

Reply via email to