[Stackevo] Stack Evolution at the IAB/IESG Retreat: Status and Next Steps

[Brian Trammell <[e-mail]>]

Greetings, all,

At the IAB/IESG retreat last week in London, we discussed the current state and structure of the IP Stack Evolution Program, work that came out of the SEMI workshop which does not yet have an owner, as well as related new work to take on. Along with the recent discussion on scope and organization, it might be time to update our program description, as well.

First, a review of existing work happening within the program:

(1) Architectural discussion on SPUD: identifying the applications that would benefit from selective explicit middlebox communication in a transport encapsulation, determining the limitations on what can be productively exposed, defining a set of protocol requirements based on these applications and limitations. IMO only once we have a fairly solid set of requirements and agreement on an architecture within the program does it make sense to refer anything to a WG; in the meantime, the [e-mail] list will remain open for general discussion, and architecture work will happen within the program. On which, please have a look at draft-trammell-stackevo-newtea-01 and poke holes in it.

(2) Creation of a HOPS RG to coordinate research and measurement on Internet path transparency impairment caused by middleboxes. This is ongoing, and we hope to have a meeting in Prague. Once this RG is created, this discussion will move there. Mirja Kühlewind holds the pen on the proposed charter and first proto-RG meeting agenda at the moment.

(3) Completion of (currently expired) draft-iab-filtering-considerations, which went through community review in January 2014, inherited from the IP Evolution Program. Dave Thaler holds the pen on this; if you'd like to help, please coordinate with him.

(4) Completion of the SEMI workshop report. We'd like to get this done soon. Please have a look at draft-trammell-semi-report-00 and point out what's missing.

In addition, we have the following work items from SEMI which don't have an editor assigned yet:

(5) A document providing guidelines on middlebox design and deployment; from section 6.3 of draft-trammell-semi-report: "The workshop identified the potential to update [RFC3234] to provide guidelines on middlebox design, implementation, and deployment in order to reduce inadvertent or accidental impact on stack ossification in existing and new middlebox designs.  This document will be produced by the IAB IP Stack Evolution program, drawing in part on the work of the BEHAVE working group, and on experience with STUN, TURN, and ICE, all of which focus more specifically on network address translation."

(6) An IAB statement on transport protocol evolution. It's not clear what this do beyond blessing UDP as the way forward for new transport protocols, in effect acknowledging (1) that the network-transport layer boundary has been four bytes from where the RFCs say it is for some time and (2) that the kernel-userspace boundary isn't really useful for security in a world where everything is virtualized anyway.

At the retreat, we discussed a few issues which we may want to examine in more detail in the program:

(7) General guidelines/principles for designing new encapsulations. We discussed at SEMI the possibility of working on guidelines for UDP as a transport substrate, but this is largely covered by draft-ietf-tsvwg-rfc5405bis. Erik Nordmark raised the point at the retreat that there are a bunch of new encapsulations (e.g. BIER, NVO3) coming out of the routing area, and these may have some common architectural principles with each other as well as with with new transport encapsulations. I'd nominate Erik Nordmark to lead following up on this, since he brought it up. :)

(8) Related to this, there appears to be some architecture and coordination work to do on new stacks, or rather, pointing out well-known principles of good engineering thereon, especially for IoT applications. Are there common principles which can/should be applied to the design of these stacks to make sure we don't have piles of gratuitously incompatible protocols?

(9) General guidelines for protocol transition. If the program is to define an architecture for evolving the transport layer, this will need to have the right incentives for deployment for new applications, as well as for transition from existing transports (where this is useful -- mainly in cases where TCP or HTTP have been pressed into service for less-than-appropriate applications). If there are guidelines for transition to be generalized from this, this would make a new document.

We briefly mentioned (in the joint session with the IESG), but did not discuss, one further piece of work:

(10) An IAB statement on the deployment of ECN (along the lines of 'yes please'). Probably this is a pointer to draft-tsvwg-ecn-benefits and related analysis of the risk of enabling ECN by default (see http://ecn.ethz.ch/ecn-pam15.pdf). We should discuss whether this is something the IAB would be interested in doing before putting much effort into it.


We should put some thought into which of these things we think we can get done during this year (rather, until Buenos Aires), and update the program's description at https://www.iab.org/activities/programs/ip-stack-evolution-program if it's not current anymore. Clearly (1), (2), and (4) are related to the original scope and are ongoing, (5) and (6) are related as well and were referred to us by the workshop (so we should get some names assigned to them, hint hint :). If you've got particular interest and cycles to work on these (or any of the following things), please shout.

Thanks, cheers,

Brian