How Applications (Will Hopefully Soon) Use the Internet Michael Welzl Max == 60, TU Darmstadt 30. 6. 2017

Valuable?? Original Max typo from 1999 !

Layering is broken in the Internet node A node B e.g. HTTP Application Layer Transport Layer entity UDP TCP  Applications expect precisely the behavior of TCP and UDP  Routers expect to see precisely TCP or UDP (sometimes with even more limitations)  OSSIFICATION

Transport layer development Computer, 30 years ago A program that sends data over the Internet, 30 years ago (using Berkeley sockets)

Transport layer development Computer, today A program that sends data over the Internet, today (using Berkeley sockets)

More than just sockets... Previous example: Berkeley sockets Today, applications use many different APIs These higher-layer systems use sockets  can only offer the services of TCP and UDP A reliable byte stream Unreliable packet (“datagram”) transmission It’s a way of thinking about communication !

... and it’s from the 80s ! Reliable byte stream, TCP Datagram, UDP

What about... Priorities? Among your own flows, and between yours and others? Careful “do not disturb anybody” background (“scavenger”) communication? Intelligent use of multiple network interfaces? Maybe using data even when a checksum fails? Codecs can handle that, but UDP will throw away all your data Using protocol features that yield lower latency? Maybe trade latency against bandwidth? Control the send buffer?

Example: unordered message delivery Some applications can accept data chunks out of order, even when requiring reliability TCP causes Head-Of-Line (HOL) blocking delay TCP receiver buffer Chunk 2 Chunk 3 Chunk 4 Chunk 1 App waits in vain! Some protocols can deliver data out of order (e.g. SCTP) If such a protocol is not available: fine to use TCP! in-order delivery is correct! Just slower ... BUT: unless an application asks for it, we can NEVER hand over data chunks in the wrong order.  This service needs to be in ALL APIs ! (not just socket level)

Solving the problem Unordered reliable message delivery is only one example... What is the minimum set of transport services that we “must” make available everywhere for them to become usable?

Bottom-up method to derive a minimum set of transport services IETF Transport Services (TAPS) Working Group Survey of services provided by transport protocols – RFC 8095 (54 pages) In-depth analysis of 30+ RFCs: TCP, MPTCP, UDP, UDP-Lite, SCTP, LEDBAT (2 Internet-drafts, 70 pages) Derivation of a minimum set: from 2), keep only services that require application-specific knowledge; do not prohibit falling back to TCP; resolve some resulting peculiarities (1 Internet-draft, 44 pages)

Result (latest version): high-level view Flow creation and flow grouping Most configuration features only configure a group (e.g., can’t configure timeout for an SCTP stream only) Should use configuration early, ideally before connecting Send-before-connect Could also be implemented as a parameter to “connect” Specify “idempotent data” for extra-fast transmission Limited connect / listen / close / abort semantics Connect may not invoke accept! No half-closed connections

Result (latest version): high-level view /2 Send messages, receive bytestream Messages stay intact, but may be (based on sender wish) reordered or dropped (configurable reliability) Receiver must be aware (detect boundaries) Be informed about sender buffer running dry Late decision about choice of data to send Configure: per-flow priorities, network-wide priorities, timeout, authentication, checksums Some queries, e.g. related to packet sizes

What’s next? How real is this? Apple now contributes to the IETF TAPS WG Interested in this open standard because of TAPS project implements a TAPS++ system a cleaner Internet transport layer; avoids re-inventing the wheel! Partners: several Universities, Mozilla, EMC, Cisco, .. Already works! e.g., demo shown with Firefox Nice research tool – e.g. lets you access features of SCTP, MPTCP, .. now even with Python bindings http://www.neat-project.org https://github.com/NEAT-project/neat "NEAT: A Platform- and Protocol-Independent Internet Transport API", IEEE Communications Magazine 55 (6), 2017.

Thank you! Questions?