Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence. We can make the text more clear here, but it isn't a technical change.
Thanks, Tommy > On Jul 23, 2019, at 12:05 PM, Max Franke <mfra...@inet.tu-berlin.de> wrote: > > So if I understand this correctly, this boils down to the fact that if two > protocols are in the candidate set for racing they are also equivalent? Thus > we dont have to worry about unequivalent protocols as they are never part of > the same candidate set anyway? > > Best > Max > > > > Am 23.07.2019 11:59 schrieb Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>: > Hi Joe, > > Yes, I completely agree. The current text in -arch expresses this as: > > 2. Both stacks MUST offer the same transport services, as required > by the application. For example, if an application specifies > that it requires reliable transmission of data, then a Protocol > Stack using UDP without any reliability layer on top would not be > allowed to replace a Protocol Stack using TCP. However, if the > application does not require reliability, then a Protocol Stack > that adds unnecessary reliability might be allowed as an > equivalent Protocol Stack as long as it does not conflict with > any other application-requested properties. > > If you think we can clarify this any further, let me know! > > Thanks, > Tommy > > On Jul 23, 2019, at 11:55 AM, Joe Touch <to...@strayalpha.com > <mailto:to...@strayalpha.com>> wrote: > > > > On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <ther...@inet.tu-berlin.de > <mailto:ther...@inet.tu-berlin.de>> wrote: > > Another important difference between TCP and UDP are Message Boundaries. > So in some cases, TCP + Framer may be equivalent to UDP. > > FWIW, they might provide *similar* capabilities, even only those that the app > is concerned about, but there are a LOT of other differences that can’t be > glossed over. In some cases, it is TCP that is lacking (as above); in others, > UDP). > > It’s only important whether the user does or doesn’t care about those > properties. When they match what they care about, they can be considered > equivalent. > > I.e., there’s not likely going to be a strict and absolute equivalence > between transports. > > Equivalence is TO THE USER, relative to their constraints. > > Joe > > _______________________________________________ > Taps mailing list > Taps@ietf.org <mailto: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
