TSVAREA @ IETF-109 (Online Only)
Friday, 20 November 2020
07:30-08:30 UTC - Friday Session II
Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing
TSV Overview and status
alto: new chair Qin Wu; rechartering
dtn: new chair Edward Birrane; finishing core docs
quic docs in ietf lc’s
taps close to finish and next up
Lars: what is alto rechartering for
Martin: 5 theme - but reach subset. lot of energy on these ideas. check out agenda
Lars: was surprised. Is there deployment?
Martin: that’s my understand, yes. especially in china there is some deployment.
Brian Trammell, Google
https://datatracker.ietf.org/wg/taps/documents/
Martin: interesting work; mostly github but don’t meet at IETF but interims
Brain: will try to make this more accessible!
(check slides and recording for all the detailed story telling)
Pete: Do we know what the uptake of the python lib or network.framework are?
Tommy: network.framework was released in 2018; in the past year we saw good update based on app dev forum; there also other third party libs with socket abstracts but not providing transport properties. Most still use web api. Other things like streaming apps are using network.framework. Some apps are only allowed this api.
pete: apple using it internally in safari and things?
tommy: yes absolutely; vast majority is using this. API is closely aligned with 2018’s taps but there are changes since then. but might update to get better cross-platform properties.
Spencer: thanks martin for putting this on! This is the right thing at the right time, e.g. regarding quic
Martin: good time with quic as we already ask people to change their APIs. So great time to say here is something to use. Chance with two wins - quic and abstraction
Brian: One reason to get this done. Thought we were done two years ago because people changing jobs/funding. But these things energized us. We want to make sure it’s a good API for quic. Initially when we started taps, quic was just about to be chartered. Also does it make sense between H3 and QUIC, or Masque on top of quic? Both need to work! Good test for the API.
Jana: Two questions: did we have evidence of other folks but Apple (who were contributing to this work) adapting the API?? Relation to QUIC: people have particular API model, e.g. HTTP; h3 is separable to H2 but similar. Concrete API but has certain features.
Brian: I’m aware of groups working on future API that have looked at TAPS and are interested. Also groups with existing API looked at taps and said it’s not for me, because the existing API has many users already and is too different. Matching of abstract API and concrete API of QUIC. Important to move to the rough shape, which we do. App needs to be less involved into the lifetime of connection. That’s a win for the interaction model. Also discussed priorities, a lot, looked into alignment with H3 but then we gave up when we looked into details.
Martin: WASM community is looking around for a platform independent API. I noticed taps but I’m a newbie, so I taps people could bring in more infos.
David Schinazi: i’m maintaining chrome-net. One of the most widely deployed network libs. Didn’t look at taps because that lib was created before taps. If we would rebuild it: taps is nice because of the consitent naming but why should I get more involved? What does it get me? We you look into the details into any open api it depends a lot on the programming language but that’s not addressed here. What’s the point about a unified concept?
Brian: similar shapes is more important, e.g. asynchronous, event driven. Post-socket tried to define threading model but left is as research project. Terminology unification goes a long way. Benefit for chro-net: mobile app would benefit from similar API shape in order to get maximum performance. Fewer arguements to make on server side. But we also have facilities in taps to get around abstraction if you know what you do.
David: Common layer on top: if you build a fork, you still end up with inefficient implementation because of the threading model mismatch
Brian: Let’s take it offline. Like to look at this.
Tommy: one other place that discussed taps was c++. they have some proposal to have new network libs. sockets with c++ wrapper on top but then more discussion about using a taps like API on top because it would be cross-platform and that would make it live longer. To David’s point: we want to avoid ossification by the apps as we want to do new stuff over the API. New API contract might not be e2e but over proxy. Using taps would make it easier to use MASQUE without breaking the app interface.
Spencer: We talked about something like quic-dispatch in the past (IETF 106 TSVAREA), and people thought it was a good idea (but IETF 107 happened). As QUIC gets closer to a significant recharter, there might be more need for that to make sure things are (not) (?) wondering off to various places like intarea and get good feedback from the QUIC community.
Magnus: Need to further consider how to do dispatching. haven’t seen super much activity but might come up again as you say when we go into maintenance mode and people start mapping. Punt to future AD :-)
Spencer: I know that you will Do The Right Thing.
Martin: See you all in not-Prague!
[07:22:56] <Bruno Rijsman> Audio is working.
[07:22:58] <Richard Scheffenegger> works
[07:23:26] <Lucas Pardue> sing some marillion magnus
[07:24:00] <Richard Scheffenegger> marillen?
[07:24:14] <Richard Scheffenegger> (austrian for aprikot ;) )
[07:24:31] <Lucas Pardue> I am already tired, a lullaby woil be dangerous
[07:25:07] <Richard Scheffenegger> virtual jetlag is worse than the real thing...
[07:26:08] <Lucas Pardue> if it starts at 12, perfect :)
[07:30:12] <Lars Eggert> ping?
[07:30:17] <Richard Scheffenegger> video is 80% audio....
[07:30:18] <Pete Resnick> pong
[07:30:19] <Szilveszter Nadas> ack
[07:30:27] <Mirja Kühlewind> i guess jabber was just empty
[07:30:54] <Lucas Pardue> Brian, sing some marillion to test your mic fully
[07:31:07] <Brian Trammell> it's not great for singing
[07:31:09] <Richard Scheffenegger> only starts showing after you join apparently
[07:31:17] <Brian Trammell> i think it's marketed for podcasters
[07:31:23] <Brian Trammell> takes me back to my college radio days though
[07:32:30] <Mirja Kühlewind> I can
[07:34:03] <Lars Eggert> could you say what alto is planning to recharter for? i had assumed they would close?
[07:34:30] <Martin Duke> there are five different ideas. i was surprised at the amount of energy
[07:34:56] <Martin Duke> some of it just maintenance stuff like extending it to HTTP/2 and 3, an operational doc, etc
[07:35:09] <Martin Duke> but also extending to cellular use cases
[07:35:18] <Martin Duke> the meeting materials from this week are mostly about this
[07:37:15] <Brian Trammell> woo PLPMTUDDT!
[07:39:54] <Tommy Pauly> Hey, it's still Thursday some places
[07:40:07] <Brian Trammell> not for long though :)
[07:40:19] <Colin Perkins> Some of you are behind the times :)
[07:40:31] <Tommy Pauly> We only have 20 minutes left of the day...
[07:42:20] <Mirja Kühlewind> we (taps) did usually meet at the in-person meetings though
[07:42:31] <Mirja Kühlewind> always nice to see each other ;-)
[07:42:42] <Martin Duke> @mirja like I said, I'm new
[07:43:23] <Tommy Pauly> It's sad that we've been all virtual interims for as long as you've been an AD, yup
[07:43:28] <Mirja Kühlewind> I think we also switched to interim because it a stage of the work where we mostly solved the hard problems and really try to wrap up
[07:45:00] <Zaheduzzaman Sarker> +1 to Mirja..... Taps interim meetings have been really effective to make progresses..
[07:53:06] <Lucas Pardue> has anyone worked on Taps with Rust's async?
[07:53:31] <Tommy Pauly> @Lucas not that I've seen, but it sounds like a good project =)
[07:54:16] <Colin Perkins> @lucas I've had a couple of students play with it - Tokio has been too unstable to make good progress until recently
[07:54:24] <Mike English> I was actually just searching for that. :)
[07:55:00] <Lucas Pardue> yeah there is still a bit of dust settling going on
[07:56:12] <Colin Perkins> student works on it one year, someone else comes along next year, finds the Tokio interface has changed, and has to rewrite... I'm hoping it's finally getting stable
[07:57:43] <Lucas Pardue> how does taps remote initiated streams? self cloning?
[07:58:02] <Lucas Pardue> support remotely*
[07:58:54] <Mihail Yanev> @Lucas I did a v4/v6 connection racing as a proof of concept using hyper which uses tokio underneath. Worked fine for that but otherwise was a bit shaky as Colin said
[07:58:57] <Tommy Pauly> @Lucas it uses a listener object you can peel out
[07:59:21] <Lucas Pardue> thanks, to both!
[07:59:24] <Mike English> How much can be shared between connections? e.g. CC?
[07:59:31] <Tommy Pauly> https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.html#name-connection-groups
[08:00:24] <Tommy Pauly> It is possible to have shared CC between connections in a group, but that would be generally implementation-specific
[08:01:26] <Mike English> Thanks!
[08:02:15] <Lucas Pardue> sorry for ruining the fun
[08:02:19] <Tommy Pauly> Brian, you didn't mention go and python!
[08:02:42] <Christian Huitema> or lisp
[08:03:08] <Mike English> or FORTH
[08:03:51] <Mike English> :satisfied:
[08:04:03] <Mike English> :skull_and_crossbones:
[08:04:40] <Jana Iyengar> Brian! You said it this time
[08:04:40] <Pete Resnick> Yay multipath!
[08:05:25] <Philipp Tiesel> you are all more than welcome to provide implementations for your favorit language
[08:05:37] <Lucas Pardue> in my experience, the transpoft apis are not actually geared around H3
[08:05:44] <Jana Iyengar> +1 Lucas
[08:05:54] <Christian Huitema> +1 Lucas
[08:06:11] <Tommy Pauly> That's something that a message oriented API helps with, though, and we're doing a lot of work to make it work well for H3
[08:06:14] <Jana Iyengar> They're not standard as well, and much of that has to do with the API model that the library has chosen.
[08:06:23] <Robin Marx> I've found the H3 and QUIC layers to be strangely separate in most implementations as well. Would have expected them to be more closely entangled.
[08:06:30] <Victor Vasiliev> I keep being confused by people's continued insistence that QUIC does not support partial reliability
[08:06:49] <Jake Holland> any motion on new taps implementations?
[08:07:02] <Jana Iyengar> There's partial reliability, and then there's partial reliabilty :-)
[08:07:10] <Jake Holland> any links? :)
[08:07:15] <Tommy Pauly> @Victor, Brian did mention that you can make partial reliability work in QUIC... but there are different ways to approach it
[08:07:29] <Mike English> Is there any inclination for taps to directly support transparent tunneling or encapsulation?
[08:07:38] <Gorry Fairhurst> The TAPS WG must have converged on all those contributions over the last 2 years, because Brian's talk looks to me a great presentation of the "common" view the group arrived at - well done Brian!
[08:07:43] <Tommy Pauly> @Mike ask at mic and clarify?
[08:07:59] <Lucas Pardue> thanks Brian
[08:09:08] <Mike English> @tommy No mic atm, just wondering where something like MASQUE might fit in here. Maybe jabber scribe can relay?
[08:10:20] <Christian Huitema> Did someone implement quic on top of the apple message passing api?
[08:11:21] <Tommy Pauly> (Well, we implemented QUIC on it at least)
[08:11:23] <Lucas Pardue> fwiw I know of folks that have tried to integrate quiche into Rust async models and hit some maturity prpblems like Colin mention. there are also folks who are using the quiche C API to integrate into other languages or frameworks e.g. Netty
[08:11:57] <Tommy Pauly> @Mike yes, I've been doing MASQUE in the TAPS stack, and support for proxying and tunneling is definitely important. It doesn't affect much of the interface, but is an implementation concern
[08:12:00] <Pete Resnick> Seeing Spencer's orange shirt cheers me for the week. Having pink lights on his headphones makes it all the better.
[08:12:18] <Magnus Westerlund too> Mike, I will relay this
[08:12:18] <Mike English> +1 Martin on timing
[08:12:55] <Spencer Dawkins> Pete - just another of the many services I provide :-)
[08:13:26] <Zaheduzzaman Sarker> Magnus seems to use the "clone" feature from taps :-)... "too"
[08:13:40] <Spencer Dawkins> Actually, TAPS was chartered a couple of years before QUIC, IIRC
[08:13:43] <Christian Huitema> Race condition at the IETF? Define race!
[08:13:51] <Eric Kinnear> It's TAPS all the way down?
[08:14:32] <Magnus Westerlund too> You can't join the jabber server with duplicate names. And Meetecho joins with your datatracker accounts name.
[08:14:35] <Lucas Pardue> turtles are positioned structurally
[08:15:28] <Spencer Dawkins> @Lucas, they're abstract turtles ;-)
[08:17:57] <Christian Huitema> Priorities in H3? Do they still have that?
[08:18:12] <Vidhi Goel> @Jana, are you in a cabin? Looks nice
[08:18:31] <Lucas Pardue> https://tools.ietf.org/html/draft-ietf-httpbis-priority-02
[08:18:55] <Mike English> I've also wondered if WASI and WebTransport can be pulled together in a TAPS direction
[08:21:50] <Eric Kinnear> Mike: Seems like yes, but so far, I've heard WebTransport say "we want all the TAPS things, but we don't want TAPS", although to be fair I don't think that much has been nailed down in WT land
[08:22:25] <Lucas Pardue> any TAPS effort on threading could be called TAPESTRY
[08:22:56] <Spencer Dawkins> I'm in q for open mike. Tommy, please go ahead!
[08:23:16] <Martin Duke> I will close the queue soon, join it now
[08:23:18] <Colin Perkins> If we get people thinking about transport APIs in a more async, abstract, and evolvable way, that’s a win for TAPS, even if the details differ. Hopefully it also gives useful input to the API shape.
[08:23:20] <Eric Kinnear> Nice Lucas
[08:25:13] <Philipp Tiesel> @lucas we actually tried to call this "events" and tried to make sure it works with threads/callbacks/co-routines/workqueue-blocks/… whereby you implement "events" with whatever works best in your language
[08:25:15] <Jana Iyengar> @Lucas: Cute.
[08:26:20] <Jana Iyengar> @Colin: I think that's already happened. I don't think anyone who's building a high throughput API thinks f amything that isn't async
[08:27:14] <Jana Iyengar> @Tommy: That is a nice outcome!
[08:27:33] <Colin Perkins> @jana async is only part of it, but yeah
[08:27:44] <Lucas Pardue> Philip yeah, threads/events/etc is more generalised to a processing model
[08:28:55] <Mike English> +1 Tommy - this is exactly what I was wondering about
[08:30:09] <Zaheduzzaman Sarker> thanks to Brian and Martin for taking on TAPS here, from TAPS chairs