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