Subject: [Stackevo] Updated description for stack evolution program

From: Brian Trammell <[email-masked]>
Date: Wed, 10 Jun 2015 17:26:21 +0200

Greetings, all,

The result of our discussions here has (I think) resulted in the following unified text. Please speak up if this isn't ready to ship.

Thanks, cheers,

Brian

--

Description

The IP Stack Evolution program covers various topics in the evolution of IPv4 and IPv6, the transport protocols running over IP, and the overall protocol stack architecture. The program addresses challenges that affect the stack in some way and where the IETF community requires architectural guidance, responding to community requests as well as actively monitoring work within IETF WGs which touch on relevant topics.

There is an observed trend of functionality moving “up the stack”: where the “waist” was once IP, now most applications run over TCP/IP, or even HTTP/TCP/IP; the stack has become increasingly ossified. This is in response both to reduced path transparency within the Internet — middleboxes that limit the protocols of the traffic that can pass through them — as well as insufficiently flexible interfaces for platform and application developers. The emergence of both new application requirements demanding more flexibility from the stack, especially at layer 4, as well as the increasing ubiquity of encryption to protect against pervasive surveillance, provides an opportunity to re-evaluate and reverse this trend.

This program aims to provide architectural guidance, and a point of coordination for work at the architectural level to improve the present situation of ossification in the Internet protocol stack. Where a working group relevant to a particular aspect of IP stack evolution exists, the program will facilitate cross-group and cross-area coordination. The program also produces documents on the IAB stream providing general guidance on and covering architectural aspects of stack evolution.

Current active work in the program includes:

(1) Definition of requirements and principles for encapsulation-based approaches to work around path transparency issues and to allow explicit cooperation between endpoints and devices on path, while cryptographically protecting information which should remain end-to-end (including transport headers). This work follows discussions at the IAB SEMI (Stack Evolution in a Middlebox Internet) workshop and the SPUD (Substrate Protocol for User Datagrams) BoF at IETF 92 in Dallas. Discussion of this work occurs on the SPUD mailing list: [email-masked].

(2) Evolution of interfaces to transport and network-layer services: improving the access of applications to the specific transport services they need (e.g. reliability, latency guarantees, congestion control properties, message boundary and order preservation, etc.) beyond the traditional SOCK_STREAM and SOCK_DGRAM interfaces. Further architectural work in this space awaits the results of related engineering being done in the IETF TAPS Working Group (mailing list: [email-masked]), the activities of which the program monitors.

(3) Discussion of principles for making new protocols within the IP stack deployable, following in part on RFC 5218 "What Makes for a Successful Protocol".

(4) Definition of principles for the use of encapsulation at various layers within the protocol stack. UDP-based encapsulations are not only useful for evolution above the IP layer, but in many tunneling contexts as well. The probable commonalities among all these applications of encapsulation might be useful in simplifying their implementation, deployment, and use.

(5) Architectural guidance for stack evolution should be informed by empirical evidence where possible and appropriate, so the program encourages efforts to collect, disseminate, and analyze data pertaining to the present state of the Internet with respect to its other activities. Work here currently focuses on the potential establishment of an IRTF research group to coordinate measurement of path transparency issues caused by middleboxes, following on the HOPS ("How Ossified is the Protocol Stack") Bar BoF at IETF 92 in Dallas. Discussion of this work occurs on the HOPS mailing list: [email-masked]

(6) Architectural guidance on traffic filtering and blocking, to result in the publication of draft-iab-filtering-considerations.

This program has itself evolved from the IP Evolution Program, which looked at general architectural issues in the evolution of IPv4 and IPv6 and the overall protocol stack architecture, and produced the following documents:

IAB Thoughts on IPv6 Network Address Translation (RFC 5902)
Evolution of the IP Model (RFC 6250)
Smart Objects Workshop Report (RFC 6574)
Architectural Considerations of IP Anycast (RFC 7094)

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2015 15:31:13 +0000

I think RFC 7305 needs to be added to the list at the end.
Otherwise good.

Dave

-----Original Message-----
From: Stackevo [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Wednesday, June 10, 2015 8:26 AM
To: IAB Board; Stackevo
Subject: [Stackevo] Updated description for stack evolution program

Greetings, all,

Thanks, cheers,

Brian

--

Description

IAB Thoughts on IPv6 Network Address Translation (RFC 5902) Evolution of the IP Model (RFC 6250) Smart Objects Workshop Report (RFC 6574) Architectural Considerations of IP Anycast (RFC 7094)

---

From: Brian Trammell <[email-masked]>
Date: Thu, 11 Jun 2015 21:43:40 +0200

Greetings, all,

One more pass, reflecting comments from yesterday, adding 7305 and including a placeholder for text we don't have yet: new reference 5 to work on stacks on constrained devices (also discussed at the London retreat, thanks Ralph for reminding me of this, and thanks in advance for providing said text ;) )

Once we have this, I think we're done. Thanks, everyone!

Cheers,

Brian

Description

(5) Architectural guidance on the creation of new protocol stacks for constrained devices [Erik and Ralph to provide text to flesh this out].

(6) Architectural guidance for stack evolution should be informed by empirical evidence where possible and appropriate, so the program encourages efforts to collect, disseminate, and analyze data pertaining to the present state of the Internet with respect to its other activities. Work here currently focuses on the potential establishment of an IRTF research group to coordinate measurement of path transparency issues caused by middleboxes, following on the HOPS ("How Ossified is the Protocol Stack") Bar BoF at IETF 92 in Dallas. Discussion of this work occurs on the HOPS mailing list: [email-masked]

(7) Architectural guidance on traffic filtering and blocking, to result in the publication of draft-iab-filtering-considerations.

Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) (RFC 7305)

---

From: Aaron Falk <[email-masked]>
Date: Fri, 26 Jun 2015 16:24:30 -0400

Hey Brian-

I've just been reading draft-iab-semi-report-00 and the new StackEvo
webpage.  The report suggests followon work of giving advice to middlebox
implementors but there appears to be no mention of it in the StackEvo
description.  Did this get lost on the cutting room floor? Or was it a
deliberate omission?

6.3. Guidelines for middlebox design and deployment

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.

--aaron

On Thu, Jun 11, 2015 at 3:43 PM, Brian Trammell <[email-masked]> wrote:

> Greetings, all,
>
> One more pass, reflecting comments from yesterday, adding 7305 and
> including a placeholder for text we don't have yet: new reference 5 to work
> on stacks on constrained devices (also discussed at the London retreat,
> thanks Ralph for reminding me of this, and thanks in advance for providing
> said text ;) )
>
> The IP Stack Evolution program covers various topics in the evolution of
> IPv4 and IPv6, the transport protocols running over IP, and the overall
> protocol stack architecture. The program addresses challenges that affect
> the stack in some way and where the IETF community requires architectural
> guidance, responding to community requests as well as actively monitoring
> work within IETF WGs which touch on relevant topics.
>
> There is an observed trend of functionality moving “up the stack”: where
> the “waist” was once IP, now most applications run over TCP/IP, or even
> HTTP/TCP/IP; the stack has become increasingly ossified. This is in
> response both to reduced path transparency within the Internet —
> middleboxes that limit the protocols of the traffic that can pass through
> them — as well as insufficiently flexible interfaces for platform and
> application developers. The emergence of both new application requirements
> demanding more flexibility from the stack, especially at layer 4, as well
> as the increasing ubiquity of encryption to protect against pervasive
> surveillance, provides an opportunity to re-evaluate and reverse this trend.
>
> This program aims to provide architectural guidance, and a point of
> coordination for work at the architectural level to improve the present
> situation of ossification in the Internet protocol stack. Where a working
> group relevant to a particular aspect of IP stack evolution exists, the
> program will facilitate cross-group and cross-area coordination. The
> program also produces documents on the IAB stream providing general
> guidance on and covering architectural aspects of stack evolution.
>
> (1) Definition of requirements and principles for encapsulation-based
> approaches to work around path transparency issues and to allow explicit
> cooperation between endpoints and devices on path, while cryptographically
> protecting information which should remain end-to-end (including transport
> headers). This work follows discussions at the IAB SEMI (Stack Evolution in
> a Middlebox Internet) workshop and the SPUD (Substrate Protocol for User
> Datagrams) BoF at IETF 92 in Dallas. Discussion of this work occurs on the
> SPUD mailing list: [email-masked].
>
> (2) Evolution of interfaces to transport and network-layer services:
> improving the access of applications to the specific transport services
> they need (e.g. reliability, latency guarantees, congestion control
> properties, message boundary and order preservation, etc.) beyond the
> traditional SOCK_STREAM and SOCK_DGRAM interfaces. Further architectural
> work in this space awaits the results of related engineering being done in
> the IETF TAPS Working Group (mailing list: [email-masked]), the activities
> of which the program monitors.
>
> (3) Discussion of principles for making new protocols within the IP stack
> deployable, following in part on RFC 5218 "What Makes for a Successful
> Protocol".
>
> (4) Definition of principles for the use of encapsulation at various
> layers within the protocol stack. UDP-based encapsulations are not only
> useful for evolution above the IP layer, but in many tunneling contexts as
> well. The probable commonalities among all these applications of
> encapsulation might be useful in simplifying their implementation,
> deployment, and use.
>
> (5) Architectural guidance on the creation of new protocol stacks for
> constrained devices [Erik and Ralph to provide text to flesh this out].
>
> (6) Architectural guidance for stack evolution should be informed by
> empirical evidence where possible and appropriate, so the program
> encourages efforts to collect, disseminate, and analyze data pertaining to
> the present state of the Internet with respect to its other activities.
> Work here currently focuses on the potential establishment of an IRTF
> research group to coordinate measurement of path transparency issues caused
> by middleboxes, following on the HOPS ("How Ossified is the Protocol
> Stack") Bar BoF at IETF 92 in Dallas. Discussion of this work occurs on the
> HOPS mailing list: [email-masked]
>
> (7) Architectural guidance on traffic filtering and blocking, to result in
> the publication of draft-iab-filtering-considerations.
>
>
> This program has itself evolved from the IP Evolution Program, which
> looked at general architectural issues in the evolution of IPv4 and IPv6
> and the overall protocol stack architecture, and produced the following
> documents:
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>
>