Minutes for TAPS at IETF-95

Meeting Minutes Transport Services (taps) WG
Title Minutes for TAPS at IETF-95
State Active
Other versions plain text
Last updated 2016-04-11

Meeting Minutes

   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!