[Taps] Draft TAPS minutes

["Aaron Falk" <[e-mail]>]

We’re overdue for filing the minutes from our Singapore meeting.  
Please give the (very good) notes by Kyle & Tale a look and send 
comments.

—aaron

  - - - - -

TAPS
IETF-100 Singapore
Tuesday, November 14, 2017
Room: Olivia

Minute takers:
Kyle Rose
tale

1. Chairs update - 10 min
	* Charter bashng
		* Chris, Aaron, Kyle agreed we need more precise charter language for 
the WG's transport security function.

2. draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo -15 min
	* Brian Trammell
		* Is this an API certification? <laugh>
		* There's an implicit assumption of ordering in protocols based on 
number of features
		* From standpoint of feature set that you need to meet, that's the 
right way to think about it
		* Thinks doc is close to done
	* Tommy Pauly
		* Need to explicitly declare required features for a transport 
up-front
		* Remove all references to "fallback" because it implies a particular 
set of preferences/priorities that imply a total order
		* Instead, just catalog protocols by features provided and leave 
ordering to another doc
	* Spencer Dawkins (responsible AD)
		* Agrees with Tommy
	* Completeness
		* Aaron: What is required for document to be complete?
		* Michael: Tommy to proofread
		* Gabriel: Is CoAP supported?
		* Michael: Minset analysis based on a survey of important existing 
transport protocols
		* Aaron: Goal of minset is to identify minimum set of functions that a 
TAPS API should support to cover the basic set of functionality required 
by IETF protocols. If there's something missing from CoAP, maybe there's 
stuff in minset that shouldn't be there; alternatively, it may be that 
CoAP is not expressive enough to be usable through the TAPS API
		* Bob Moskovitz: Purpose of TAPS should be to disconnect the 
application from the details of the transport, whether or not a 
constrained transport <---this probably needs clarification
		* Tommy: (missed)
		* Mirja: How to map this to post-sockets? Anything that isn't related 
to connection establishment or data transfer should be separated out
		* Michael: "Maintenance" covers the configuration aspects of protocols
		* Tommy: Pieces of functionality that are core transport 
functionality, and then protocol-specific (or model-specific) things 
that need to be separated out
		* Michael: Need to distinguish between what needs to be said up-front, 
but I don't like the idea of separating out core functionality from 
non-core
		* Mirja: There is a box called "configuration" in post-sockets. We 
need to know what goes in there.
		* Brian: There are things you need to do during connection setup that 
can't be changed without tearing down connection state: not maintenance. 
Is this an API specification? It's a specification for APIs that 
implement TAPS. Would be useful if the knobs available here were 
organized in a better way. May just need to add another layer to express 
additional configuration.

3. draft-trammell-taps-post-sockets-03, Brian Trammell, ETH Zurich - 20 
min
	* Brian Trammel
		* Hard requirement that the protocol stack configuration work without 
a requirement that a bunch of config be provided.
		* "Configuration" box is what you use to constrain the magic protocol 
configuration state maintained for a path in the association.
		* Obviate the need for dicking around with sockopts because the 
defaults are saner.
	* Tommy Pauly
		* *IF* you use TCP, set this option; *IF* you choose SCTP, do this. 
Extra knobs if you need something very specific.
		* Noted another change in the draft is around messages; we like the 
message abstraction but need to understand how that relates to streams 
and chunking
	* Praveen from Microsoft
		* How do you reconcile system configuration with app configuration(? 
not sure I got that right)
		* Brian: the jokey answers is that it sort of looks like cascading 
style sheets, using predictable overrides to get a final instance 
configuration.  hope to do better than CSS
	* Kyle Rose
		* Re predictability and "too much magic" making things hard to figure 
out with regard to performance targets etc
			* Brian: Yes really, let's talk about this offline because it'll be 
like a half hour discussion
		* Accessability of specific aspects of different transport protocol 
features (maybe non-obvious requirements, like degrading perf on purpose 
for testing purposes)
			* Brian: the intention is to make it all available through the API if 
you know which one you're working with
	* Brian
		* Open issues:
			* a protocol-independent carrier state machine
			* how to represent certain transport-specific interactions
		* Bring this into the wg now?
			* critical mass of Abstract interface proposals now
			* ready to take the creative leap to design the API
			* Aaron:  actually this does sound like a charter change for 
architecture
			* name?: In a way this is looking at "maxset" rather than "minset"
			* Michael Wetzl: the reason the charter is so conservative was 
because people couldn't really agree so had to be pared down.  Agree 
that it is good to have a higher layer, but concerned about the 
implementability
			* Aaron: moving into the territory of a charter revision, which we're 
not going to talk about right now.  mic closed.

5. draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU Berlin - 20 
min
	* Automated Transport Option Selection (see slides)
	* Desire to use same set of (essential) keywords no matter what 
programming language is being used
	* Main questions: is this easy enough and useful enough to devs?  
sufficient to express the usual set of intents?  what's missing?
	* Michael Wetzl:
		* could be missing out some things that might not be obvious from 
looking at current protocols
	* ?:
		* How to app dev really know how to understand things like the 
implications of burstiness?  or what bitrates it is using?
		* Philip: An app should have a fairly intuitive understanding of 
whether it is constant or bursty, even if it doesn't know the specifics 
of volume
	* Praveen:
		* Think it really needs some way of indicating the pattern of traffic 
(eg, send/receive messages)
		* Philip: +1
	* Tommy:
		* Very difficult area to get right; we're going to need to expose the 
protocol knobs
		* Definitely want to see this discussion happening in the WG even if 
this particular set of options is torn down.  Expect it to be a tricky, 
difficult discussion
	* Aaron Falk:
		* Have you implemented it?
		* Philip: limited implementation on top of BSD Sockets
		* This does go back to the ATM classification discussions and previous 
attempts to categorize what is expected of the network
		* This table is an "attractive nuisance" for criticism and a good 
starting point
		* Philip: agreed, it is just a starting point and not being proposed 
as the end point
	* ?
		* The table worries me because it seems far to easy to rathole on each 
element of it
		* Aaron: are there semantics from the ABT world that would be useful?
	* ?
		* An issue in the table that "intents" are about things the app is 
signalling what it intends to do, but other things there are not really 
intents but something the app desires
		* It isn't useful for apps to just only be able to say "give me all 
the best performance always" but rather to have to indicate what the 
trade-offs are
	* Mirja Kuhlewind:
		* Agree with ?previous speaker.  Not really sure what does make sense 
to specify here.
	* Brian:
		* "Can you go back to the ATM table [slide] again?"
		* Two main issues with this; the further right you get the happier I 
am and to the left the sadder.  It's sort of like a heat map of how I 
like the table.
		* Table helped clarify for me the separations that are needed
		* Two distincts groups of people in this room, apps chauvanists and 
transport chauvinists, and these are in tension for designing the 
architecture.  really need to find the balance.
		* This way is application chauvanist (and I'm [Brian] also application 
chauvanist) but we need to call that out
	* David Schinazi
		* Another type of chauvanist, an engineering chauvanist, which I am
		* Definitely value in some sort of registry for different types of 
intents and showing how they could be used
		* Premature to have a laundry list of all the things we might possibly 
want without an understanding of how we really want to use them (like 
burstiness)
	* Gorry Fairhurst:
		* I like the list; I think the list should be bigger, but the datatype 
values should mostly be binary (enums)
	* Philip:
		* Open question: is this the way the IETF describes Abstract APIs?

4. draft-pauly-taps-guidelines-01 - Tommy Pauly, Apple -25 min
	* See slides, on the topic of racing connections
	* Tommy ... didn't even get off the title slide before Colin was @ the 
mic
	* Colin
		* Scoping question: when you say racing do you mean Happy Eyeballs or 
things like ICE as well?
		* Tommy: mostly from Happy Eyeballs perspective
	* Aaron:
		* Is split VPN definining separate peths?
		* Tommy: conceptually yes
	* Colin
		* Trying to still figure out the difference between a path and 
endpoints
		* ICE is about determing what works
		* Tommy: which yes is also what this about, and we do need more work 
w/ICE
	* Brian
		* (on Avoiding Ossification slide) these things seem to be mutually 
exclusive but maybe not intrinstically so but rather in your approach.  
not sure how to fix it though.
		* Tommy:  in the context of the current app dev cycle, taps is way 
better than BSD sockets api used to be, way easier to just turn on a bit 
than change the whole model
		* Re what should be raced or not raced, advantages to doing it tree 
oriented rather than sequence oriented
	* Colin
		* On the ossification point, in the past we were trying to be general 
(SOCK_STREAM) but never really was, whereas we do avoid some of that 
with taps by already starting with more than one underlying choice
	* Wolfgang Beck
		* It is interesting that most (all?) IETF docs that talk about what 
protocol an app should use never talk about general charateristics like 
stream/dgram but rather specifically call out TCP or UDP
	* Colin
		* Quick followup on the ICE point, you may have to hook this racing 
into the application state
	* Spencer
		* Interested in the comments about modern dev cycles vs historic, and 
would like this explored more before last call
		* Tommy: the tail of people who are not pushing new updates to their 
code are probably not going to adopting anything beyond BSD sockets 
anyway

6. draft-fairhurst-taps-neat-00, Gorry Fairhurst, University of Aberdeen 
-20 min
	* See slides
	* Zahed: Who is setting up the policy?
	* Gorry: Internal interface in neat, from the policy manager
	* Personally pefer binary keywords for desired characteristics, like 
"low latency", over specific metrics
	* Slight concerns about making things overly complicated into the neat 
api
	* Strongly believe taps API has to be callback based to support the 
expected mechanisms of the current app dev world
	* Aaron
		* Can you say anything about the example apps?
		* Gorry:  well we can send bytes backwards and forwards, so that's 
good right?  And Mozilla has something working with it
	* Mirja
		* The base architecture should be a message not a stream
		* Gorry: totally agree with you
		* Still some fuzziness around transport/session layer
	* Kyle
		* Minor quibble on making it event driven, because sometimes you don't 
really want to use that style (maybe using imperative/blocking, maybe 
using CPS)
		* What you want is the API to express various programming models, 
maybe with the event-based model as the foundation for others if it's 
sufficiently expressive to capture all widely-used models
		* Gorry: system is based on libuv, and yes maybe we could do other 
models on top of that as the substrate
	* Tommy
		* We definitely don't want blocking to be the main API but there are 
multiple models for asynchronousity
		* Abstract API should absolutely not have anything specific about how 
to implement it, just the features needed
	* Wolfgang Beck
		* ? ... sorry missed that first comment (so did I)
		* Issues about limiting th queue size is not that useful without 
understanding other issues w.r.t rate / etc.  What we really want is 
more like the Van Jacobsen model with something like packet soldiers(?)
		* Gorry: you're a realtime person, aren't you?
		* Yes so coming from that perspective
	* Zahed
		* Gorry: See happy eyeballs as "how do you decide on a final 
transport?" But then you have the problem of choosing the candidates, 
and that's the bit where the policy engine(?) fits in.
	* Gorry
		* Deciding on an architecture will help a lot with nailing down 
terminology

7. Discussion on charter item 3 - 10 min
	* Aaron
		* Look at the history of the group, and how the possibility of 
rechartering was considered early on based on initial results
		* Aaron's feelig the love
		* Let the record show: Aaron is happy.
		* My gut tells me that there is a useful common architecture can be 
extracted from this.  What does the group think?
	* Brian Trammel
		* We basically do have some architectures, so can be chosing to 
continue that as wg business.  Like postsockets is an architecture
		* Aaron: I would be pleased to hear whether the people who work on 
other projects (neat) would be good with working with that
	* Mirja
		* The different projects have different levels of abstraction, so we 
should be deciding on what level of abstraction to use
		* Should pursue as unified, not two separate abstraction layers
	* Michael
		* Essential agreement with Mirja
		* Aaron: implementation experience is extremely valuable for 
validating these ideas
	* Gorry
		* Not incompatible; just different levels
	* Anna
		* Neat is not abstract enough but postsockets probably too abstract, 
would be good to find something in the middle
	* Tommy
		* We have enough experience in the room with various implementations. 
Agree this is at a very abstract level. There's a neat implementation 
doc saying "this is how we decided to implement it". I could produce one 
of those also for how we (Apple) implemented it.
		* What I want to see out of postsockets is something that is forward 
looking enough to still be relevant in 10 years but still implementable 
now
	* --over time--
	* Mirja
	* Phillip
		* Good to see that postsockets/neat is moving toward a common language 
and want to keep them separate for now to see how they might naturally 
come together over time
	* Tommy
		* One thing that could help speed up that coming together is a 
terminoogy document to solidify that common language (eg, to define what 
a path is, etc)
	* Aaron thinks the bar is low for defining terminology.  Aaron is 
apparently new to the IETF

--fin