Re: [Taps] Draft TAPS minutes

[Christopher Wood <[e-mail]>]

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 <[e-mail]> 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
> 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.
>          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
>       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?
>       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
>       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
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps
>