Subject: [Stackevo] New writeup for Stack Evolution program on the IAB site

From: Brian Trammell <[email-masked]>
Date: Thu, 4 Jun 2015 13:10:19 +0200

Greetings, all,

Following SEMI, the SPUD BoF and followup calls, and discussions at the IAB retreat in London, I've reworked the description of the program for the IAB webpage, specifically in the active work section.

Please let me know if there's anything here that's missing, or could be said better.

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. 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. This program aims to provide guidance to improve this situation.

Where a working group relevant to a particular aspect of IP stack evolution exists, program participants work within that working group, both contributing to engineering work on Internet-Drafts as well as facilitating 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. Current work is proceeding within the IETF TAPS (Transport Services) working group: [email-masked].

(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.

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: Aaron Falk <[email-masked]>
Date: Thu, 4 Jun 2015 14:44:27 -0400

LIke it.  You might put a reference to the work being informed by
measurement and encouraging Internet measurement activities that will be
helpful to the other topics listed.

--aaron

On Thu, Jun 4, 2015 at 7:10 AM, Brian Trammell <[email-masked]> wrote:

> Greetings, all,
>
> Following SEMI, the SPUD BoF and followup calls, and discussions at the
> IAB retreat in London, I've reworked the description of the program for the
> IAB webpage, specifically in the active work section.
>
> 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. 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. This program aims to provide guidance
> to improve this situation.
>
> Where a working group relevant to a particular aspect of IP stack
> evolution exists, program participants work within that working group, both
> contributing to engineering work on Internet-Drafts as well as facilitating
> 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. Current work is
> proceeding within the IETF TAPS (Transport Services) working group:
> [email-masked].
>
> (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.
>
> 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
>
>

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 5 Jun 2015 15:58:26 -0400

Hi Brian,

I like this….not to gild the lily, but does it make sense to also mention the increasingly common use of encryption at multiple layers in the second paragraph, as one of the factors pushing relevant functionality up the stack?

Suzanne

On Jun 4, 2015, at 2:44 PM, Aaron Falk <[email-masked]> wrote:

> LIke it.  You might put a reference to the work being informed by measurement and encouraging Internet measurement activities that will be helpful to the other topics listed.
> 
> --aaron
>

---

From: Brian Trammell <[email-masked]>
Date: Sun, 7 Jun 2015 00:17:34 +0200

hi Suzanne, Aaron, all,

> On 05 Jun 2015, at 21:58, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi Brian,
> 
> 

Yep. In a larger sense we should note the synergy between this work and the privsec work; the structure of this writeup dates to before that was as obvious (to me, at least) as it is post-SEMI.

>> LIke it.  You might put a reference to the work being informed by measurement and encouraging Internet measurement activities that will be helpful to the other topics listed.

Good point.

Taking both of these comments and generating appropriate verbiage for each, we're left with:

Description

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 an IETF working group or IRTF research group relevant to a particular aspect of IP stack evolution exists, program participants work within that group, both contributing to engineering work on Internet-Drafts as well as facilitating 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.

(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 a 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]

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2015 02:12:40 +0000

Mostly good.  A couple suggestions below with [DT]

On Thu, Jun 4, 2015 at 7:10 AM, Brian Trammell <[email-masked]<mailto:[email-masked]>> wrote:
Greetings, all,

Thanks, cheers,

Brian

Description

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. 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. This program aims to provide guidance to improve this situation.

Where a working group relevant to a particular aspect of IP stack evolution exists, program participants work within that working group, both contributing to engineering work on Internet-Drafts as well as facilitating cross-group and cross-area coordination.
[DT] Since participants working in WGs do so as individuals not as official program members per se, I'd suggest rewording the above sentence as:
"Where a working group relevant to a particular aspect of IP stack evolution exists, the program will simply 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]<mailto:[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. Current work is proceeding within the IETF TAPS (Transport Services) working group: [email-masked]<mailto:[email-masked]>.
[DT] Above makes it sound like TAPS is a subset of the program, which it isn't.   That is "Current work" _of the program_ is not proceeding within TAPS.  Need to find a way to reword.   Maybe something like "The program will monitor the work of the IETF TAPS (Transport Services) working group."

(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.
[DT] What's missing from the list of "current active work" above is the filtering-considerations document that Erik and I are working on.

_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

---

From: Brian Trammell <[email-masked]>
Date: Wed, 10 Jun 2015 09:06:44 +0200

Hi Dave,

Thanks! Will address these, comment-comments inline...

Sent from my iPhone

> On 10 Jun 2015, at 04:12, Dave Thaler <[email-masked]> wrote:
> 
> [DT] Since participants working in WGs do so as individuals not as official program members per se, I’d suggest rewording the above sentence as:
> 
> “Where a working group relevant to a particular aspect of IP stack evolution exists, the program will simply facilitate cross-group and cross-area coordination.”
> 
Yep.
> [DT] Above makes it sound like TAPS is a subset of the program, which it isn’t.   That is “Current work” _of the program_ is not proceeding within TAPS.  Need to find a way to reword.   Maybe something like “The program will monitor the work of the IETF TAPS (Transport Services) working group.”
> 
This language is left over from the time before taps was chartered where it still wasn't clear how much alignment there would be. I do think we want to capture that the program has a interest in interface evolution separate from (but currently very much aligned with) the specific vision developing in taps...

Perhaps "this work is aligned with the current charter of the taps working group, which the program is monitoring, and where program members contribute on this topic"?

> [DT] What’s missing from the list of “current active work” above is the filtering-considerations document that Erik and I are working on.
> 
Yep. Knew I was missing something from the London list... Thanks!

Updated text to follow when I get my hands on a keyboard...

Cheers, Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2015 14:39:21 +0000

[…]

[DT] My point is that “program members” (per se) don’t contribute on the topic, individuals do, but not with an official “program member” hat on as such.   So I don’t like the “where program members contribute on this topic” phrase.

-Dave

---

From: Brian Trammell <[email-masked]>
Date: Wed, 10 Jun 2015 16:57:20 +0200

> On 10 Jun 2015, at 16:39, Dave Thaler <[email-masked]> wrote:
> 
> […]
> 

Okay, let's try something different then:

(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.

Cheers,

Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2015 14:58:00 +0000

I like that.

Dave

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 7:57 AM
To: Dave Thaler
Cc: Aaron Falk; Stackevo; Suzanne Woolf; IAB Board
Subject: Re: [Stackevo] [IAB] New writeup for Stack Evolution program on the IAB site

Cheers,

Brian