Re: [Taps] Draft TAPS minutes

[Ignacio Solis <[e-mail]>]

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
<[e-mail]> wrote:
> 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
>>
>> Chairs update - 10 min
>>
>> Charter bashng
>>
>> Chris, Aaron, Kyle agreed we need more precise charter language for the
>> WG's transport security function.
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> 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
>>
>> 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
>>
>> 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
>
>
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps
>



-- 
Nacho - Ignacio Solis - [e-mail]