[Taps] TAPS Documents for Charter Item 3

Tommy Pauly <tpauly@apple.com> Wed, 10 January 2018 17:11 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9211B12DA24 for <taps@ietfa.amsl.com>; Wed, 10 Jan 2018 09:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bsjnonbROI7d for <taps@ietfa.amsl.com>; Wed, 10 Jan 2018 09:11:48 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com []) (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 44BFD12D875 for <taps@ietf.org>; Wed, 10 Jan 2018 09:11:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1515604308; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=n31jI9flPbvpeM4lVnNJyUvp2ttHGV0BAxpEzo/X7jQ=; b=EPQLN5wg7TFfJNHpIkkTOUBhLvIONOHMK9AeNkvBAm2Lo50lVUsOWBtWc7WkK2zU sOUEITK4OpT2Ktf9UEQ9qiGFWc2igwO2oIhYWVjLRseA8DNSrT5K1xPTWWI3y8R6 6637GcvnrhgEfPW2vqW+PBmM3itrwbDyUerglGL5AF30c4vb7l9ygVONs/YNbYVY vWIIz6jvXZhZAEkZxFm9A5XIPssJiU1l5BKa/FwvVlqMc04mKsuxAtf4HoiAEMPK QdmHNd2VpKhDLSRSUBv3y/LL4Mab+SGld+7sge2KkOGpVblIikalxSSAFyadNy6a iFA+vx59wTDYXutKKqQc+w==;
Received: from relay3.apple.com (relay3.apple.com []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id B5.B1.16042.459465A5; Wed, 10 Jan 2018 09:11:48 -0800 (PST)
X-AuditID: 11973e12-801fd9c000003eaa-ea-5a564954a4a6
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com []) by relay3.apple.com (Apple SCV relay) with SMTP id 86.FC.12852.359465A5; Wed, 10 Jan 2018 09:11:48 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_fmjFdq7W+xOzElL0nnZNaw)"
Received: from [] (unknown []) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 64bit (built Dec 4 2017)) with ESMTPSA id <0P2C00600NRN3070@nwk-mmpp-sz13.apple.com> for taps@ietf.org; Wed, 10 Jan 2018 09:11:47 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com>
Date: Wed, 10 Jan 2018 09:11:46 -0800
To: taps@ietf.org
X-Mailer: Apple Mail (2.3458)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAYrBviGRZl8Osvs8WdGAdGjyVLfjIF MEZx2aSk5mSWpRbp2yVwZSx/vpK5oHcCY8WSQ9eZGxhv1XQxcnBICJhIfOiQ7GLk4hASWM0k ceb/RrYuRk6weN+n3awQiUOMEidPNbKDJHgFBCV+TL7HAmIzC4RJ3N/5hRmiaCGTxOw7e9hA pgoLSEhs3pMIUsMmoCJx/NsGZhBbWEBL4vPXN0wQc2wktr6fC2azCKhK3Lg1E2y+CND8rSe7 WSGOkJVYOfsu2BESAndZJaZuv8s4gZF/FpI7ZiG5YxbQamYBdYkpU3IhwtoST95dYIWw1SQW /l7EhCy+gJFtFaNQbmJmjm5mnoleYkFBTqpecn7uJkZQqE63E9rBeGqV1SFGAQ5GJR7eDeJh UUKsiWXFlbmHGKU5WJTEefd98Y8SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMiVm3NxumvF 0ovrir1MKnN/Bq/c2M1wylXgi6Q1g9oMiS8a6qu2lFs270l0s809u2XnfZ6ueV393OsVD3Fw 5zvIb9wckZCtvnylRoyS1+aItWwZQjGPp/AGRqTFyt+ZnBEVe6F7OePGoIa7PNXKn84u6Psz t/0g22vW7xNu+2yvTE6KWqi1U4mlOCPRUIu5qDgRAGg9Vyk2AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FB8QzfEMyzK4KqexZ0YB0aPJUt+MgUw RnHZpKTmZJalFunbJXBlLH++krmgdwJjxZJD15kbGG/VdDFyckgImEj0fdrN2sXIxSEkcIhR 4uSpRnaQBK+AoMSPyfdYQGxmgTCJ+zu/MEMULWSSmH1nD1sXIweHsICExOY9iSA1bAIqEse/ bWAGsYUFtCQ+f33DBDHHRmLr+7lgNouAqsSNWzPB5osAzd96spsV4ghZiZWz77JOYOSZhWT1 LCSrZwFtYxZQl5gyJRcirC3x5N0FVghbTWLh70VMyOILGNlWMQoUpeYkVhrrJRYU5KTqJefn bmIEh1Zh8A7GP8usDjEKcDAq8fBGiIZFCbEmlhVX5gL9z8GsJMLrZA4U4k1JrKxKLcqPLyrN SS0+xCjNwaIkznvIDiglkJ5YkpqdmlqQWgSTZeLglGpgbF944Oe7beVXrZ6E3pq8qfriBK2L zvtmz0hxfs51941uHof97vVlqtyHec+2+jPv1emcGq6ZYXblrLzbj5RaDWGvfwyrVu7rEr98 1FF7hcHWZ8c2c9owbS1y536z5YFa11+GiUwl28Q/S94KDat1bjjoc/qcPmN6bTbr1T5VU0me Vf9+Vei5K7EUZyQaajEXFScCALbOedQpAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/aeWjbESg2iNU7l569KLJ8CcO-kM>
Subject: [Taps] TAPS Documents for Charter Item 3
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 10 Jan 2018 17:11:51 -0000

Hello TAPS,

In Singapore, there was much discussion about where we go after the minset drafts, and what documents will form charter item 3:

3) Specify experimental support mechanisms to provide the Transport 
Services identified in work item 2. This document will explain 
how to select and engage an appropriate protocol and how to 
discover which protocols are available for the selected service 
between a given pair of end points. Further, it will provide a 
basis for incremental deployment. Work on this document will 
begin when the TAPS Transport Services have been specified.

Since it would be good to get convergence and adoption of documents in London, I’d like to take a stab at how we can structure the WG documents and start a discussion on this list to decide our collective approach.

At a high level, based on the work of NEAT, Post Sockets, Happy Eyeballs, Socket Intents, etc, it seems like the “support mechanisms” for TAPS are converging into categories (a) how to expose functionality in an Abstract API and (b) guidance on how to implement a library that provides TAPS functionality. These two categories are not unrelated, but have different audiences; Abstract APIs are aimed at adopters of a TAPS system, while the implementation guidance aspects are aimed at library and system implementers. The high-level concepts that bind these together form the overall TAPS architecture.

Looking at things in this way, I could imagine three documents, which would form the capstone of the TAPS work
1) TAPS Architecture: high level explanation of the approach and goals, how the API and implementations relate, and how the system is derived from the protocol surveys and minset. Defines consistent terminology for concepts used in the other documents.
2) TAPS API: document aimed at adopters taking advantage of a TAPS system: configuration, initiation of channels, listening/responding, data transfer, and maintenance.
3) TAPS Implementation Guide: document aimed at implementers on how to bring up connections (handling a multiplicity of paths, endpoints, and protocols), sending and receiving data through protocol stack instances, and interpreting configuration and system policy into decisions.

I believe that many (or all) of the outstanding documents we have in the WG already fall into one or more of the categories. Here’s a table with the three proposed documents as 1, 2, 3, and three aspects of a TAPS system/architecture as A, B, C:

1. TAPS Architecture
Connection Establishment
Data transfer
Policy and Path Selection
Intents and configuration
3. TAPS Implementation Guide
Protocol Racing, Path Racing, Happy Eyeballs
Protocol Stack Instance
Policy engine

In this table, we could see the existing documents contributing aspects to certain blocks:

draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C
draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B)
draft-pauly-taps-guidelines: 3A, (1C)
draft-grinnemo-taps-he: 3A
draft-tiesel-taps-socketintents: 2C

This is a rough assignment and not necessarily exhaustive, but the point is that much of the content is probably already there is some form, and can be reinterpreted into these documents.

What do people think about this approach? Any aspects that are missed here that would need to be separate documents, or new sections across the documents?