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:24 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 D03B71203CE for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 08:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, 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 GuZWh5aaveZX for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 08:24:52 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 E456F120369 for <taps@ietf.org>; Tue, 23 Jul 2019 08:24:46 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NFLwnu006397; Tue, 23 Jul 2019 08:24:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=ZZNE3+Gxr3KOBN/K1QhFYZekCGvVnPacZEXo5evyO3o=; b=ahYQ0zabu603sGGsE/a5z35Hhiz29u9doWdRSUF1mMFwLRKA4cTc2CDmcryt/MyP7nAY j1D8FkY9ewAEbW95qXMtNQMibWWttW3HEcjQO/ZmkQbdP9lejWODiqYr19zFo15V3d3P CCf3oGmKwy0I266bed0b5KL2Je7jN+PFkgkI6LOtTS5icd7XvXPNfHDIpXWVptyDCCXN pX6bSvML6l0XJLrvFmxh9KSeiXuS6KNpZE13jdwRxbg+YlGB6ar8PTx+rEUYOjFsPQfk LFFHZNTjRmtlB1vpwA6QWWaHZhdSO6yXy123GBr+BF+AUSwyqxli8+gTAmMJgS//zPGA JA==
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2tv1y0j0ec-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 08:24:45 -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 <0PV30094PPH7HGD0@mr2-mtap-s02.rno.apple.com>; Tue, 23 Jul 2019 08:24:43 -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 <0PV300I00P9Q2D00@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:24:43 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 243d5618d6c40fa8f19ea30f70110151
X-Va-E-CD: 844c7cd8bab9de5eb47f49962d389d34
X-Va-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86
X-Va-CD: 0
X-Va-ID: b711b49b-0e89-46cf-b151-98576b593df7
X-V-A:
X-V-T-CD: 243d5618d6c40fa8f19ea30f70110151
X-V-E-CD: 844c7cd8bab9de5eb47f49962d389d34
X-V-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86
X-V-CD: 0
X-V-ID: 42e1dd60-d2cc-4241-b83c-89ea9927ee9a
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 <0PV3003QAPH4L200@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:24:43 -0700 (PDT)
Sender: tpauly@apple.com
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de>
Date: Tue, 23 Jul 2019 11:24:36 -0400
Cc: taps@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <68B96C1C-B5E6-4630-8019-10C704251B87@apple.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>
To: Theresa Enghardt <theresa@inet.tu-berlin.de>
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/u01A_jjtMzWaIuTZJNjl9PmNElY>
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:25:05 -0000


> On Jul 23, 2019, at 11:19 AM, Theresa Enghardt <theresa@inet.tu-berlin.de> wrote:
> 
> Hi,
> 
>> On 23/07/2019, 10:31, Tommy Pauly wrote:
>>> […] 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.
> 
> Another important difference between TCP and UDP are Message Boundaries.
> So in some cases, TCP + Framer may be equivalent to UDP.

Exactly! That's what I meant by "a message protocol over TCP".
> 
> 
> We probably don't want to put that in the Architecture draft, but a
> Framer can essentially provide the "Message boundaries" property, thus,
> making TCP equivalent to UDP if Message boundaries are required, right?

Yes, I think that's already implicit in the text in Section 4.2.3, point 1. TCP doesn't preserve boundaries on its own/if it's the top (but does if there's another protocol that does).
> 
> Maybe that's something for Implementation draft? But the application may
> also want to know about the possibility to essentially use TCP or UDP
> without having to change (much)? Thinking about DNS, even if there may
> be more stuff to consider here, such as the EDNS0 features Ted Hardie
> mentioned.

I agree that the implementation document is a more appropriate place to discuss the particulars of which protocols can be determined to be equivalent.

Thanks,
Tommy
> 
> Best,
> Theresa
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

v2.23.0 | Report a Bug | By Email