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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
