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