Please note that the drafts provide more elaborate answers to some of these questions: there is a problem statement, a strawman architecture, use cases, ...
Q1: Why do we need this, what are the benefits?
A1.1: Protocols like SCTP offer a lot of functionality, yet their usage is quite limited. The sheer length of the API description, while necessary to cover all of SCTP's functionality, doesn't make it more attractive. Some functionality is now duplicated in MPTCP and TCP Minion, and each and every one of these solutions requires applications to use a dedicated API, which isn't even always standardized (e.g. there is no RFC describing an API for DCCP or LEDBAT). The result is that the most attractive approach for application programmers is to do what is already being done today: if you don't care much about performance, choose TCP; else, and if you're an expert (or a company that can afford to do it), implement your own protocol, preferably over UDP (cf. RTMFP, QUIC).
A1.2: Hiding the choice and configuration of the used transport protocol from applications can potentially give applications most of the benefits that protocols like SCTP, LEDBAT etc. offer, when- and wherever these protocols are available. It also has the potential to simplify the transport layer: e.g. it seems that the major gains of SPDY are attained via its multi-streaming feature, but this is impaired by TCP's RTT-scale head-of-line blocking delay; as this FAQ explains, QUIC is meant to address this problem. Would transparent usage of SCTP eliminate the need for QUIC, and even some of the functionality of SPDY?
A1.3: Pushing the complexity of using SCTP etc. away from applications, hiding it in the OS, gives OS designers greater freedom in designing their transport layer, which could help them in product diversification ("my transport system is better than your transport system").
A1.4: These days, everyone wants lower latency. To reduce latency, and limit the number of necessary handshakes, more band aids are not the answer; TAPS facilitates integration of functionality in a single place, which should help latency reduction (in addition to the possibilities listed in draft-petlund-latency-transport-services).
Q1.1: But why does it need a standard?
A1.1.1: Without a standard, there will be point solutions (as we have today). Some of them may be proprietary too. We'd like to achieve a more general move ahead for the transport layer, which is based on using mechanisms and protocols that the IETF has designed rather than re-inventing the wheel.
Q1.2: This is mostly about an API; why should the IETF be bothered?
A1.2.1: Not providing an API to the protocols means that we specify how something works without really specifying how to use it; that seems wrong, and there are enough examples of APIs coming out of the IETF. Besides, the plan is first and foremost to specify the services; we'll document at least one example API.
A1.2.2: The IRTF wouldn't be right, It's about finishing work that has begun in the IETF, and making sure that people can make good use of transport protocols that the IETF has defined. It's in the same spirit as specs for SCTP-over-UDP, DCCP-over-UDP, or the SCTP API - things that need to be done to make the standards useful. The IRTF is about longer-term research issues, about things that aren't ready for the IETF yet. Defining how to use IETF transports doesn't seem to fit in this category.
A1.2.3: Other standardization bodies wouldn't be right, as the expertise on the protocols really is in the IETF.
Q1.3: Why does it need a WG instead of just being a draft to TSVWG?
A1.3.1: TSVWG is a busy group, and this needs much discussion. We don't want to bore half of the TSVWG audience to death by debating API details - there needs to be a group for people interested in doing this work.
Q1.4: But... a WG?? This isn't even defining a protocol?
A1.4: Neither did e.g. PILC or any of the MIB groups. Besides, this affects the network, as it's about host behavior, even though it's one-sided - e.g. Happy Eyeballs for transports (we do have it for v4/v6, with RFC6555). Standardizing this is as important as it is to standardize congestion control.
Q2: How can we agree on the set of transport services that we want to expose to applications?
A2.1: We mine RFCs and some common higher-level APIs. This work will have an end because we're not open to add any random application requirement in the future - we go with existing APIs that are used, a set that the WG will define. Second, we try to map services onto each other. To get an idea on how a list of services provided by transport protocols could look, see Stefan Joerer's ICC paper + master thesis. This is only one way of doing it, but it shows that, using simple rules, one can systematically arrive at a reasonable (it seemed to us) list of services. Note though that this list would be longer today, as this work predates e.g. MPTCP and LEDBAT etc.
Q3: How could this work?
Q3.1: How could connection establishment be done?
A3.1.1: There are many possibilities; either way, one can rely on happy eyeballs (see the material page for more information).
A3.1.2: We don't want to require extra signaling. Note however that, if such signaling were done today, one would not only have to define the means of signaling but also the transport services that are being signaled. Thus, agreeing on transport services is necessary for such signaling anyway.
Q3.2: How does fall-back work?
A3.2.1: Easy enough, with Happy Eyeballs: as a last resort, TCP is used. (perhaps even as a fall-back for UDP? Why not?)