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

From: Taps <taps-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: den 23 juli 2019 19:52
To: Max Franke <mfranke@inet.tu-berlin.de>
Cc: Joe Touch <touch@strayalpha.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; Theresa Enghardt <theresa@inet.tu-berlin.de>; taps@ietf.org
Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent

Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence.

Same here, seems we all agree on this.

Thanks,
Anna

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 <mfranke@inet.tu-berlin.de<mailto:mfranke@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.com@dmarc.ietf.org<mailto:tpauly=40apple.com@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 <touch@strayalpha.com<mailto:touch@strayalpha.com>> wrote:

On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <theresa@inet.tu-berlin.de<mailto:theresa@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<mailto:Taps@ietf.org>
https://www.ietf.org/mailman/listinfo/taps