| XMPP Working Group | B. Trammell |
| Internet-Draft | ETH Zurich |
| Intended status: Informational | M. Thomson |
| Expires: December 17, 2017 | Mozilla |
| L. Howard | |
| Retevia | |
| T. Hardie | |
| June 15, 2017 |
What Is an Endpoint?
draft-trammell-whats-an-endpoint-latest
what is an endpoint
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
“Architectural Principles of the Internet” [RFC1958] states:
It is also generally felt that end-to-end functions can best be realised by end-to-end protocols.
This is an articulation of the end-to-end argument [Saltzer84], which pervades the architecture of the Internet, and is a key differentiator between the Internet architecture and the architectures of electronic communications networks that came before it, and the architectures of some networks over which Internet access is provided. It is often referred to in shorthand in the IETF as “smart endpoints, dumb middles”.
We observe that this principle can only be applied, however, when one has agreement on what an endpoint is. Early in the design of the Internet, this agreement was relatively obvious: a network-layer endpoint was synonymous with a host, and a transport-layer endpoint was synonymous with a process running on a host.
The architecture of the Internet is necessarily descriptive. It should be as simple as possible but not simpler. Changes in the Internet through several decades of development and changing deployment models requires re-evaluating assumptions, including those of simplicity. This draft aims to rectify the proposes a generalized definition of an endpoint, then explores how it can be applied to understanding the architecture of the Internet, specifically [EDITOR’S NOTE: list controversies here].
[EDITOR’S NOTE: go ted go]
One reading of the relevant standards is that an endpoint is defined to be synonymous with a host in [RFC1122], and is taken to be anything that meets the requirements specified therein…
[EDITOR’S NOTE: This is from Brian’s message.]
An endpoint is a necessarily-stateful interface between “the network” (for some definition of “the network”) and the entity the network provides communication on behalf of (a user, an application, a device, a service, etc.) This entity is associated with some identity (which may be cryptographically verifiable) and some intent to communicate with some other endpoint(s).
[EDITOR’S NOTE: This is from Lee’s Montreal commit. We should take elements of one or both of these and turn it into the snappy one-liner. Lee’s current one-liner is snappier but I think too restricted…]
From these specific definitions, one can generalize to the statement: An endpoint is that function that identifies itself as the target of communication.
[EDITOR’S NOTE: Introduce subsections]
[EDITOR’S NOTE: Aaron’s comment on the March thread]
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.
[EDITOR’S NOTE: from Lee’s commit]
an application endpoint is the process that receives communication from an application and begins processing it. A network endpoint is the process (or more loosely, a device) that receives a network packet and processes it. A security endpoint is the process that responds to communication about security.
Implications of “transport endpoint” being different than “application endpoint” being different from “security identity”
IoT, Server clusters. Application process != host
To the app, the other end is maybe a hostname, or maybe a process, or maybe a socket API.
But the layered architecture is a strength. You shouldn’t care about the other end, as long as you can rely on the system when you hand off to the next layer.
Is it as simple as saying, “The L3 endpoint is one thing, the L4 endpoint is another thing, . . . the L7 endpoint is another thing.” And if so, the L8 endpoint?
[EDITOR’S NOTE: Eliot’s comment from the March thread]
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.
[EDITOR’S NOTE: from Natasha]
An endpoint is the closest element to the actor in a use case.
[EDITOR’S NOTE: from Joe]
An endpoint either initiates network communications or acts as the intended target for such initiations… 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.
[EDITOR’S NOTE: from Gabriel]
An endpoint is a participant in a semantic dialog.
[EDITOR’S NOTE: This is from Ted’s comment on the 14.6. IAB call. Clean this up a bit.]
The cooperative middlebox, if you have a split server where the server is doing some of the work at the front and some at a series of backends. Might be as far in as the thing that serves the actual data. In QUIC you have this model where if you try and say the end points are talking to each other, you’re collapsing a bunch of cooperative systems into something called an end point. But we’ve traditionally thought of services as client to server or endpoint to endpoint, but that may be too simple. Some of the endpoint people in the IOT space may not see the mirroring, so I think the 00 will be useful for saying this is happening at both ends.
write me
write me
write me
write me
| [RFC1122] | Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989. |
| [RFC1958] | Carpenter, B., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996. |
| [Saltzer84] | Saltzer, J., Reed, D. and D. Clark, "End-to-end arguments in system design (in ACM TOCS 2(4))", November 1984. |