On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <tpa...@apple.com> wrote:
> > > On Jan 11, 2018, at 12:23 AM, Michael Welzl <mich...@ifi.uio.no> wrote: > > Hi Tommy, > > A few answers below: > > On Jan 10, 2018, at 6:11 PM, Tommy Pauly <tpa...@apple.com> 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 Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
