Re: [Taps] Draft TAPS minutes

["tom p." <[e-mail]>]

----- Original Message -----
From: "Ignacio Solis" <[e-mail]>
Sent: Thursday, December 28, 2017 4:59 AM

> I'm amazed somebody (other than the chairs) actually goes through and
> reads the minutes.

As one of those who has not got the time or the money or the ... to be
there in person, yes, I do read the minutes.  In fact, there are 20 WG
in which I might have an interest; of these, to date, seven have posted
minutes, or references thereto, on the WG list, so TAPS is doing rather
well; and yes, TAPS are good minutes, not a link to or transcription
of, Etherpad.

<rant>
And WG that do not produce minutes tend to be those that ignore other
aspects of the ways of working of the IETF, such as discussing
issues on the WG list, of moving forward based on WG consensus on
the list, of allowing time for comment, of acting on comments accepting
or rejecting but not ignoring or losing them, ....

More subjectively, I think that the WG that do not respect the IETF's
way of working tend to produce flawed work, that turns out to have
defects sooner rather than later!

</rant>

Tom Petch

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