Minutes IETF100: taps
minutes-100-taps-00

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 Welzl, 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
                        Welzl: 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 Welzl:
                * this could show us some things that we might be missing out,
                as they might not be obvious from looking at current protocols
        * Nacho Solis:
                * 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). * 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