Subject: [Taps] Draft TAPS minutes

From: "Aaron Falk" <[email-masked]>
Date: Thu, 21 Dec 2017 13:10:00 -0500

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

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Dec 2017 17:18:28 +0000

IIRC the person marked as ? in the draft-tiesel-taps-socketintents-01 slot
was Nacho Solis.

Best,
Chris

On Thu, Dec 21, 2017 at 10:10 AM Aaron Falk <[email-masked]> wrote:

> 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
>    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
>       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
>       - 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
>             - Aaron: moving into the territory of a charter revision,
>             which we're not going to talk about right now. mic closed.
>          4.
>
>    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
>       - Main questions: is this easy enough and useful enough to devs?
>       - Michael Wetzl:
>       - could be missing out some things that might not be obvious from
>       - ?:
>          - How to app dev really know how to understand things like the
>          - 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
>          - 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
>          - 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?
>       5.
>
>    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
>       - 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
>          - 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
>          - 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
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: Ignacio Solis <[email-masked]>
Date: Wed, 27 Dec 2017 20:59:11 -0800

I'm amazed somebody (other than the chairs) actually goes through and
reads the minutes.

I do remember saying something, but I'm hoping it was more eloquent at
the time.  (external observers might have classified it as "rat
holing").   I may be a couple of the "?"s.

I believe I was trying to say that not all applications will know what
is their "intent" with respect to the network.  Also, each intent type
will have to be carefully constructed to be useful and not to create
confusion (think of bursty at different time scales).   Also (do we
want to get into this?) how will meta/super protocols behave? (think
of QUIC).

Like I mentioned at some point, I would rather focus on trade-offs
(ordering?) so the system can make choices for me.

And finally, we should consider giving some guidance of when you
should just "use another `socket`" (probably analogous to "use another
thread").

Nacho

On Wed, Dec 27, 2017 at 9:18 AM, Christopher Wood
<[email-masked]> wrote:
>> ________________________________
>>
>> TAPS
>> IETF-100 Singapore
>> Charter bashng
>> Chris, Aaron, Kyle agreed we need more precise charter language for the
>> WG's transport security function.
>>
>> 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.
>>
>> 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
>> 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.
>>
>> 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
>> 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
>> 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
>> This way is application chauvanist (and I'm [Brian] also application
>> 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
>> Philip:
>> Open question: is this the way the IETF describes Abstract APIs?
>>
>> 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
>>
>> 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
>> 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
>> 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
>>
>> 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
>> 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
>>

-- 
Nacho - Ignacio Solis - [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Thu, 28 Dec 2017 12:30:52 +0100

Hi,

Two fixes inline:

> On Dec 21, 2017, at 7:10 PM, Aaron Falk <[email-masked]> wrote:
> 
> 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
> Chris, Aaron, Kyle agreed we need more precise charter language for the WG's transport security function.
s/Wizel/Welzl  pretty please  :-)

> 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
> 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
> 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
> 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.
> 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:
> 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.
> 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
s/Wetzl/Welzl  pretty please  :-)
and: my statement here, in this context, sounds as if I said that the socketintents draft "could be missing out some things …”. I believe I said the opposite: that this could be useful because it shows us things that we might otherwise miss. Suggested re-phrasing:
***
this could show us some things that we might be missing out, as they might not be obvious from looking at current protocols
***

That’s it from my side. Thanks, cheers
Michael

---

From: "tom p." <[email-masked]>
Date: Thu, 28 Dec 2017 12:03:30 -0000

----- Original Message -----
From: "Ignacio Solis" <[email-masked]>
Sent: Thursday, December 28, 2017 4:59 AM

> I'm amazed somebody (other than the chairs) actually goes through and

As one of those who has not got the time or the money or the ... to be
there in person, yes, I do read the minutes.  In fact, there are 20 WG
in which I might have an interest; of these, to date, seven have posted
minutes, or references thereto, on the WG list, so TAPS is doing rather
well; and yes, TAPS are good minutes, not a link to or transcription
of, Etherpad.

<rant>
And WG that do not produce minutes tend to be those that ignore other
aspects of the ways of working of the IETF, such as discussing
issues on the WG list, of moving forward based on WG consensus on
the list, of allowing time for comment, of acting on comments accepting
or rejecting but not ignoring or losing them, ....

More subjectively, I think that the WG that do not respect the IETF's
way of working tend to produce flawed work, that turns out to have
defects sooner rather than later!

</rant>

Tom Petch

> >> 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.
more