Note takers: David C Lawrence and Michael Welzl – Note well covered.  Introduced new co-chair. – draft-taps-transports-10 – Mirja relayed from Spencer with AD hat on that the decision of whether the doc is final is up to the WG but it's probably ready for publication. – Ready for AD review. – draft-fairhurst-taps-transports-usage-udp - Gorry Fairhost – Other protocols from the main document need to be analyzed for more transports-usage docs.  Any volunteers? – Toerless: for multicast part would like to see progress on the API – Are there any implementation project?  We know of one, but any more? – Brian Trammel: we have the beginnings of a thought of an implementation called post-sockets.  Not really ready to announce anything, but possibly will bring to taps in Berlin. – draft-taps-transport-usage --Naeem Khademi – Terminology compliant with taps-transports. – Plan to include more SCTP RFCs. – Also plan to inc MPTCP, UDP, UDP-Lite, DCCP and (D)TLS. – Already have potential contributors for all above – taps-transports-10 mentions (D)TLS do provide security function but the API is from elsewhere. – document rules (Apdx B of transports-usage-00) prohibit including IETF-external stuff, – Naeem asks  what to do with (D)TLS – Michael Tuexen: are you asking: can we just run OpenSSL over a TAPS system? From an app perspective or API perspective? – Naeem: For the purpose of the document, we need to specify an API. This API comes from outside IETF documents, so what do we do now? – Christian Huitema: we have implementations in Microsoft that do not use the OpenSSL API. I am skeptical of the idea of standardizing more than the abstract API in the IETF. Concrete APIs have stuff like key management, certificate management etc., depending on system specific management functions. – Rich Salz: at most you want to put it in an informative appendix, security considerations is the place to go. Having the binding would be interesting but not a part of the official document. – Brian Trammel: +1 to Rich and Christian. Probably we need to define the minimal abstract API for DTLS in this document, in terms of the services that we need. Here's a thing, please encrypt it, etc. From the transport standpoint the bits that you need are not that big. I think that's the right thing to do. – Aaron: uuuuuh, you mean we do that instead of tls wg? – Brian: No we should just describe what is that we need. – Christian Huitema: Two examples of things that are done in security APIs that are hard to put abstract. One example: management of certificate authorities. Another example: how do you ensure that encryption keys you are using are protected in hardware or just software? Extremely hard to specify in an abstract way without looking at what system you're working with. Want to do it the same with phone or other device. Martin Thompson (?) published a draft 2 months ago describing how to run QUIC over DTLS. Solution is based on layering, UDP and DTLS layered on top of it, and QUIC on top of DTLS. I do not know whether Martin's proposal is what we will accept but it's legitimate to look at this layering approach. – Aaron: Christian, one option is to just punt on DTLS.  Do you recommend that? – Christian: At this point maybe yes. – Mirja Kuehlewind: Different protocol that's called TCPINC, extended API in this group is maybe also something to look at. – Gorry Fairhurst: What do we do? I suggest we carry on with this draft and refine it, my approach for UDP was to write a separate draft to get people to read it. That may be an even better approach for DTLS - not to publish a separate RFC but a draft, to get people to read it. Find people who can write this and get them to do it, then get security people to look at it, then integrate it. Should be done fast because else progress can be very slow. – Naeem: sounds reasonable to me. Who? (No concrete volunteers came forward.) – Aaron: People who were at the mic might be collaborators. – Naeem: Ok. – Aaron: Someone needs to start. You? – Naeem: Can take it to the mailing list. – Rich Salz: probably worth asking in tls wg for a 5 minute slice to explain what's wanted. – Aaron: one suggestion was QUIC; what was the other? – Christian Huitema: WebRTC is another example. – Aaron: maybe we can find someone involved in one of these other cases and get them to contribute. – Mirja: maybe UTA is the better group to go to for this. – Aaron: if Naeem can push forward with this document we can try to find collaborators. – transports-usage-udp next steps. Gorry Fairhurst, – Describes how UDP and UDP-Lite exposes services to an app – send and recv are the basic core but a lot of other networking issues are exposed directly to the app like checksum issues and path MTU – Changes in -01 added require_checksum option – Is this draft the right sort of document that is needed by the taps wg? – Toerless: Fairly useless on API side, because the reference material is useless. The fact that the APIs suck is something we knew from the beginning. They're only religious references from where we can get the services. If you gave it to someone who is unfamiliar with it, could they implement? Probably not. – Gorry: multicast is messed up, we need to see what to do about it. Dont know about socket API aspects. What to do - is UDP really not specified? Do we have a specification problem? – Michael Tuexen: access to ICMP messages seems to be missing. – Gorry: it's called error report, following Michael Welzl's taxonomy from the other document – Christian: missing notion of reusing ports.  Not only multicast issue, but definitely mandatory for it. Another question, did someone do an analysis of how APIs that are exposed in practice match the documents? – Gorry: Tom Jones, co-author – Christian: there are different dimensions there. Sandboxed API or not? What programming language? C++ and Java or C# are not quite the same. Might be interesting to do this kind of comparison. When doing an abstraction of APIs it's good to look at what abstractions already are there. Classic feature of more abstract languages is using names instead of addresses. – Christian: in practice, you end up making a shim API because of the vertical slice that you mention. – Gorry: I can say yes, don't know how to progress. – Tommy Pauly, Apple: We have one of these higher level APIs. If you are doing a more connected use that can simplify things. Also one thing I was wondering about: getInterfaceMTU(), isn't that too restrictive? We expose maximum datagram size. – Gorry: I tried to take these names from various RFCs. Max datagram size is closer to what DCCP did. – Tommy Pauly: more generic – Gorry: yes. probably be more useful. – Toerless: connected model works. There are parameters missing, especially around the port, you try to get a port that is free or a port that you want to use. IETF has in the meantime come up with ephemeral port ranges. It should be able to say if you want a port with a semantic in it. – Gorry: we could try and express something about this. – Toreless: extended socket API options in v6 have some issues. We must have the not connected model. – Gorry: I get that. – Michael Welzl: maybe this is for the second document? Would be more efficient way of handling this maybe. – Gorry: we don't want to miss it, either way we do it. This draft should probably have an appendix covering the things that were said. – Gorry: Should we park on multicast? – Aaron: concern about complexity about including multicast, given the challenge that we have just for unicast. I would be ok with just making an observation that these things exist, I don't think it's really where the energy for the group lies. – Brian Trammell: Insight here is that much of the complexity here comes from multicast. Maybe we should fix the APIs for multicast. We don't want to go to the rathole, this document sounding to the rathole. The doc can say don't step in the rathole. – Aaron: sounds like a good charter for a new group. – Gorry: yes and no. It may not be as messy as it looks. People probably have implementations already that do these things. Is anyone interested in reviewing the multicast API? – Toerless: IPv4 one exists; one that doesn't do ... simplifications by just leaving out some parameters from the API ... one API for multicast join, that looks simple enough. Better than all the 10 options in SSM API. – Aaron: Toerless, you're the only one who's stood up to say it should be done.  Will you do work on it? – Toreless: Within the scope of what TAPS says, Gorry did a great job. I can help to simplify that stuff. Would be interested to see what other things could be done. Datagram protocols have multicast APIs, could be good to look at. – Aaron: the exclusion of multicast is just a practical consideration. Phase 2 in the charter looks at protocols in phase 1, says this is the useful subset that we want to use. We can charter later and add to it. – Toerless: interesting because they are newer than UDP, they provide useful reference. – Aaron: can you give examples? take it offline... – Gorry: so I need to know what I'm doing next. – Aaron: I like the idea of a separate draft, keep on working on it, sounds like someone wants to help on multicast; are you done for the scope you covered? – Gorry: I think so, there are some open issues about binding sockets and how to use these sockets. I need help. We need help or merge it with Michael's draft as soon as we hear back from some people to see whether we miss something. – Aaron: someone who can help with the sockets question?  (no) – Gorry: we could take the inputs we got from DISPATCH, general review, then merge it. – Aaron: any objections? (Silence.) But it hasn't had a lot of review. – Gorry: we'll keep this open and revise it, before next meeting we'll offer to merge the text. – draft-gjessing-taps-minset-01, Stein Gjessing Describes taps arch for how the app interfaces to taps software   which interfaces to IETF trans protos.  A minimal abstract API for the   app, with stuff that can happen between the taps and proto   layers not exposed to the app, including some that can be automated.   Some subsets of features might be combinable. Automated: 16, Added: 3, Deleted: 8 – Gorry: when we incorporate UDP, we'll have facilities to set the DF bit in the IP header. Is this ok? Do we know how to expose this? Just the datagram side needs it, the other doesn't? – Stein: depends on how complex we want the abstract interface to become. – Gorry: we do need a simple abstract API, but we need to figure out how to do these things. – Stein: maybe it can be automatized? – Gorry: then it's not UDP. Maybe there's interest in other WGs, where they might know about it. – Aaron: not enough meat in there, pretty abstract; keep going eventually I will have an opinion. – Notetaker's note: so what is the taps software layer doing for "automatable" if not being able to deal with things like this? – Tommy Pauly: to that point of Gorry: maybe one response to that is to say: it should be some part of the top level abstraction. This isn't optimizing, but almost optional functional. You could get UDP working without this function, it has an ok default behavior, but you may really need this. Maybe we'll find new categories. – Stein: I agree, you could have a minimal subset but then also an extra subset that you don't have to use. – Aaron: your view on how to minimize is different from what I thought it is. I thought minimal protocols, your view is minimal features. You'll be able to delete fewer and fewer things. There's only so much that you can automate. I think the reason to talk about the minimal set where we can build prototype – Stein: you can't make a first minimal set, and then a later another minimal set? – Aaron: you're trying hard to throw out stuff that you don't want to show to the top layer. I think the point of this phase 2 is to be short and simple, a decision making step to just pick a set of protocols. – Stein: the result if you do that minimal set is that you could have a taps API that couldn't be used because it uses so few of the protocols – Aaron: I don't think TAPS needs to be the universal abstract API for the transport layer. But folks may disagree. Mirja: Not sure it can agree or disagree. In step 3 we definitely should have a smaller set that we want to implement and provide. In this step, we have to make the decision what to support. Should be possible to extend API easily without redoing it completely. Aaron: Could become an enormous project. – Mirja: I agree. – Tale: I agree with Aaron, the value here is providing a simple API for apps, so not trying to incorporate all of the features of transports whether exposed or not. – Stein: we are going to make new draft. – Gorry: I do agree that we need only a set of things to work on, and a simple abstract API. I disagree that it prevents you doing things. The simple set lets you do things very simply but there's a danger that it then becomes a bit trivial. For a real application you want to influence things with a set of protocols. – Stein: complete set is quite big but you only have to use a small part of it in order to get some real benefit. – Gorry: yes, your program can be quite simple but extensible if you want – Tommy Pauly: we should distinguish between a small and simple API and a small set of features. Depending on how you design your higher level abstraction there are things that may become easier to do or just get wrapped up into higher level abstractions. Example, read and write. Asynchronous model gives you more feedback in the basic subset. Gets wrapped up into your basic read and write call. We shouldn't necessarily say these features should be kicked out because they create complexity. – Aaron: I think we lost focus. I thought the value is to be able to apply happy eyeball approach for protocols. To do that you must be able to trade off feature combinations to find what works. To me, the goal of the TAPS API should be to expose a set of services that can be composed using existing protocols underneath. Magic of TAPS is the probing to get these features. We shouldn't be trying to solve the problem of API developers. – Mirja: I agree. I think it's in the box called automated. I'd like to talk more about the functionality. – Aaron: what the application can ask that you can automate? – Michael Welzl: not sure I get the problem here. How many people have read the draft?  (approx. 8 hands raised)   So how is the draft different from what Aaron suggests? We need to identify the functional bits so we can decide between different protocols. – Mirja Kuehlewind: I would like to see the fallbacks, how to fallback from SCTP to TCP. And maybe we don't need to have all the stuff that's in automatable, first shorten the list? – Michael Welzl: ok – NEAT project, Michael Tuexen – Disclaimer: API can change, and has not been substantially tested – Aaron: what are the next development steps? – Michael Tuexen: UDP, UDP-Lite integration; TLS and DTLS will be part of it, inside the NEAT library. Integration of userland stack. Then more abstract, defining requirements of protocol choice. – ?? , PARC: how much do you think this design has to do with what TAPS is doing, versus switching from socket driven I/O to asynchronous I/O? The choice that you made means a program would have to choose this. – Michael Tuexen: the plan is that you can use the NEAT library with an event loop. You can integrate libuv stuff in other event loops. – ??, PARC: work that we're doing at TAPS with integration vs us doing sockets over an asynchronous event loop. Part of it is ... the fact that we're using an event loop here vs. blocking / unblocking calls. – Michael T: we did it this way because we think that's most appropriate for people that use this library. Not saying TAPS should make a statement vs blocking / nonblocking. We try to follow what TAPS provides, for choosing protocols you want to use. We thought this is the most appropriate way for potential usage of the library. – Toerless: async or sync is a choice of a concrete API, whereas TAPS makes an abstract API. Easier to put a sync API on top an async one than the other way round – ??, PARC: we have an implementation that does exactly the same thing, using our own transport – Aaron: did you say you're implementing TAPS? – ??, PARC: we do but we do not use IP. – Aaron: what? – ??, PARC: ICNRG research group, layer 3 protocol, modules on top where you can select the features that transport layer provides, we have the exact same problem. Security built in, messaging, .. same exact problem of having to figure out how to communicate. We approve!