IETF Logo Mail Archive

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

Joe Touch <touch@strayalpha.com> Tue, 23 July 2019 16:14 UTC

Return-Path: <touch@strayalpha.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 83E34120344 for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 09:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level:
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 QXZEHs1KKsjw for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 09:14:51 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 AF7B012036E for <taps@ietf.org>; Tue, 23 Jul 2019 09:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m6JGRQ7/ZhMY36U7AWY09qXr0BJv0hDXt4nNF/i1JPk=; b=kiIE8ADqX865XqnQqT9IIflYz baYidm+jSp6pkqw25VEnSww8WyIi5JDe6f83JC+MDUh2r/sV9HBUfRyJeySLaDPN+1umvG+bfkG5T 8E7BpAY31W6gN6LKKSpartxGXxgpR39irdSbrxTX2bRhRfIlAWt02NuqtURJ0Wmk4k4gDy+hzn5nA 8Dvc5fhyuPQd7vf46T9GCs8vv0RyTIwPWtLHgs1pQe7P1lpUgnfkCYpjvUM9nWOmrz+12aIxACUuD j+2NdD/QPnlvu4oi0lodF191WkO/EkC7T3CBVpgD1by117ItyiXzchVeYArRGWkZv9XRrajjcSurW lC2ylMfFA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55829 helo=[192.168.1.11]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hpxR8-004HmV-If; Tue, 23 Jul 2019 12:14:51 -0400
To: Tommy Pauly <tpauly@apple.com>
Cc: Theresa Enghardt <theresa@inet.tu-berlin.de>, taps@ietf.org
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> <FE3F9BD0-2052-4FD4-8799-4AA90B66B0A4@apple.com>
From: Joe Touch <touch@strayalpha.com>
Message-ID: <4263a14e-9f29-e009-45fa-52acca139be5@strayalpha.com>
Date: Tue, 23 Jul 2019 09:14:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <FE3F9BD0-2052-4FD4-8799-4AA90B66B0A4@apple.com>
Content-Type: multipart/alternative; boundary="------------CE02AD1FB5D14EF6AF10432A"
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/2SsdW72MaPCyTclQTegrgJ9nfdU>
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:15:05 -0000

You've specified this as if it were an individual property. You need to
deal with sets of properties, perhaps including choices (A and B) or (A
and C) but not (A and B and D)...

This is widely known as "constraint satisfaction", unsurprisingly.

Joe

On 7/23/2019 8:59 AM, Tommy Pauly wrote:
> 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
>

v2.23.0 | Report a Bug | By Email