Re: [Taps] New Transport Networking APIs in iOS 12 beta

Jonathan Lennox <jonathan@vidyo.com> Mon, 11 June 2018 16:47 UTC

Return-Path: <jonathan@vidyo.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 60D53130FF1 for <taps@ietfa.amsl.com>; Mon, 11 Jun 2018 09:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.411
X-Spam-Level:
X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.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 eyvyzej6iz7M for <taps@ietfa.amsl.com>; Mon, 11 Jun 2018 09:47:15 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772E6130E70 for <taps@ietf.org>; Mon, 11 Jun 2018 09:47:15 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id a18-v6so3633102qtj.4 for <taps@ietf.org>; Mon, 11 Jun 2018 09:47:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JqP0aH6zv6Pex9WpZ3jSbej9GpVm11nKi9EVw7jk6M8=; b=HhpHfYFo50iFQgdNhDc9z6kTr4LLtrUu4vfx214Vhvi7DdbzKDxNytBSiDgmoKq6ri pEDk8tuedPNGm4cx4XgOd8UR13uCT1dsyjparIQFncbQ3oZPR6nhOjuAdMzBLMR8zfjy yc2GFiXVSZnQ5Gg1GGt4ZCl43gJ2OvPeNRDRfkyDKTkivhFJWIPmXR1rc+iM8+QPJlTj jBh7tDt3HYo6O85lAzFPCRUL+hulb5ype1D62R/OemmdZ01AMr6kwMQps++caVnt0Odj b7anDZCDPfbVNL8VwXb22bg/kIZmAL+ZuGWwYSm/R1QQmkx5QfN4LIa9+HdbcNRdfxPc sL4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JqP0aH6zv6Pex9WpZ3jSbej9GpVm11nKi9EVw7jk6M8=; b=B1XdNf/S31IrqTyqaPBdoQnYE3Dk5rzTNraE7mUeisb3gKUA+dvRUdx8Z8LtUN9ZoR dipyfuHRul6lD+6WpDjf3I77wsxrmGi7NkOhQINZLwmqq2m20l+dVyoGlQHdq2ORW4im xu8HkGsgqn5wBImMxFpeM2UbfO1fuOaxoBlmB7x+OV0SRIlYzHT8TpqwBqbwfXvQes6Q CRpcfYeX4cxh/3BjSI2H1SzP8hTtzhI4kOyzffisZS8a4v2AEPoGnOJmOkTXq42oJZC1 BGHM6ZrmbI5PJt1d8ragSMlzT5sJgSuZeF9YsArjomnitVEGyxmZbtyiG9Cf4CYnSA+X xyQg==
X-Gm-Message-State: APt69E36qGDZ6/z4gIm0niw81e5OnlIl3ko1D2RSrc3qJ0BON38D5A6j fJUaObsOOMqxcvKazQvv7Qq9vw==
X-Google-Smtp-Source: ADUXVKLObYT3tKo0jLKjvXT7E06neNziq4S3UtwFsp+W81oJZkyt5mGoNBXzF6YKe5fj9ZacJ+MSJw==
X-Received: by 2002:a0c:985a:: with SMTP id e26-v6mr15857774qvd.44.1528735634496; Mon, 11 Jun 2018 09:47:14 -0700 (PDT)
Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id p72-v6sm25289366qki.15.2018.06.11.09.47.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 09:47:13 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Lennox <jonathan@vidyo.com>
In-Reply-To: <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no>
Date: Mon, 11 Jun 2018 12:47:12 -0400
Cc: Tommy Pauly <tpauly@apple.com>, "taps@ietf.org" <taps@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com>
References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/svgH0RyNQyfSLiF1pOdHfq5Qt3o>
Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.26
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, 11 Jun 2018 16:47:18 -0000

I’ve read over Apple’s new API.  (One note: the URL that Tommy sent a link to doesn’t have the full documentation of the API yet; many of the types and methods still say “No overview available.” If you’re an Apple developer, the header files supplied with the macOS 10.14 and iOS 12 beta SDKs in the Xcode 10 beta contain much fuller versions of the documentation.)

The main difference I’ve found between TAPS and Network.framework is that Network.framework doesn’t have a Preconnection object.  Instead, Connection objects for outgoing connections are directly created from a constructor, and then must have their .start method called before they act.

This part is a relatively minor semantic difference, but more significant is how incoming connections are handled.  In Network.framework, there is a Listener object with a new_connection handler, and this object can produce unlimited numbers of Connections until stopped.  This is unlike TAPS where a Listen action consumes a Preconnection, and to receive multiple connections on the same port, Listen must be called on multiple cloned Preconnections.

I feel like the Network.framework model is an easier programming model for most use cases, but it has the downside that an API user has no way to pace its handling of incoming connections.

> On Jun 10, 2018, at 4:02 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> Hi,
> 
> This - in particular your answer to Michael - is indeed extremely cool! Thanks to you and your colleagues at Apple for pursuing this direction, and thanks for sharing it with the group!
> 
> About this statement in the original email:
> ***
> Either way, we’d love for everyone to take a read through the API and give feedback on how we can continue to evolve things towards a post-sockets and fully TAPS model.
> ***
> 
> I think an obvious answer to this is: the more in line with draft-ietf-taps-interface it is, the better - and where it’s not, it would probably be interesting for the group to know the reasons.
> 
> Cheers,
> Michael
> 
> 
> 
>> On Jun 9, 2018, at 10:54 PM, Tommy Pauly <tpauly@apple.com> wrote:
>> 
>> Hello Michael,
>> 
>> The architecture is designed specifically to allow loading different protocols. The parameters object is centered around a “protocol stack” configuration object, which is composed of protocol options for defined protocol implementations. This only exposes a default stack now, but is designed to offer the configuration of alternate stacks as well. In this first version, we’re only letting developers compose stacks with pre-defined protocols, but I want to allow custom protocol definitions and implementations going forward—for both simple framers, as well as full blown transports like SCTP and QUIC! The model of the connection sending and receiving messages is sufficiently generic to support any of the TAPS protocols. 
>> 
>> Best,
>> Tommy
>> 
>> On Jun 9, 2018, at 11:38 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>> 
>>>> On 8. Jun 2018, at 18:29, Tommy Pauly <tpauly@apple.com> wrote:
>>>> 
>>>> Hello TAPS!
>>>> 
>>>> This week we released Network.framework, a new set of transport APIs, as part of the beta for iOS 12 and macOS Mojave.
>>>> 
>>>> This API provides support for connections and listeners using TCP, UDP, TLS, and DTLS; connecting by name or service, with happy eyeballs support for addresses, interfaces, and protocols (for proxies, etc). This provides our basis for “post-sockets” API work. As we define as a working group more of the full TAPS API vision for protocol agility, we'd like on add that support to this framework. 
>>> Hi Tommy,
>>> 
>>> great news!
>>> Is there also a possibility to add new transports to the framework, like
>>> SCTP or QUIC?
>>> 
>>> Best regards
>>> Michael
>>>> 
>>>> Video of the presentation:
>>>> https://developer.apple.com/videos/play/wwdc2018/715/
>>>> 
>>>> Sample implementation of netcat:
>>>> https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework
>>>> 
>>>> Swift and C API:
>>>> https://developer.apple.com/documentation/network
>>>> 
>>>> If you are an iOS or macOS developer, please try out the APIs! Either way, we’d love for everyone to take a read through the API and give feedback on how we can continue to evolve things towards a post-sockets and fully TAPS model. Note that on iOS and tvOS, this framework is currently using a user-space networking stack instead of sockets when applicable.
>>>> 
>>>> Best,
>>>> Tommy
>>>> _______________________________________________
>>>> Taps mailing list
>>>> Taps@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/taps
>>> 
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps