draft-ietf-taps-arch-14.txt   draft-ietf-taps-arch-15.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: 31 March 2023 Google Switzerland GmbH Expires: 23 April 2023 Google Switzerland GmbH
A. Brunstrom A. Brunstrom
Karlstad University Karlstad University
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
C. Perkins C. Perkins
University of Glasgow University of Glasgow
27 September 2022 20 October 2022
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-14 draft-ietf-taps-arch-15
Abstract Abstract
This document describes an architecture for exposing transport This document describes an architecture for exposing transport
protocol features to applications for network communication, a protocol features to applications for network communication, a
Transport Services system. The Transport Services Application Transport Services system. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. This API uses messages for representing data interaction pattern. This API uses messages for representing data
transfer to applications, and describes how implementations can use transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and multiple IP addresses, multiple protocols, and multiple paths, and
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 March 2023. This Internet-Draft will expire on 23 April 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 8, line 22 skipping to change at page 8, line 22
interactions with the Transport Services API that are not directly interactions with the Transport Services API that are not directly
related to events on the network or network interfaces. related to events on the network or network interfaces.
2.2. Data Transfer Using Messages 2.2. Data Transfer Using Messages
The Socket API provides a message interface for datagram protocols The Socket API provides a message interface for datagram protocols
like UDP, but provides an unstructured stream abstraction for TCP. like UDP, but provides an unstructured stream abstraction for TCP.
While TCP has the ability to send and receive data as a byte-stream, While TCP has the ability to send and receive data as a byte-stream,
most applications need to interpret structure within this byte- most applications need to interpret structure within this byte-
stream. For example, HTTP/1.1 uses character delimiters to segment stream. For example, HTTP/1.1 uses character delimiters to segment
messages over a byte-stream [RFC7230]; TLS record headers carry a messages over a byte-stream [RFC9112]; TLS record headers carry a
version, content type, and length [RFC8446]; and HTTP/2 uses frames version, content type, and length [RFC8446]; and HTTP/2 uses frames
to segment its headers and bodies [RFC7540]. to segment its headers and bodies [RFC9113].
The Transport Services API represents data as messages, so that it The Transport Services API represents data as messages, so that it
more closely matches the way applications use the network. Providing more closely matches the way applications use the network. Providing
a message-based abstraction provides many benefits, such as: a message-based abstraction provides many benefits, such as:
* the ability to associate deadlines with messages, for applications * the ability to associate deadlines with messages, for applications
that care about timing; that care about timing;
* the ability to control reliability, which messages to retransmit * the ability to control reliability, which messages to retransmit
when there is packet loss, and how best to make use of the data when there is packet loss, and how best to make use of the data
skipping to change at page 19, line 34 skipping to change at page 19, line 34
connection from that endpoint. The process of identifying options connection from that endpoint. The process of identifying options
for the connection, such as resolution of the Remote Endpoint, for the connection, such as resolution of the Remote Endpoint,
occurs in response to the Rendezvous call. As with Listeners, the occurs in response to the Rendezvous call. As with Listeners, the
set of local paths and endpoints is constrained by Selection set of local paths and endpoints is constrained by Selection
Properties. If successful, the Rendezvous call returns a Properties. If successful, the Rendezvous call returns a
Connection object to represent the established peer-to-peer Connection object to represent the established peer-to-peer
connection. The processes by which connections are initiated connection. The processes by which connections are initiated
during a Rendezvous action will depend on the set of Local and during a Rendezvous action will depend on the set of Local and
Remote Endpoints configured on the Preconnection. For example, if Remote Endpoints configured on the Preconnection. For example, if
the Local and Remote Endpoints are TCP host candidates, then a TCP the Local and Remote Endpoints are TCP host candidates, then a TCP
simultaneous open [RFC0793] will be performed. However, if the simultaneous open [RFC9293] will be performed. However, if the
set of Local Endpoints includes server reflexive candidates, such set of Local Endpoints includes server reflexive candidates, such
as those provided by STUN, a Rendezvous action will race as those provided by STUN, a Rendezvous action will race
candidates in the style of the ICE algorithm [RFC8445] to perform candidates in the style of the ICE algorithm [RFC8445] to perform
NAT binding discovery and initiate a peer-to-peer connection. NAT binding discovery and initiate a peer-to-peer connection.
4.1.5. Data Transfer Objects and Actions 4.1.5. Data Transfer Objects and Actions
* Message: A Message object is a unit of data that can be * Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two endpoints represented as bytes that can be transferred between two endpoints
over a transport connection. The bytes within a Message are over a transport connection. The bytes within a Message are
skipping to change at page 26, line 32 skipping to change at page 26, line 32
both co-authors of this architecture specification as it progressed both co-authors of this architecture specification as it progressed
through the TAPS working group. Thanks as well to Stuart Cheshire, through the TAPS working group. Thanks as well to Stuart Cheshire,
Josh Graessley, David Schinazi, and Eric Kinnear for their Josh Graessley, David Schinazi, and Eric Kinnear for their
implementation and design efforts, including Happy Eyeballs, that implementation and design efforts, including Happy Eyeballs, that
heavily influenced this work. heavily influenced this work.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
K├╝hlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
"An Abstract Application Layer Interface to Transport
Services", Work in Progress, Internet-Draft, draft-ietf-
taps-interface-17, 27 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
interface-17>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and
M. Welzl, "Implementing Interfaces to Transport Services", M. Welzl, "Implementing Interfaces to Transport Services",
Work in Progress, Internet-Draft, draft-ietf-taps-impl-13, Work in Progress, Internet-Draft, draft-ietf-taps-impl-13,
31 August 2022, <https://datatracker.ietf.org/doc/html/ 31 August 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-taps-impl-13>. draft-ietf-taps-impl-13>.
[I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
K├╝hlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
"An Abstract Application Layer Interface to Transport
Services", Work in Progress, Internet-Draft, draft-ietf-
taps-interface-17, 27 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps-
interface-17>.
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open -- Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7", group Technical Standard: Base Specifications, Issue 7",
2008. 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/rfc/rfc793>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/rfc/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/rfc/rfc8095>. <https://www.rfc-editor.org/rfc/rfc8095>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/rfc/rfc8305>. <https://www.rfc-editor.org/rfc/rfc8305>.
skipping to change at page 28, line 19 skipping to change at page 28, line 5
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction between Security Wood, "A Survey of the Interaction between Security
Protocols and Transport Services", RFC 8922, Protocols and Transport Services", RFC 8922,
DOI 10.17487/RFC8922, October 2020, DOI 10.17487/RFC8922, October 2020,
<https://www.rfc-editor.org/rfc/rfc8922>. <https://www.rfc-editor.org/rfc/rfc8922>.
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/rfc/rfc8923>. October 2020, <https://www.rfc-editor.org/rfc/rfc8923>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
Authors' Addresses Authors' Addresses
Tommy Pauly (editor) Tommy Pauly (editor)
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
Brian Trammell (editor) Brian Trammell (editor)
 End of changes. 12 change blocks. 
30 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/