Re: [Taps] TAPS Documents for Charter Item 3

["Aaron Falk" <[e-mail]>]

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 <[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


> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps