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