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 protected]> 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 18 Jan 2018, at 10:02, Christopher Wood wrote: > > On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <[email protected] > <mailto:[email protected]>> wrote: > > >> On Jan 11, 2018, at 12:23 AM, Michael Welzl <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Tommy, >> >> A few answers below: >> >>> On Jan 10, 2018, at 6:11 PM, Tommy Pauly <[email protected] >>> <mailto:[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. > > +1, especially for decoupling the API from specific protocols. > > Best, > Chris > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > <https://www.ietf.org/mailman/listinfo/taps>
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
