Subject: [Stackevo] Draft IP Stack Evolution Program Program Description

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 27 Mar 2017 23:16:45 +0200

Greetings, all,

Thanks to everyone for the interesting conversation this afternoon; for
my part I came in with not very much idea how to scope what we want to
do going forward (and thanks to Ted for throwing together a slide deck
at the last minute and at great expense to make up for my inability to
figure out how to get started)...

It seems to me a good way forward for the program is to move its current
agenda on transport ossification and to "monitoring" mode -- as it has
largely moved to the TSV area -- and to ponder, Zen-like, the question:
"what is an endpoint?" There are a lot of questions packed into that
one, including some that IMO will be easier to grapple with when phrased
this way.

So with this message, I'd like to ask two things.

First, I'd like everyone to have a look at the three paragraphs below,
as an initial suggestion for our new program description. I tried to
capture the new question, and the change in our focus with respect to
the ossification agenda.

Second, I'd like everyone to send a short answer to the question "what
is an endpoint, and why is this question interesting?" to see what falls
out of trying to think of challenges for the IP stack in terms of who,
exactly, it is we're trying to connect with the Internet. (I'd start,
but it's late...)

Thanks, and good night,

Brian (program lead hammock)

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

The diversity of "endpoints" in the Internet -- applications,
transport-layer ports, hosts, gateways and tunnel ends -- is far greater
than that the IP protocol stack was originally intended to serve. This
has impacts on protocol design, because narrow assumptions about the
properties of these endpoints may not hold. The program is currently
focusing on the stress this places on the architecture.

The program has focused for the past few years on the problem of
ossification in the IP protocol stack, specifically at the transport
layer. Since the founding of this program, there is significant new work
in the IETF's transport area addressing this issue; the program's
members participate in work in the IETF, and monitor it on behalf of the
IAB, with an eye toward architectural oversight. The program also
provides a point of contact on architectural issues arising from
interaction between these new transport protocols and the rising
diversity of link layers deployed in the Internet.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Mar 2017 16:41:23 -0500

Hi,

> exactly, it is we're trying to connect with the Internet. (I'd start,

An endpoint consists of a set of components bound together through a
single identity, through which those components are controlled.  It's an
interesting question because the means by which an endpoint may
communicate with others will vary, and most of our work focuses on
interfaces with IP addresses being endpoints.

Eliot

---

From: Natasha Rooney <[email-masked]>
Date: Mon, 27 Mar 2017 22:59:56 +0000

This is a tough one, I thought about using the words “person", “system", or making a number of cases to support IoT and traditional user/provider cases, but nowadays I really think it’s as broad as...

"An endpoint is the closest element to the actor in a use case."

Not sure about the use of the word “element”, I’ll think on whether to change it for another. I like Elliot’s use of “identity” as well, I perhaps should include this in some way.

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On 27 Mar 2017, at 16:16, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:

Greetings, all,

Thanks, and good night,

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

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: "Aaron Falk" <[email-masked]>
Date: Tue, 28 Mar 2017 00:08:25 -0500

> capture the new question, and the change in our focus with respect to

Only one initial comment….

> properties of these endpoints may not hold.

suggest

“…because -former- assumptions about the properties of these 
elements may -no longer- hold”

Ie, this is an effort to reflect that the world has changed.  There was 
an [Internet design 
principal](http://www.isi.edu/~braden/myfiles/umass.talk.pdf) 
paraphrasing ‘make the architecture as simple as possible but not 
simpler’ and the world changing requires re-evaluating assumptions 
including those of simplicity.

> exactly, it is we're trying to connect with the Internet. (I'd start,

It’s late here too :) because that’s when email gets attended to.

An endpoint is where application state lives.  For lower layer 
protocols, the Internet is generally in service to applications, to hand 
data to an application is to hand it to an endpoint.  What makes this 
interesting is that our prioritization of trust issues has changed, the 
technologies hosting applications have become more distributed (in the 
peripheral, rack, and cloud senses), and the notion that if one 
sub-element of an application endpoint fails, the rest of the 
application endpoint sub-elements will know (aka fate sharing) may no 
longer be valid.

—aaron

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 28 Mar 2017 09:52:55 +0200

Good morning, Stackevo,

I have two answers to my first question: one which attempts to take a strict IP-network-centric view (which is in turn informed by my continued and ever more steadfast belief that the stack is missing a layer), and one from a hopefully broader perspective. I think I believe both at once, a superposition made possible by caffeination -- one of the *disadvantages* of remote participation is while I can shift my own schedule to Central Daylight, I have so far been unsuccessful in convincing Callista, or more importantly for scheduling purposes her daycare, to do so... *yawn*...

I also tried not to look at others' answers; I'll reply to those in other threads.

(1) An endpoint in the IP architecture is a logical entity connected to an IP network which is the initial sender or final recipient of a transport-layer packet, bound to some logical identity (service/service-agent or user-agent).

In the (pre-virtualization-containerization) UNIX model of distributed computing, and endpoint is bound to a single process. I say "initial/final" here because I regard the lack of encryption on transport layer headers to be a historical accident, and the participation of non-endpoints at this layer to be an exploit of that accident. In this view, there's nothing architecturally special about tunnel endpoints their application just happens to be packet-encapsulation as opposed to encapsulation of other less ethereal things, like pictures of cats. Same with gateways, nothing special about them either: they're just IP endpoints which happen to be back-to-backed with other non-IP endpoints -- the end-to-endness happens above the layer where "the Internet architecture" should care.

I like this definition because it is nicely self-contained, but I'm not sure it has much predictive power in helping us see how IP will be evolved by fitness functions beyond those which are strictly technical and network-centered. Hence:

(2) An endpoint is a logical identity (service/service-agent and/or user-agent) or set of identities associated with a single party, engaged in a specific two-to-N party intent to communicate.

Here, it's the identity (which we presume is authenticated, whether through a third-party certificate or via good old TOFU -- we explicitly don't inherit the accident of non-authenticatible peers here) and the intent which are important. This is a little rough... I'm not quite sure how tunnels fit into this view, but application layer gateways are either treated as endpoints or as forwarding devices based on (1) whether they represent the intent to communicate, or that intent is delegated to devices behind them and (2) whether the devices behind them have separable identities (which in the IoT space, is usually the result of a business model question).

Why is this question interesting? In the small, it's obviously interesting to me if I can write that many words about it while basically still asleep. In the large, because I think the spaces between the multiple answers will help us reason about how the demands on the Internet by the applications using it are shaping the architecture.

Cheers,

Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 28 Mar 2017 11:08:40 +0200

hi Aaron,

> On 28 Mar 2017, at 07:08, Aaron Falk <[email-masked]> wrote:
> 
> “…because -former- assumptions about the properties of these elements may -no longer- hold”
> 
> Ie, this is an effort to reflect that the world has changed. There was an Internet design principal paraphrasing ‘make the architecture as simple as possible but not simpler’ and the world changing requires re-evaluating assumptions including those of simplicity.

Yep. (And that second sentence belongs in the what-is-an-endpoint draft...)

It turns out we've had a stackevo group on github for a while, so I've got a working copy of this up in https://github.com/stackevo/administrivia. Ping me with your github ID if you'd like an invite.

Cheers,

Brian

---

From: Lee Howard <[email-masked]>
Date: Tue, 28 Mar 2017 08:38:24 -0500

Replying before I read everyone else¹s comments.

>one, including some that IMO will be easier to grapple with when phrased

Yes.

btw, I¹ve always thought we havea dichotomy between hosts and nodes, and
that dichotomy is blurring in StackEvoly interesting ways.

>exactly, it is we're trying to connect with the Internet. (I'd start,

An endpoint is the point at which the header for a layer is added or
removed.
By that formulation, we have Ethernet endpoints, where the fragments have
Ethernet headers added or removed. Ditto Wi-Fi, etc.
We have IP endpoints. It would be interesting to argue that NATs are
endpoints, because they strip the IP headers (or counter-argue that they
don¹t, since they just change the address, but I think most end up
replacing the header, even if they reuse some values from the original
header).
The TCP endpoint may on the same machine as the IP endpoint.
The HTTPS endpoint might be a load balancer process.
The HTML endpoint could be a front end web server (daemon?).

A host is a device that is an endpoint for the full stack.
A node is a device that is only L1-L2 endpoint.
A middlebox is, therefore, any endpoint L3-7 endpoint.
I include L7 because I can¹t figure out how to articulate the difference
between a L7 firewall, L7 proxy, and a front-end server that initiates
connections and processes to other servers on behalf of a use process.

I reran the above definition against the 4-layer model, and found I had
more endpoints than layers.

Hmm, not sure I met the requirement of a ³short answer."

>protocol stack architecture.

That sentence doesn¹t say much. ³program covers various topics in
everything."

>The program addresses challenges that

< because narrow
> because of narrow

>focusing on the stress this places on the architecture.

Or maybe
< because narrow. . .
> because of outdated assumptions that all of these endpoints exist within
>the same machinery, under single administrative control, working
>cooperatively.

>diversity of link layers deployed in the Internet.

Works for me.

Lee

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Mar 2017 10:24:25 -0500

> focusing on the stress this places on the architecture.
I think the third paragraph here sounds a bit odd.  Suggested edit below

> layer. There is now significant new work in the IETF's transport area
> addressing this issue.  The program's members participate in the work in
> the IETF and will provide a point of contact should architectural issues
> arise from interactions between these new transport protocols and the
> diverse of link layers deployed in the Internet.
>
>

 "what is an endpoint, and why is this question interesting?

A network endpoint is the element which sends and receives communications
in a particular exchange.  The question is interesting because the network
endpoint for one exchange may be quite different from the endpoint in other
exchanges that include some of  same network interfaces.  So the network
endpoint for security updates may be a component of the network endpoint
for 6lo packet trains and both may be different from the network endpoint
for an application exchange.

Ted

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 28 Mar 2017 18:03:11 +0200

> On 28 Mar 2017, at 17:24, Ted Hardie <[email-masked]> wrote:
> 
> On Mon, Mar 27, 2017 at 4:16 PM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> 
> layer. There is now significant new work in the IETF's transport area addressing this issue.  The program's members participate in the work in the IETF and will provide a point of contact should architectural issues arise from interactions between these new transport protocols and the  diverse of link layers deployed in the Internet.
> 

Yeah, that's better. In the working copy, thanks!

Cheers,

Brian

> A network endpoint is the element which sends and receives communications in a particular exchange.  The question is interesting because the network endpoint for one exchange may be quite different from the endpoint in other exchanges that include some of  same network interfaces.  So the network endpoint for security updates may be a component of the network endpoint for 6lo packet trains and both may be different from the network endpoint for an application exchange.
> 
> Ted
> [email-masked]

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 28 Mar 2017 11:55:02 -0500

> On Mar 28, 2017, at 8:38 AM, Lee Howard <[email-masked]> wrote:
> 

I'm not convinced of that just yet.  If you're just adding a layer, you're clearly not at the end.  How about:

An endpoint either initiates network communications or acts as the intended target for such initiations.

— 
Joe Hildebrand

---

From: Robert Sparks <[email-masked]>
Date: Tue, 28 Mar 2017 13:14:44 -0500

Responding to bits of the thread already (and not providing specifically 
what Brian asked for yet) -

Eliot mentioned identity - Joe and Lee talked a bit about stack layers. 
Both thoughts are good to apply when analyzing the impact of the 
pervasive deployment of things like SIP B2BUAs on what you want to label 
as an endpoint.

RjS

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 28 Mar 2017 14:04:19 -0500

> On Mar 28, 2017, at 1:14 PM, Robert Sparks <[email-masked]> wrote:
> 
> Responding to bits of the thread already (and not providing specifically what Brian asked for yet) -
> 
> Eliot mentioned identity - Joe and Lee talked a bit about stack layers. Both thoughts are good to apply when analyzing the impact of the pervasive deployment of things like SIP B2BUAs on what you want to label as an endpoint.

My read would be:
If the initiator knowingly chose to use a b2bua based on configuration or discovery, then I'd say it was an endpoint.  If it was something the path injected into the flow without user or user-agent awareness, it's not an endpoint.  I think intent of the UA is interesting (Lee's message notwithstanding: I'm still thinking about it too.)

— 
Joe Hildebrand

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 29 Mar 2017 06:20:11 +0000

An endpoint is an entity is a participant in a semantic dialog.

> -----Original Message-----
> From: Stackevo [mailto:[email-masked]] On Behalf Of Brian
> Trammell (IETF)
> Sent: Monday, March 27, 2017 16:17
> To: [email-masked]
> Subject: [Stackevo] Draft IP Stack Evolution Program Program Description
> 
> Greetings, all,
> 
> Thanks to everyone for the interesting conversation this afternoon; for my
> part I came in with not very much idea how to scope what we want to do
> going forward (and thanks to Ted for throwing together a slide deck at the
> last minute and at great expense to make up for my inability to figure out
> how to get started)...
> 
> agenda on transport ossification and to "monitoring" mode -- as it has largely
> moved to the TSV area -- and to ponder, Zen-like, the question:
> "what is an endpoint?" There are a lot of questions packed into that one,
> including some that IMO will be easier to grapple with when phrased this
> way.
> 
> First, I'd like everyone to have a look at the three paragraphs below, as an
> initial suggestion for our new program description. I tried to capture the new
> question, and the change in our focus with respect to the ossification agenda.
> 
> Second, I'd like everyone to send a short answer to the question "what is an
> endpoint, and why is this question interesting?" to see what falls out of trying
> to think of challenges for the IP stack in terms of who, exactly, it is we're
> trying to connect with the Internet. (I'd start, but it's late...)
> 
> Thanks, and good night,
> 
> 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.
> 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.
> 
> The diversity of "endpoints" in the Internet -- applications, transport-layer
> ports, hosts, gateways and tunnel ends -- is far greater than that the IP
> protocol stack was originally intended to serve. This has impacts on protocol
> design, because narrow assumptions about the properties of these
> endpoints may not hold. The program is currently focusing on the stress this
> places on the architecture.
> 
> ossification in the IP protocol stack, specifically at the transport layer. Since
> the founding of this program, there is significant new work in the IETF's
> transport area addressing this issue; the program's members participate in
> work in the IETF, and monitor it on behalf of the IAB, with an eye toward
> architectural oversight. The program also provides a point of contact on
> architectural issues arising from interaction between these new transport
> protocols and the rising diversity of link layers deployed in the Internet.
>