Re: [Taps] How to handle Protocol stacks that are not equivalent

On 23/07/2019, 10:31, Tommy Pauly wrote:
> 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
That makes sense to me.

Gorry
>> On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel<philipp@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