Subject: [Stackevo] a page on what Stack Evolution is and why one should care

From: Brian Trammell <[email-masked]>
Date: Thu, 23 Apr 2015 18:33:10 +0200

Greetings, all,

In the context of a question ISOC asked the IAB about helping to publicize our activities and programs better, I put together the following few paragraphs (with feedback from Lars and Ted) on what it is we're trying to do here in the short to intermediate term:

--

The Internet has been using basically the same stack for the past two decades. A great deal of effort has gone into IPv6 transition, and it appears that this effort is finally paying off. And there are many new applications running on the Internet, though these run more and more often atop HTTP. But between these layers we have basically the same good old TCP we have since the nineties.

But is this not simply an indication that we did TCP/IP right? Is this a case of if it ain't broke, don't fix it?

Not really. Transport is proving just as hard to update and extend as the network layer has, and for largely the same reasons: many devices in the network make implicit assumptions about the structure and meaning of protocols above IP, and the widespread deployment of code in an operating system kernel is difficult. And this is causing a real problem. It's not just that good engineering effort on new transport protocols (e.g. SCTP) and extensions (e.g. ECN) goes largely undeployed. New applications need transport services other than those provided by TCP, and in the meantime are forced to roll their own solutions for problems common to the transport layer, with the attendant costs and disadvantages for open interoperability.

The IAB Stack Evolution program is exploring solutions to this, focusing on architectural questions. We have an opportunity to make progress on this problem due to another collision of forces: the increasing reliance of network management on middleboxes on the one hand against the increasing deployment of cryptography to protect confidentiality and integrity on the other. We're currently asking whether a change to the architecture would either support new session, reliability and transfer semantics better, especially given that many policy mechanisms now rely on cleartext access.

Specifically, the Substrate Protocol for User Datagrams (SPUD) focus area within the program is exploring the possibility of combining encryption of application and transport headers, selective exposure of transport semantics, and a UDP-based encapsulation to allow userspace deployment, as an experimental protocol to determine what kinds of information are really necessary for middleboxes important to the operation of the Internet to have access to in order for them to function property.

The eventual intent of this effort is to help application and platform developers apply best transport practices in an environment in which data and metadata are protected from meddling and observation, enabling new applications to deploy in the Internet, and maintaining network manageability while providing increased privacy to users. Should this work identify appropriate concrete engineering challenges, these will be brought to new or existing working groups within the IETF. Focused research problems may be the work of future research groups within the IRTF.

--

There are things which are missing (everything around TAPS, already a WG; everything around HOPS, which I suspect is probably an RG), which could be added to a more comprehensive statement, but I wanted to start with where the energy coming out of Dallas seems to be.

Comments and flames much appreciated.

Thanks, cheers,

Brian