Re: [Taps] How to handle Protocol stacks that are not equivalent
Max Franke <mfranke@inet.tu-berlin.de> Tue, 23 July 2019 16:05 UTC
Return-Path: <mfranke@inet.tu-berlin.de>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E79112039B for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 09:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.478
X-Spam-Level:
X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ZDiqjs8kqh for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 09:05:55 -0700 (PDT)
Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.152.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECDD120343 for <taps@ietf.org>; Tue, 23 Jul 2019 09:05:55 -0700 (PDT)
Received: from [172.16.150.129] (unknown [207.115.96.130]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id ADD94207EA; Tue, 23 Jul 2019 18:05:53 +0200 (CEST)
Date: Tue, 23 Jul 2019 12:05:55 -0400
Message-ID: <fcbd50de-9364-4e33-aebb-dccaeece8141@email.android.com>
X-Android-Message-ID: <fcbd50de-9364-4e33-aebb-dccaeece8141@email.android.com>
In-Reply-To: <FE3F9BD0-2052-4FD4-8799-4AA90B66B0A4@apple.com>
From: Max Franke <mfranke@inet.tu-berlin.de>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: Joe Touch <touch@strayalpha.com>, Theresa Enghardt <theresa@inet.tu-berlin.de>, taps@ietf.org
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/j6rsLbwUPTLk4ZCQJPtxNGUBGL4>
Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 16:06:04 -0000
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,TommyOn Jul 23, 2019, at 11:55 AM, Joe Touch <touch@strayalpha.com> wrote:_______________________________________________On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <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
https://www.ietf.org/mailman/listinfo/taps
- [Taps] How to handle Protocol stacks that are not… Philipp S. Tiesel
- Re: [Taps] How to handle Protocol stacks that are… Tommy Pauly
- Re: [Taps] How to handle Protocol stacks that are… Gorry Fairhurst
- Re: [Taps] How to handle Protocol stacks that are… Theresa Enghardt
- Re: [Taps] How to handle Protocol stacks that are… Tommy Pauly
- Re: [Taps] How to handle Protocol stacks that are… Joe Touch
- Re: [Taps] How to handle Protocol stacks that are… Tommy Pauly
- Re: [Taps] How to handle Protocol stacks that are… Max Franke
- Re: [Taps] How to handle Protocol stacks that are… Joe Touch
- Re: [Taps] How to handle Protocol stacks that are… Tommy Pauly
- Re: [Taps] How to handle Protocol stacks that are… Anna Brunström
- Re: [Taps] How to handle Protocol stacks that are… Theresa Enghardt
- Re: [Taps] How to handle Protocol stacks that are… Max Franke
- Re: [Taps] How to handle Protocol stacks that are… Philipp S. Tiesel