Re: [Taps] TAPS Documents for Charter Item 3
"Aaron Falk" <aaron.falk@gmail.com> Mon, 22 January 2018 20:05 UTC
Return-Path: <aaron.falk@gmail.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 11B961270A0 for <taps@ietfa.amsl.com>; Mon, 22 Jan 2018 12:05:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Mo2_TmIzfZK3 for <taps@ietfa.amsl.com>; Mon, 22 Jan 2018 12:05:20 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 1E0B212706D for <taps@ietf.org>; Mon, 22 Jan 2018 12:05:19 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id z11so24047568qtm.3 for <taps@ietf.org>; Mon, 22 Jan 2018 12:05:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=3TXkePEEuBZDmJlRUXCuPqTpb38LKGRJ42aAv2FkIcs=; b=D5PgNK8Gr7HslPwsjj4CWa9/YyGQVR4m45OWFahAQKs60ptf17HFmvGb++S1pMEXLd FuL/6jJQenu9caR0jwXwNyKOmg5f3A9gvJ6W7jks/FLuEo5m9pS09HYAHaDc1u3y8uc8 8nMgLapNYH2589RR1X5dA3Svk3B6oFqgU5liW8sC3ebFA1B1InzB1yF09Rq2O1W4MGfY 2uW52BsWrSnMhkJn2chqhXWGZACsMt6NyCb/VpsnqQhcyHpmZ2AOr3CtkZNxj/nw0WNd R4Ir4gcgLRTU0zjqN7u5q6gET6tQ1BaewnJm9VELvUxl9fq0ZH+OMVymX8RpDV/VSxX1 4igg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=3TXkePEEuBZDmJlRUXCuPqTpb38LKGRJ42aAv2FkIcs=; b=VDElajlQ6PLGf0nCHUV0c6xrRmNr90/CluA5nyP1ynep3diAMg6z1+EPsFN1htzKXY jM4ABBF8FABz8tatP9gosa++BAVQaghA9/6IDjclBX1MuYEvBAZJPVlxOZhNk7vAI/tp HiqPpK5/o8c72s/z+Sso61Ds8p3a/TNFP+2wPEvbwTZfT1MFdRjUooWRa7HHEo7W5grE poe6i3R6SYaKfRq0dgnHbH2MQnkw7KHX18nsGXXTzGG32VG1dGZAiUMkQVibHl5WiJ4s 2kmSwqyOLKutkpWbcAjVVHfXw8kE9DXFlDCBIpYxPWGbM8gRiPGJaQi0No1o3f+FBT4V i4jQ==
X-Gm-Message-State: AKwxytfLdRymv4dfgQt9JV2pFMI/rcC2HOD18kNaU0cptQMHwKsPgiqF 4vwLWdMXzLGCGHSlllc40yM=
X-Google-Smtp-Source: AH8x2274Mc+x/fYuWnDPjAV9WQcS0vgDQvQqGzTT93NdY+I6B5RGqbGKSG3YJ8aRF6wK1ROns7voIg==
X-Received: by 10.200.37.216 with SMTP id f24mr12379496qtf.165.1516651518051; Mon, 22 Jan 2018 12:05:18 -0800 (PST)
Received: from [172.19.42.4] ([2601:184:4980:a321:ad2c:a022:cd3c:59bb]) by smtp.gmail.com with ESMTPSA id e16sm11990509qte.97.2018.01.22.12.05.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 12:05:17 -0800 (PST)
From: Aaron Falk <aaron.falk@gmail.com>
To: Christopher Wood <christopherwood07@gmail.com>
Cc: Tommy Pauly <tpauly@apple.com>, Michael Welzl <michawe@ifi.uio.no>, taps@ietf.org
Date: Mon, 22 Jan 2018 15:05:15 -0500
X-Mailer: MailMate (1.10r5443)
Message-ID: <AC61208A-87AE-4241-AC12-6DCF19AE1476@gmail.com>
In-Reply-To: <CAO8oSXkOmf_F89xsoxyZrABdinQq6OVD94zyWt_XpuOQMsUP1w@mail.gmail.com>
References: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> <E2E5D336-27BF-4F83-BECD-0589FC2769AB@ifi.uio.no> <FA73A113-B3BE-4E95-B3D1-76397E63ABD8@apple.com> <CAO8oSXkOmf_F89xsoxyZrABdinQq6OVD94zyWt_XpuOQMsUP1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_B8E78D88-1C4B-44F9-BCC1-2F46BC500383_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"HTML":[840, 14439], "plain":[461, 6272], "uuid":"13327A26-1C2E-4EC6-8E80-F4FD172660B5"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/9pS8T7PV5QSzW0qtCVihuaKtpug>
Subject: Re: [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: Mon, 22 Jan 2018 20:05:24 -0000
I like this structure (quite a bit!) but it’s not clear to me from the discussion whether we have one approach or several. Can we consolidate into a single approach? We had discussed this in Singapore but I want to be sure folks believe it. :) When we chartered, we imagined that there may be multiple approaches, which seemed undesirable but tolerable given the researchy nature of the wg. —aaron On 18 Jan 2018, at 10:02, Christopher Wood wrote: > On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <tpauly@apple.com> wrote: > >> >> >> On Jan 11, 2018, at 12:23 AM, Michael Welzl <michawe@ifi.uio.no> >> wrote: >> >> Hi Tommy, >> >> A few answers below: >> >> On Jan 10, 2018, at 6:11 PM, Tommy Pauly <tpauly@apple.com> wrote: >> >> 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. >> >> >> Funny, I have also been thinking about item 3 in exactly this way for >> a >> long time … and I believe we two are not the only ones. >> This split really seems quite natural. >> >> >> Good to hear that the split seems reasonable! >> >> >> 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: >> >> >> *A* >> *B* >> *C* >> *1. TAPS Architecture* >> Connection Establishment >> Data transfer >> Policy and Path Selection >> *2. TAPS API* >> Initiator/Listener/Responder >> Send/Receive >> 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 >> >> >> I agree with this rough assessment. This table is good to think >> about! >> I think draft-tiesel-taps-communitgrany is missing for 1) (not sure >> if >> it’s A / B / C, but it’s about terminology) >> >> >> Yes, this wasn’t a complete list. Also note that I’m not >> proposing that we >> adopt any of the documents as they are, but specifically adopt WG >> items for >> Architecture, API, and Implementation, and we build those documents >> from >> the existing ones, taking the best parts of all of them. >> >> >> >> 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? >> >> >> Personally I like the approach but I’d caution that we need a tight >> connection between the lines in the table. For everything we do, we >> must >> make sure it’s implementable, and explain how. Hence, a document >> describing >> API primitives should also clarify how these primitives could be >> implemented - with the split you describe above, by pointing at a >> specific >> section for each functionality in a "line 3” document (if these >> things >> really are going to be separate documents?). >> >> >> That’s why I’d propose having three documents that are adopted as >> a group, >> that are designed to go through the process together, and heavily >> reference >> one another. The definition of what goes in each should be based on >> the >> audience. One other comment I have for the API is that it should >> likely >> remain agnostic to specific protocols: it should say “here’s how >> to >> send/receive with these kind of options, and protocols will treat >> them like >> this”; but the implementation document can go into details of how >> those map >> down to specific protocol details in existing mappings (TCP, SCTP, >> UDP, >> QUIC). My two goals in saying this are: >> 1) The API should be simple and easy to understand for an adopter’s >> perspective >> 2) The API should be relevant despite changes in transport protocols >> de >> jour. Maybe in fifty years no one is using TCP anymore; we’ll >> publish >> implementation and mapping updates, but the API document should still >> be >> unchanged. >> > > +1, especially for decoupling the API from specific protocols. > > Best, > Chris > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
- [Taps] TAPS Documents for Charter Item 3 Tommy Pauly
- Re: [Taps] TAPS Documents for Charter Item 3 Michael Welzl
- Re: [Taps] TAPS Documents for Charter Item 3 Tommy Pauly
- Re: [Taps] TAPS Documents for Charter Item 3 Christopher Wood
- Re: [Taps] TAPS Documents for Charter Item 3 Aaron Falk
- Re: [Taps] TAPS Documents for Charter Item 3 Tommy Pauly