Taps Status PagesTransport Services (Active WG)
Tsv Area: Martin Duke, Magnus Westerlund | 2014-Sep-23 —Chairs:
IETF-93 taps agenda
Session 2015-07-23 1300-1500: Karlin I/II - taps chatroom
Transport Services (TAPS) Working Group Thursday, July 23, 1300-1500 Karlin I/II Note: all discussion is regarding completion of draft-ietf-taps-transports-06 0. Administrivia (5 min) 1. Review of schedule for taking draft-ietf-taps-transports to working group last call this year. (5 min) 2. Review of protocols we don't have text for yet. (We're looking at you, RTP.) (5 min) Q: Are there any other missing protocols worth holding up the document? 3. Document Review (30 min) Discussion of "refactored" transport protocol components. In -06 we have redefined the components of TCP to be closer (in our opinion) to the actual interactions between each of the behaviors of the protocol. This is necessarily messier than starting from a "clean" set of features and working backward, as TCP was not designed as a composition of behaviors, rather evolving around a set of constraints. Q: Is this an acceptable approach? 4. Substantive Discussion: Features (30 min) Regardless of how we decompose the protocols, we do know enough about *some* transport service features to start writing detailed information about the features -- the discussion here will focus on draft-gjessing-taps-minset and/or section 4 of draft-ietf-taps-transports. Q: Administrative question: where is the split between these documents? Q: Primary technical question: what do we know about the features that belong in this minimum set that we can start writing? 5. Substantive Discussion: Interfaces (30 min) Discussion on interfaces/APIs and how we should consider them as input for the TAPS effort. There are three broad areas of questions about the eventual interface that TAPS will provide: (a) what are the knobs? (and who gets to turn them: app developer, user, administrator, kernel developer, etc)? (b) what are the meters (and who gets to see them)? (c) what are the patterns of interaction supported by existing interfaces? Q: Does this start work on the second document or is there something we can take from (abstract and concrete) interfaces already deployed that would inform the decomposition of transport protocols/services?