IETF Logo Mail Archive

Re: [Taps] On Profiles for TAPS Preconnections

"Philipp S. Tiesel" <philipp@tiesel.net> Mon, 22 July 2019 22:56 UTC

Return-Path: <philipp@tiesel.net>
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 186AA1200BA for <taps@ietfa.amsl.com>; Mon, 22 Jul 2019 15:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 CUYDN-jVDMlp for <taps@ietfa.amsl.com>; Mon, 22 Jul 2019 15:56:40 -0700 (PDT)
Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 394CC1200DE for <taps@ietf.org>; Mon, 22 Jul 2019 15:56:40 -0700 (PDT)
X-Envelope-From: philipp@tiesel.net
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6MMuXNl016871 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 00:56:33 +0200
Received: from [2001:67c:370:128:6d26:adba:4d25:1628] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipp@tiesel.net>) id 1hphCP-0000K8-Bb; Tue, 23 Jul 2019 00:54:29 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: "Philipp S. Tiesel" <philipp@tiesel.net>
In-Reply-To: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com>
Date: Mon, 22 Jul 2019 18:56:30 -0400
Cc: taps WG <taps@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net>
References: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/x4U2Kk-f53a5tmVwdWE2ybhqYoc>
Subject: Re: [Taps] On Profiles for TAPS Preconnections
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: Mon, 22 Jul 2019 22:56:42 -0000

Hi,

> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> 
> An issue we discussed today in the TAPS meeting was whether or not we should add a concept of "profiles" to the Transport Services APIs. An example of a profile is a "reliable, secure, in-order stream"; or "unreliable datagrams". Another way to think of these profiles are as convenient ways to initialize common parameters.
> 
> One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328
> 
> To help discern the working group's position, I'll try to distill the high-level options here:
> 
> 1. Add Profiles as a top-level API document concept that modifies how transport properties and/or preconnections are created. (This is PR #328.)
> 2. Mention in the API document that specific API implementations may expose conveniences and profiles (presumably as a way to initialize preconnections), but do not modify the API or specify an abstract symbol for profiles.
> 3. Do not mention profiles at all in the API document, but mention something in the implementation document.

I am definitely in favour of option 1. Our implementation experience with PyTAPS showed that setting all transport properties necessary to get “UDP like service” becomes tedious otherwise.
I fear not including them in the examples and the core API will result in many developers rejecting TAPS as too complex to use.
The profiles provide a useful convenience to applications (just like the the shortcuts properties.prefer(property) instead of properties.add(property, prefer)).

In addition, profiles allow us to be less conservative in how we choose the defaults for transport properties, i.e., we don’t need the TAPS defaults to be TCP compatible as long as the reliable-in-order-stream profile is.

AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

v2.23.0 | Report a Bug | By Email