Subject: [Taps] TAPS Documents for Charter Item 3

From: Tommy Pauly <[email-masked]>
Date: Wed, 10 Jan 2018 09:11:46 -0800

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:

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

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?

Thanks,
Tommy

---

From: Michael Welzl <[email-masked]>
Date: Thu, 11 Jan 2018 09:23:24 +0100

Hi Tommy,

A few answers below:

> On Jan 10, 2018, at 6:11 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hello TAPS,
> 

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.

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

> 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?).

Cheers,
Michael

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Jan 2018 07:28:10 -0800

> On Jan 11, 2018, at 12:23 AM, Michael Welzl <[email-masked]> wrote:
> 
> Hi Tommy,
> 
> A few answers below:
> 
>> On Jan 10, 2018, at 6:11 PM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello TAPS,
>> 

Good to hear that the split seems reasonable!

> 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.
> 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…

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.

Thanks,
Tommy
> 
> Cheers,
> Michael
> 
> _______________________________________________
> Taps mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>

---

From: Christopher Wood <[email-masked]>
Date: Thu, 18 Jan 2018 07:02:14 -0800

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

> In Singapore, there was much discussion about where we go after the minset
> drafts, and what documents will form charter item 3:
>
> 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.
>
> 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.
> 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
> *2. TAPS API*
> *3. TAPS Implementation Guide*
> 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:
> 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

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 22 Jan 2018 15:05:15 -0500

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:

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

> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 22 Jan 2018 12:59:50 -0800

I think we’re going to try to discuss and come together for a single approach for the architecture and documents. Ideally, I’d like to see a single set of unified Architecture/API/Implementation documents that embody the generic TAPS work as an approach. However, since there will be many different implementations (which is always a good thing for IETF work), I’d expect that the specific names and terms will vary in the individual codebases. The goal would be that the documents provide a common set of language for referring to aspects beyond any one implementation as a framework and guide for specific implementations.

If we can get all agreed, it would be great to have a set of common documents we can look over for London!

Thanks,
Tommy

> On Jan 22, 2018, at 12:05 PM, Aaron Falk <[email-masked]> wrote:
> 
> 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 Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Jan 11, 2018, at 12:23 AM, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Tommy,
>> 
>> A few answers below:
>>