Re: [Taps] TAPS Documents for Charter Item 3

[Christopher Wood <[e-mail]>]

On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <[e-mail]> wrote:

>
>
> On Jan 11, 2018, at 12:23 AM, Michael Welzl <[e-mail]> wrote:
>
> Hi Tommy,
>
> A few answers below:
>
> On Jan 10, 2018, at 6:11 PM, Tommy Pauly <[e-mail]> 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