Background information and material

Potential benefits:

This paper:

Michael Welzl, Florian Niederbacher, Stein Gjessing: "Beneficial Transparent Deployment of SCTP: the Missing Pieces", IEEE GlobeCom 2011, 5-9 December 2011, Houston, Texas.

shows that SCTP's multi-streaming can be transparently applied to TCP connections, giving significant performance gains.

API design:

Stefan Joerer's master thesis and ICC'11 paper:

Michael Welzl, Stefan Joerer, Stein Gjessing: "Towards a Protocol-Independent Internet Transport API", FutureNet IV workshop in conjunction with of IEEE ICC 2011, 5-9 June 2011, Kyoto, Japan.

This gives an example of what the WG's work could look like: from mining RFCs and applying certain rules, we systematically arrive at a list of services and then describe how they could be incorporated in the socket API.

How could it work:

Connection establishment - finding out which protocol works: Happy Eyeballs (old i-d, IPJ article).

Issues:

• e.g. SCTP INIT-ACK can arrive after TCP SYN-ACK: we can use it for a later connection if we need it (thanks to Joe Touch for this idea), or terminate and populate a cache with "SCTP works on this path" information such that we wait longer.
• scalability: IPv6+IPv4+SCTP+TCP already gives us 4 packets to send. This may have been the reason why SCTP was removed as the i-d proceeded towards its publication as RFC6555, but:
  • IW10 allows sending 10 packets in one go *after* the handshake, so why is it a problem *in* the handshake?
  • Losing TCP SYNs is a real issue, and hence sending multiple packets for connection setup is perhaps by itself a good idea
    • If we use a protocol for later connections, we may not need to shoot out all packets in the first RTT

If a protocol is not available / some mechanism does not work:

• There was some discussion on the mailing list about the possibility of using TCP as a fall-back for everything, and realize all services with a shim layer on top of TCP.
• ... or everything could be done over UDP.
• Not everyone agreed with such a fall-back design; the only alternative might be to sometimes say "no" to the requesting application. Both are possible implementations.

Connection establishment - telling the other side which protocol to use: e.g. draft-wood-tae-specifying-uri-transports-08 or, more generic but perhaps more heavyweight, BEEP

A related IETF activity:

• AEON

Some supportive (in my opinion) papers and position statements:

• "RUTS at IETF 43: a look back", presentation by Spencer Dawkins @ IETF-88. See the last slide: "Perhaps time to think about it again - Step back, look at big picture like RUTS"
• "Functional decomposition of the transport layer", presentation by Jana Iyengar @ IETF-88. See slide 5.
  • "The 'best effort' service as a deployment success factor" by Michael Welzl @ IAB Workshop on Internet Technology Adoption and Transition (ITAT) 2013
• "Towards More Expressive Transport-Layer Interfaces" by Lars Eggert and Wes Eddy @ MobiArch 2006
  • "A Case for Middleware to Enable Advanced Internet Services" by Michael Welzl @ NGNM Workshop, Networking 2004
  • "Service-oriented Protocol Interfaces and Dynamic Intermediation of Communication Services" by Dirk Henrici and Bernd Reuther @ CIIT 2003, and many more papers by Bernd Reuther et al (just look for DANCE or "Service" in this list)