Transport Services BoF (TAPS)
89th IETF Meeting, March 2014, London, England.
Wednesday, March 5, 13:00-15:00, room Viscount.
http://www.ietf.org/audio/ietf89/ietf89-viscount-20140305-1300-pm1.mp3

129 attendees (based on blue sheets).



Chairs (Murray S. Kucherawy and Michael Welzl): Introduction
Played an audio rendition of "taps" and presented the Note Well.



Jon Crowcroft: Socket Science?
(draft-moncaster-tsvwg-transport-services-01)


Jana Iyengar - What is the deployment story for some of the things you talked about?

Jon - In Cambridge they have deployed code into serious working environments, in different OS. If you want to put something in the internet infrastructure in the carrier world it is difficult. We're not in that world, we're in the world where e.g. the MPTCP group deployed something and Apple shipped it. In this Bof we need to now what things have to be put on the table, to see what we need. We are nowhere near a deployment story.

Jana - I don't expect that we don't have answers right now, but it is an important question we should consider.

Kevin Fall - In 2007 we did some work where we referenced you by name, in the Haggle work; in the API part, a lot of this was bottom up generated. Looking at HPC, Haggle, other asynchronous things etc. publish/subscribe model was of interest. Natural for content distribution, and not as natural but possible for RPC-like synchronous interaction. Transport selection and other protocol selection was an orthogonal API from the application, so that if you wanted an operator to say "no, all these apps are going to use this other protocol stack", you could do that. Now the application was forced to do it as well. It was a research prototype thing but showed some related issues.

Jon - That's certainly our model for choosing the cryptos. You could do other things, e.g. transport selection that you mentioned. Certainly the more asynchronous API is the way to go. Seems inevitable in multi-core.

Kevin - It was an asynchronous API. One other question is, if the data is not at the source, and not at the receiver, then what is it, what is the sender, what is the receiver, how do you account for it. Is there another entity involved?

Ran Atkinson - I'd like to make a plea on the API front. The reason why the C language sockets API has a sockaddr is that we didn't have DNS back in the 1980s when it got shipped and deployed. Now we do have a DNS, and experience is that various things get easier for applications, multihoming, multipath, if we can use things other than IP addresses to name endpoints. Let's not force the application to get into the guts of the OS, let's at least support as one option name-based endpoints.

Jon - Yes, we need better identifiers (host names, etc.). We had this discussion previously. Great point. Van Jacobson shipped a whole bunch of tools around 1988-90 which only took DNS names. Turned out early on that resolve was blocking and time out sometimes, but that's not a reason to not use names, it's just a stupid resolve interface. With a notification interface you would get that, it would just do the right thing.

Pete Resnick - What Kevin and Ran said rang very true. A in API stands for something. It always makes me nervous when transport people start making APIs, because we have to live with them in the nosebleed session. I wish you would think about this in terms of a layer. Maybe a session layer, or a whatever layer. At some point you'll have to prototype this stuff, build the API, that's great, but in some sense leave it to OSes that interface with applications to do the work to build the API and actually produce the layer that you want with all the information that you want and whatever APIs are needed, whether it is sockets, which would be a bad outcome as far as I'm concerned, or something else, leave that not in whatever you're producing.

Michael Welzl - Next presentation is from an applications person, will talk about how that fits with APIs. We've been trying to address this concern since Vancouver, and there's also a draft about how this work relates to APIs.

Dave Thaler - Agree with everything Ran said. If you look at the APIs you need to use to get an application into the Windows App store, then sockaddr isn't anywhere in there. You can't use sockaddr, it's name based, so I agree with all of that, including Pete's points as well. Side discussion at workshop last week, on the relationship of user experience and applications, and APIs at this layer and maybe below. Interesting question there that doesn't have a simple answer. Goes back to Jon's point about providing a way for applications to know what transports they are using - one of the topics was the notion of opportunistic encryption. i.e. encryption without authentication. So the question is, do you want to tell the layer above that you are doing encryption, but without authentication? There's no simple answer to that, there are arguments both ways. I want to relay that because there may be analogies to other things here. Reason for doing it: if you know that a layer below you is doing encryption, you can reduce redundant encryption. Giving better information means you can get a better solution. That's one side of the argument. The other is, apps and OSs have UIs that say "btw, your certificate has errors, would you like to continue?" and people say "ok" because they want to get work done. This user experience is a really bad way to do it, so we had a discussion about a better way to do it. So the disadvantage of providing the information up there, you leave it up to applications to decide their own way of doing this.

Jon - In a way that last thing is a bit like implementing late binding for the end-to-end arguments in systems design.  "Great, someone has done crypto down there, I don't have to do it", or vice versa. You could do that for various other functions like ordering etc. We're not anti end-to-end here one bit, we're just saying you need to be a bit mature about it.

Bob Briscoe - About naming issues. Really cool stack composition implementation 1998 by Richard Hayton called FlexiNet, in Java. Not just naming the other end but use the name for the composition, and the name object said how you could put together the composition. That might be an idea that you could use here, where the name actually comprises all your requirements. All ends need to know the same thing about the stack. The other point about that that comes to what Pete Resnick said is that it was more about application layer stack elements like persistence and things like that, less about the lower layers, it came from the application programmer's perspective.

Dave Crocker - Lower layer guys do really bad APIs until the apps guys do them. (laughter) Presenting a need for a more powerful API. True. There is another side: APIs are for programmers, who are human, so we have a human factors issue here. The more knobs and switches there are, the more they will be gotten wrong. That doesn't mean don't put have them available, but don't impose them on. That usually requires some kind of fast path for common usage that doesn't require the programmer to know everything, so it's not like there aren't ways to deal with it, but it should be a part of the design process.

Jon - Right. Perhaps transport folks are not the right ones to do APIs, perhaps the applications folks would do that. That split of work might be a part of an output of this.

Dmitry Anipko (Microsoft) - From your perspective, what is the goal of this work, can you summarize the problem statement in one or two sentences? Is it a final goal to have an API which will be the same across platforms which applications will be able to use?

Jon - I don't think we deliver an API. We're going to deliver a discussion which might inform -

Dmitry - I understand, but the endpoint of the discussion?

Jon - We want efficiency and user experience to improve. This is what's driving people to do workarounds. The workarounds are not always good. The output might be a list of the things that a small shift in API choices would mean so we can do things in a set of right ways rather than working around lots of things.

Dmitry - If the goal is to come up with a set of recommendations, or a set of service models, a session like abstraction, and abstract APIs for that, that is fine. If the goal is an API that is useable by all applications, I don't think it is a reachable goal. I just looked up Android API, Windows Store API, iOS API, and they are different for a reason, because people are making money off applications that are limited to their platform. So unless there are specific applications targeted like the ones in web browsers which are supposed to be the same on all platforms, I don't think it's realistic to have an API which is the same on all platforms. So I'm asking what's the goal, shall we spend any time on API development itself?

Jon - Making money is not the only motive for changing APIs, there are other motives. The IETF doesn't itself make money. I don't think that makes it a non-achievable goal necessarily. I think the purpose of this meeting is to figure out what are reasonable things we might write down for the next meeting that would then lead to achievable goals.

Adam Montville (relayed by chair) - Echo a lot of what some of the last commenters have said, with a call for the IETF to conceive a standard set of personas efforts such as this can leverage when considering behavior-driven design.



Martin Sustrik: Towards Transport-Agnostic Middleware
(draft-hurtig-tsvwg-transport-apis-00)

Kevin Fall - Previous slide (PGM for LAN vs. TCP for WAN): who defines that policy?

Martin - network admin, has the most information about the network.

Kevin - Good. The programmer, as you argued, might not know all those deployment concerns. The arguments are all performance based arguments. So the setting might be different between environments. To categorically say pub/sub should use these protocols... there will obviously be exceptions.

Martin - Idea would be to have some heuristics by default and allow admin to set them.

Yoshihiro - Slide number 3. Protocol stack. I saw a messaging middleware layer; usually when we talk about a layer it implies there are some end parties that use a layer and communicate, exchanging some information. If that is correct, it could be more than an API, some new protocol may be needed to realize that layer.

Martin - Of course the concrete messaging middleware implements some kind of protocol, but that's kind of irrelevant for this group.

Yoshihiro - I would suggest to discuss the use case more detailed to see if some protocol work is needed or not.

Martin - For message middleware, yes, but the scope of the BOF is smaller, we're just interested in the API stuff, not the protocol stuff

Yoshihiro - Then I think I would suggest to change this figure.

Martin - That was just an introduction to the middleware.

Dirk Kutscher - Seems like some research topics are re-appearing every 10 years. 10 years ago pub-sub, message passing etc. was really popular. We even did one here, RFC3259, which had a different approach but similar concepts. Also the idea of flexibly specifying the group of communication peers, infer appropriate underlay, UDP, shared memory or TCP. I think what you got better here is the separation between policy and mechanism selection. What is the current state of message passing / pub-sub research? Is this your current work, or are you referring to previous efforts?

Martin - What I've explained is the state of affairs. What we have now is several protocols that we can use, and they work like fall-backs. Typically you want to use something like PGM to distribute messages on the local network, but if there is no PGM, what you can do is to simply simulate non-reliability on top of TCP and use that. 

Michael Tuexen - The programmer specifies pub/sub and then you have a network configuration which says "I do it over TCP" or whatever. Isn't it also required to say, if you use pub/sub, that you intend reliability or non-reliability? And wouldn't you code against that? Doesn't this mean that the guy who's making the choice which transport protocols to use also needs this? So there is more information needed to make these choices, except for pub/sub or whatever programming pattern you use?

Martin - When you look at the patterns, very often the pattern has very specific requirements about the transport. When you're doing pub/sub (example on a slide), if you use a reliable transport, it is not going to work. It's going to hang up if you have a lot of nodes because one of them will be slow, one of them will die, the whole distribution tree will be dad.

Michael - Okay, so it's part of pub/sub that's unreliable?

Martin - Yes, it must be. That was the point I was trying to make, that just specifying your scenario, your use case, often gives you a lot of requirements for the transport service you want to use.

Erik Nordmark - Can you express the ordering assumptions that the applications may or may not have? One of the things that Jon brought up is being able to remove Head-of-Line blocking and reduce average latency by delivering things out of order. If I gave you that and you plugged it in underneath, would your applications continue to work, or would they have to specify that these messages would have to be published before those can be published? Today I don't think we have anything like that in the system. It's a general question, if we relax the constraints underneath at the transport, does it bubble all the way up to the application, and the application needs a different language to express these things that we don't have?

Martin - Depends on the pattern you are using. Most applications in the pub/sub space expect that messages appear in order, but it's pretty easy to do ordering on top of the transport layer because it's unreliable, so you just drop messages that appear out of order. In the other use case, request/reply, you don't care about ordering. The client sends one request and gets one reply.

Stuart Cheshire (Apple) - One of your slides said that the developer can't tell at development time what is the right protocol to use. I disagree. As a developer writing an application I have some idea in my head about what services are available to me and if I want the data to be delivered reliably, in order, than I would use TCP that does that. And if a different transport is shimmed in at runtime that doesn't deliver data in order then my application breaks. If I have to know that I might not get data in order and I have to build my own reordering mechanism, then TCP didn't save me any time because I had to do write the code anyway. If I want something that preserves message boundaries, and you substitute something in that doesn't preserve boundaries then my application breaks. So the only time I believe it's sensible to make these decisions is at development time because it controls your decision about what lines of code to write and what libraries you're going to use. It reminds me of something from long ago before I even worked at Apple, before OS 10, on Mac OS 9, they adopted the streams networking infrastructure. The executives told us that this is absolutely wonderful - they had slides with boxes with arrows showing how you could plumb any of these streams modules together in any order you wanted, and in fact the APIs, when an application opened a networking socket it passed a string saying "TCP,IP,Ethernet" which told the network stack which streams modules to load and how to plumb them together. And then WiFi came along, which is not Ethernet, so they had to change the code and go "you asked for Ethernet, we're going to ignore that". Then it turned out, if you tried to run TCP over AppleTalk, it just doesn't work. The oil and water don't mix. It might be nice if you could run anything over anything, but it turns out in reality that it doesn't work. So, if the application specified "TCP,anything" they just ignored the "anything" and you got TCP. That was then TCP over IP over whatever hardware was there that supported IP, but this idea that you can mix and match boxes at runtime is very attractive on paper but I think in reality all the attempts to do that have failed.

Martin - I think you're right when you're speaking about about one-to-one applications, but if you're thinking of something like this, a global distribution of NYC feeds from the global exchange to the traders, every part of the tree belongs to a different organization, in a different part of the world, basically there is nothing common. So maybe one part of the tree is a little trading shop in Malaysia, and another one is a big one in Russia, and each of them has different networking technologies. The top guy is NYC. Why should it care about a little trading shop in Malaysia? They just want to push the data out and that's it. That's the idea.

Harald Alvestrand - Two properties you need of a system where you can choose the protocol at runtime: both ends of the communication have to choose the same thing or there is no communication, and: configuration is going to be wrong so don't do it. The administrator specifying the policy for the default case is a sign of a bad design. By the way, all the pub/sub systems I know of use TCP because the state machine you get into by randomly dropping messages is far too complex for the applications to handle. So your choice of examples doesn't strike me as particularly compelling.

Martin - I think you're missing the whole PGM stuff.

Jon Crowcroft - There's a big deployment of PGM in three major trading networks where it has been running for more than 10 years, they have the Microsoft implementation in Reuters - this is a massive system, it's not TCP. It's out there. I agree with you about this point though, I don't think static configuration makes sense, which is why I mentioned the Happy Eyeballs parallel exploration of what set of protocols would fit together, so then you get both ends able to find a minimum agreement that would work necessarily and sufficiently for them. I think his answer is right about the protocol.

Harald - I don't know PGM, which is probably a weakness. Happy Eyeballs is a clear case of how things get very complicated very fast. I was discussing over lunch about a particular case in ICE where by having too many configuration options we could find out that we could spend 3 hours with trying a new alternative every 20 ms before being sure we had tried them all. Administrative configuration is not the answer, but trying every option is also not the answer, we need to think about this.

Martin - (elaborates on PGM example from slides) This is typical stock trading. On the line, using pgm because if you assign a TCP stream to each box you would just overload the network, but if you're sending the data to a remote location you're using TCP because multicast might not pass through the LAN. That's a real example of how it's used, and that means it's useful.

Yusuke Doi (Toshiba) - Question on security. Your idea is to decouple the endpoints between sender and receiver by some sort of abstraction like a messaging pattern, I think current security mechanism is best on pairwise authentication or authorization or integrity check or whatever. I think this approach will require something more than what we have. Do you have any idea on the security mechanism that can be coupled with this approach?

Martin - What people were doing so far with pub/sub was that a Publisher was encrypting everything and the Subscribers were decrypting it. If someone unauthorized was listening he would get it garbled.

Yusuke - I think something can be invented and integrated.

Dave Thaler - Agree with what Stuart said, and agree with your response, and will try to generalize that and add something to it. For people who write applications, by which I mean stuff way up here, too many options confuses them. This was probably Dave Crocker's point as well. Having things that are tailored to what they're trying to accomplish is good. Kind of what you're doing here is for those who are doing pub/sub type stuff, you're trying to construct a higher level semantic that's this pub/sub API. That's the point that says, well that's actually more understandable than this lower API that's just plain sockets and stuff. So there's benefit in that. What there's less benefit in is a transport-agnostic API that's really low level, that says "oh, I can turn on and off all these different options", it's something that's a good API but it's not for app developers, it's for people that develop this sort of stuff, people that are the networking experts. The application developers are usually not networking experts, they're experts in doing what their application is trying to do. Fewer options for them that say this is the thing that's looking like it's doing what I want, and this is an example of that, and I think that's kind of what Stuart was getting at in his points, to say you gotta put the right decisions at the right place. So I don't think your points are incompatible, which was your response to say, for one-to-one, there are some considerations, for pub/sub there's this higher-level semantic and things. And so I'm a fan of things that are higher-level semantics that say "here's the easiest way to do what you're doing", and maybe the higher-level semantics here is then in your example the transport agnostic stuff, where I may be relaying some stuff over PGM and other stuff over TCP, and that's an example of a higher-level framework that's not sockets-level stuff but at least one layer up. I think you guys are actually both right at different layers.

Toerless Eckert - About Security. One of the pain points you bring in here when you say encryption is whether at the abstraction of the transport it is feasible to do group keying, because in this example you do replication in the network, for this you would need group keying, sometimes group keying is not applicable, so how do you deal with this in the general case?

Michael Welzl - reminder: intention is to define a set of services, not to come up with one particular lower-level API, and implement this in various ways. What you've just seen is a presentation of how these services could be embedded in a middleware to make it work better, as one particular implementation. But Gorry will clarify implementation possibilities.



Gorry Fairhurst: How could Transport Services be provided?
(draft-montpetit-transport-strawman-00)

(presentation: Goal 1: Choice of protocol can become transparent for application)


Dave Thaler - There are two different ways the discussion could focus here. The stuff being talked about here is saying, there is some intelligence that needs to happen; these are considerations that are like inputs to that intelligence (your blue bullets (referring to slides)). Talking about what the behavior should be, based on those and how to use those is useful, for example, MIF is doing some of that for one or more of those bullets but maybe not all of them. Separately, should there be APIs for that? Those are actually two different questions. You could imagine that the people writing the middleware boxes that you showed on the previous slide might want to attain control there and differentiate or have five or six of the bullets and so on. So I buy that any guidance we can provide there is useful, the IETF has been doing some of that, in MIF, ICE and things like that, but it's not at all clear to me that a middleware would actually want an API here. I agree with the goal, but there's two different ways to interpret that, those are different and we should discuss those separately.

Gorry - I would add to that the middleware would want to know what was chosen and have the possibility to get that right. Not just a matter of saying "go and do something for me".

Dave - My point is, the middleware may want to do the choosing itself. Not obvious that a middleware might want to call the TAPS API as opposed to implement the behavior you described, but maybe one more piece or one less piece. Picture on previous slide may or may not match.
 
Dirk Kutscher - about run-time decisions: many of those depend on what the other side supports. Someone mentioned ICE before; to me this looks like something effectively requiring ICE.

Gorry - I don't want to rewrite ICE. ICE does exist, people may need to use TURN service to get through various NATS at different levels to do TCP transition. There are many of these modules around, and I'm interested in getting those working, not in rewriting them. Many apps need this sort of mechanisms.

Dirk - I'm afraid of the explosion of combinations

Gorry - Part of my motivation here is to get that explosion under the control of people here a little bit, instead of everyone writing an explosion of code to try and code around these. ICE is already pretty complicated. There are other things on the radar that aren't ICE but are similar multi-option negotiation things that have to be performed.

Andrew McGregor - Need to advise implementers to expose what actually happened so these things are debuggable.

(presentation cont'd: Goal 2: Needs to work if this is only implemented at the sender
(Hopefully only a sender-side at the beginning)).

(presentation cont'd: Goal 3: Faster choosing of an appropriate transport.
(Multiple interfaces often available)).

(presentation cont'd: Important: we can put machinery to find out other transports or communications abilities available to the application. Example, discover path MTU for a given connection/association.)

Chair relaying question - Will it be made clear at some point how service characteristics will be represented and selected? For example, if I want to choose a transport with specific QoS or confidentiality characteristics, how is it determined at the time of the call? So it seems that some model for representing capabilities is going to be needed.

Gorry - That may well be within the scope of what we're trying to do here.

Stuart Cheshire - Similar sentiment to what I said before, which is that I really thing the decision about what transport to use ought to be made at design time. Comment about the wording on the second slide where it talks about "a lot of app developers don't want to support more than one transport protocol" - that's a very telling phrase. It's not the job of application programmers to support transport protocols, it's the job of transport protocols to provide the services that applications need, and as soon as we turn this around and say "those mean app developers are not using my shiny new SCTP" I think the burden is going in the wrong direction.

Gorry - That wasn't the intended point. My point really was that it's the middleware that matters. I'm not so interested in what apps people do, the apps people operate with middleware and it's the middleware that has to be keyed in with this.

Jon - One of the motivations we have for PVTCP was that things change during the transport session. For example, may migrate endpoint of an MPTCP from on the same core to another core, then you might want to migrate it off to a different rack, and you want to keep the MPTCP connection without reestablishing all the keys and going through a RTT, not good, that's happening all the time. May seem to be a special case but everything seems to be a special case. So I think we have an argument for that, with multi-endpoint cases, may not be very many cases, but then we could enumerate them, maybe there's only 2-3 of them and we can just have those coded up in a nice way, that would be great.

Stuart Cheshire - It's a terminology question: is MPTCP a new transport protocol or is it a variant of an existing one? In the sense of the API provided to the application, it's providing the same in-order byte-stream service that doesn't preserve message boundaries, so the application doesn't have to change its assumptions even though the layer below is getting more capable, and I'm all in favor of that. It's the question of whether the application services are uncertain at design time that I'm more sceptical about applications being able to handle that.

Gorry - Understood, I don't think there's a big a difference here with what you just said.

Toerless Eckert - I fully agree with what Stuart said, but I just can't see how that is against having a TAPS API. I really think that having the abstraction take away the complexity of dealing with these protocols cannot be done by the next guy saying I have this new shiny protocol that has all these features in it. It's always a reactive thing of us bringing together multiple things that have been developed independently. In the past there have been a lot of efforts of people trying to write these kinds of abstraction layer but I don't think in the IETF we ever figured out a strategy around that, we said we don't do API so go to POSIX, but POSIX didn't do a good job for us. What can we do here about this? I'd love to support this.

Marie-Jos‚ Montpetit (MIT) - After I did the draft I did speak to a number of application developers, some of them being my students, and I follow with the comment from Stuart, there are issues. One that they raised is: yes, it would be nice if there was this way, because suddenly the application is used across some network or subnetwork that would require a better transport protocol, and there would be a way to use it, and that's fine - but they also have a problem with testing, and noone has raised the issue of testing. People spend an awful lot of time and an awful lot of money making sure that their applications work. If they test it with TCP and it works perfectly and then somebody changes the transport and you put it in the app store and it fails miserably, that won't work. So, I didn't put that in the draft, but I think there should be something in this group that will address the daily life of software developers who have to test things.

Gorry - Yes, and that's particularly true when you have things like Happy Eyeballs etc. all done without having any audit of what's going on.

Scott Brim - Regarding this beautiful diagram, in a wonderful world of course you have a single universal TAPS API, but that just begs the question: if it's a research project, yes, but if you're trying to get traction in the Internet, you have a huge hill to climb, and we need some sort of intermediate steps that you can take before you can get there, you need some motivation - why should Google do that, for example?

Dave Thaler - The point about testing is exactly right. Comments on this picture here: the TAPS API does not make evolution possible. The middleware made evolution possible, and so, why are the box with the TAPS API and the middleware box different boxes? There's a distinction between abstract APIs and concrete APIs. Abstract APIs are somewhat synonymous to service models; that's what MIF does, that's what GSSAPI did - an abstract API *and* a concrete API - and concrete APIs like Javascript is owned by W3C, C++ is owned by ISO/IEC and all of those are examples of things that are not sockets but they are above sockets, and there are other things that are above middleware like a pub/sub API like in previous solutions. When we're talking about evolution, which ones are we talking about? The ones that are written by people that are networking experts want to retain control because they have algorithms that they think are doing the job. You can give them advice, but they want to be making the decisions themselves. What I don't buy is that big yellow line in there being valuable.

Gorry - That big yellow line was meant to be a fuzzy line that didn't exist.

Dave Crocker - There was a reference today to a different standards group that had 4-5 transports as alternatives, and they didn't do as well as TCP did. My understanding is that when TCP was under development and LANs came along in the middle of that, there was a huge debate about distinguishing TCP over LAN vs. TCP over WAN, and the debate was quite luckily (or just good insight) chosen to be simplified: we ought to be careful that all those bright shiny alternatives don't create more problems than they solve. That said, I think this is a great session. Since this isn't targeting a working group, this sounds perfect for a research group.

Chair - This is too early to talk about; we've taken the "chartering, where should it live" specifically off the table to leave room for general discussion.



Margaret Wasserman: An Introduction to Multiple Interfaces WG (MIF)

(presentation: Some application of MIF to this BoF. DNS and VPN examples were provided. Administrative domain and a provisioning domain examples were provided. )

Michael Scharf - Speaking as an author of the multipath API document: while MPTCP is a success story right now, we have the problem that the API document that I personally wrote is not deployed. The question to this group is, how can we ensure that if we wrote a document that it will be deployed? In MPTCP we have an existence proof that we failed on this so far. It might change but it hasn't been successful.

Margaret - In IPv6 we wrote an API on extensions to sockets and they were widely deployed. So we have existence cases that it works as well.

Tim Shepard - "local printing when I'm on my VPN" example from Margaret's presentation - the higher level question is: is there any hope of this being at all useful without having to go upgrade all the apps to be provisioning domain aware?

Margaret - Certain things will help. There's the problem statement and a separate existing solutions document. There are already things nodes do that try to help with this. They'll do DNS out of multiple interfaces at the same time, or multiple interfaces in sequence, different OSes do different things. If your printer is that printer.local and your VPN has a DNS that doesn't know about printer.local, if you tried both DNSes you'd find printer.local. A lot of nodes don't try both DNSes, they got DHCP off the VPN and they threw away their DNS list from the local network because they don't know what to do if they get two, and this is intended to solve that problem. 

Jon - I wish I had known about this about 3 years ago, we did MPTCP for Android, and there's a policy database that my grad student put in which gives you 3 options, it is not complicated - it doesn't say don't do MPTCP, or do a fall-back to TCP if MPTCP is not going to work because you don't get through some crazy middle-box or the other end doesn't do it, but the policy choice is: do you want to maximize your battery life, so you use the lowest-energy interface out of your WiFi or 3G, or do you want to maximize your throughput, which would be one reason to use MPTCP (or reliability because of path diversity), or do you want to minimize the price because your 3G roaming has just kicked in and you're from the US and you're in Europe and it's going to cost you your flight home for the next 3 minutes. So at least one point there is, I think your work has an interface to new things you might want to do with new transports.

Margaret - It's doing a similar thing, but it's available to all of the upper layers. Some upper layers will continue doing what they are doing, and the IP stack will still try to make the best choice it knows how to make, like what it's doing now.

Dave Thaler - How do you make an API be successful? You mentioned the IPv6 one, so I wanted to give a data pointer: the IPv6 ones (the basic socket extensions and then the event socket ones) were successful in part at the time because the majority of applications then were writing to the socket APIs. That's no longer true. So the reasons why they became successful no longer apply. There are other APIs the IETF has done, and I was an author on one of those, which was the multicast socket extensions, which was shortly after that time, and there the reason that became successful is because we specifically worked with the POSIX community, and they standardized what we published in the POSIX standards. We worked with other SDOs. This gets back to my point, when doing concrete APIs, the way to be successful is to work with the SDOs that actually own that. The C++ standardization committee, the Javascript standardization committee, whoever it is that's actually authoritative for that. To say "here's the service model, here's the sample API, you guys do the language binding", that model actually works very well. What also works very well is where we just do a service model or an abstract API and then we leave it to them to come up with something and then we review their stuff. The main point is, it's the cross-SDO interactions here that I want to encourage, and that's what makes you successful because that's what the applications are writing to. It's not what we do but what they do.

Keith Moore - Tension between trying to hide complexity from applications that results from multiple interfaces, multiple transport protocols or whatever, and on the other hand to try to give applications the flexibility they need to deal with different scenarios posted by multiple transport protocols, multiple interfaces, whatever. If you try to hide the complexity, you will break applications, full stop. There is no such thing as a general ability to move from one interface or protocol or provisioning domain or whatever to another without breaking some applications. If you try to make all this stuff visible then you end up giving application so many knobs that you break them in a different way. I was doing work with multiple interfaces in the late 90s and I found dozens of profiles that applications might need to follow, and trying to get a stack to understand the subtle differences and all the different choices they could make with with address selection, interface selection, transport protocol selection, I was trying to deal with all of that, and it got very hairy very quickly. If you only came up with 3 different profiles you were not looking very hard. I don't have a good answer for you, but there are certainly dragons in this space and it's really easy to make things worse than they wore beforehand.

Margaret - A lot of this work is driven by some of the mobile people who are already writing what they call connection managers that provide those higher level APIs that Dave was talking about, although there are many others. These people know what they want to offer. Jon talked about offering 3 choices; they know what they conceptually want to offer, but they need a way to to find out from the stack what interfaces are available, and tell the stack what interfaces they want to use, it's unlikely that a low level API that we're defining now will be touched by what we typically call an application; it would likely be the middleware stuff that Gorry was talking about that would probably touch our APIs, and then the upper level applications would be talking to Happy Eyeballs, or some of the middleware, or something like that. Read the documents and send questions to mif@ietf.org.

Chair - Question to the audience: Does the definition of an API shed light on the services that transport needs to offer to applications? Hum?

Audience - this is a meaningless question.

Joe Hildebrand - I am IAB shepherd here; we don't necessarily need the answer to a question like that right now to judge the sense of the room. We don't know quit enough yet. I think there was some good talk back and forth here amongst the folks from applications and transports, which was one of the reasons this was interesting for us to have this on the agenda here, so thanks everyone.

Spencer Dawkins - I'm the responsible AD; thanks everyone, I really appreciate having the applications' participation.

END.