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<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
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
