IETF Logo Mail Archive

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

Tommy Pauly <tpauly@apple.com> Tue, 23 July 2019 15:59 UTC

Return-Path: <tpauly@apple.com>
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 02763120193 for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 08:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 miE5spBgF8Cw for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 08:59:32 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD54120121 for <taps@ietf.org>; Tue, 23 Jul 2019 08:59:32 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NFqB0g021938; Tue, 23 Jul 2019 08:59:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=R9/hvJ5CglPEjLGOarvDIGQst2S2/oAxjPZGFAednXc=; b=AGIduK3S+yRuAb+RsSirUouO85GLMVnvXoC2IH64vCjm18FIwerqfsjGT+rNT1AfJdqS ytjHvAI0CYiIujhNi07K6P5K6FUybc0fniLCrxohwgQQ8nCp6MuJ1D8K0x1khjqte4EU L2eSIsYQZfrevdx5t6a/dbqi0q+53Dsnc2phFONOHLpkyNxRlUBaq6iqjiQsA3n5pq8d AvI8ymtbMw7Vwhiit97awtMKF3IYSB+GJO0hlk1QcGuJfDKFO9Av05Bh6gCrVthdsUYX 3ggdXuTe/6vBbnX9KxGWJGCPegJljcLm3RGBX/DXf+F1uR8FrmyCVEuG2zlB+UoI64AI KQ==
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2tvk6mxkss-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 08:59:30 -0700
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV3008YDR35R230@mr2-mtap-s02.rno.apple.com>; Tue, 23 Jul 2019 08:59:29 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV300I00QQTP400@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:59:29 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 3411a62f3898e2de3a4b1b275171c74f
X-Va-E-CD: 844c7cd8bab9de5eb47f49962d389d34
X-Va-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86
X-Va-CD: 0
X-Va-ID: 4857e7d4-bfeb-4f1d-bd5b-76dd24ab5777
X-V-A:
X-V-T-CD: 3411a62f3898e2de3a4b1b275171c74f
X-V-E-CD: 844c7cd8bab9de5eb47f49962d389d34
X-V-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86
X-V-CD: 0
X-V-ID: a12e45c6-8922-4f06-ac86-894331909eda
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-23_07:,, signatures=0
Received: from [17.235.51.16] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV300BODR335J00@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:59:29 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <FE3F9BD0-2052-4FD4-8799-4AA90B66B0A4@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_1BD41395-0E94-444E-950A-926CEE979F1F"
MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Tue, 23 Jul 2019 11:59:24 -0400
In-reply-to: <CE86E597-831E-478A-B75D-147D65AE47E5@strayalpha.com>
Cc: Theresa Enghardt <theresa@inet.tu-berlin.de>, taps@ietf.org
To: Joe Touch <touch@strayalpha.com>
References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> <F9C04679-79DB-4CAA-9710-DD5C04FD30E8@apple.com> <5D3722DF.8070000@erg.abdn.ac.uk> <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> <CE86E597-831E-478A-B75D-147D65AE47E5@strayalpha.com>
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_07:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/Juvr93uzRnbvZqC8bkAmPPctsYk>
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 15:59:35 -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,
Tommy

> On 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 <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
> https://www.ietf.org/mailman/listinfo/taps

v2.23.0 | Report a Bug | By Email