< draft-ietf-taps-arch-03.txt   draft-ietf-taps-arch-04.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: September 12, 2019 Google Expires: January 9, 2020 Google
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
P. Tiesel P. Tiesel
TU Berlin TU Berlin
C. Wood C. Wood
Apple Inc. Apple Inc.
March 11, 2019 July 08, 2019
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-03 draft-ietf-taps-arch-04
Abstract Abstract
This document provides an overview of the architecture of Transport This document provides an overview of the architecture of Transport
Services, a model for exposing transport protocol features to Services, a model for exposing transport protocol features to
applications for network communication. In contrast to what is applications for network communication. In contrast to what is
provided by most existing Application Programming Interfaces (APIs), provided by most existing Application Programming Interfaces (APIs),
Transport Services is based on an asynchronous, event-driven Transport Services is based on an asynchronous, event-driven
interaction pattern; it uses messages for representing data transfer interaction pattern; it uses messages for representing data transfer
to applications; and it assumes an implementation that can use to applications; and it assumes an implementation that can use
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 28 skipping to change at page 6, line 28
o the ability to provide control of reliability, choosing which o the ability to provide control of reliability, choosing which
messages to retransmit in the event of packet loss, and how best messages to retransmit in the event of packet loss, and how best
to make use of the data that arrived; to make use of the data that arrived;
o the ability to manage dependencies between messages, when the o the ability to manage dependencies between messages, when the
transport system could decide to not deliver a message, either transport system could decide to not deliver a message, either
following packet loss or because it has missed a deadline. In following packet loss or because it has missed a deadline. In
particular, this can avoid (re-)sending data that relies on a particular, this can avoid (re-)sending data that relies on a
previous transmission that was never received. previous transmission that was never received.
o the ability to automatically assign messages and connections to
underlaying transport connections to utilize multi-streaming and
pooled connections.
Allowing applications to interact with messages is backwards- Allowing applications to interact with messages is backwards-
compatible with existings protocols and APIs, as it does not change compatible with existings protocols and APIs, as it does not change
the wire format of any protocol. Instead, it gives the protocol the wire format of any protocol. Instead, it gives the protocol
stack additional information to allow it to make better use of modern stack additional information to allow it to make better use of modern
transport services, while simplifying the application's role in transport services, while simplifying the application's role in
parsing data. parsing data.
1.4. Flexibile Implementation 1.4. Flexibile Implementation
Sockets, for protocols like TCP, are generally limited to connecting Sockets, for protocols like TCP, are generally limited to connecting
skipping to change at page 14, line 10 skipping to change at page 14, line 10
* Transport Properties: Transport Properties can be specified as * Transport Properties: Transport Properties can be specified as
part of a Preconnection to allow the application to configure part of a Preconnection to allow the application to configure
the Transport System and express their requirements, the Transport System and express their requirements,
prohibitions, and preferences. There are three kinds of prohibitions, and preferences. There are three kinds of
Transport Properties: Selection Properties (Section 4.1.2), Transport Properties: Selection Properties (Section 4.1.2),
Connection Properties (Section 4.1.2), and Message Properties Connection Properties (Section 4.1.2), and Message Properties
(Section 4.1.4). Message Properties can also be specified (Section 4.1.4). Message Properties can also be specified
during data transfer to affect specific Messages. during data transfer to affect specific Messages.
o Connection: A Connection object represents an active transport o Connection: A Connection object represents one or more active
protocol instance that can send and/or receive Messages between transport protocol instances that can send and/or receive Messages
local and remote systems. It holds state pertaining to the between local and remote systems. It holds state pertaining to
underlying transport protocol instance and any ongoing data the underlying transport protocol instances and any ongoing data
transfer. This represents, for example, an active connection in a transfers. This represents, for example, an active connection in
connection-oriented protocol such as TCP, or a fully-specified a connection-oriented protocol such as TCP, or a fully-specified
5-tuple for a connectionless protocol such as UDP. 5-tuple for a connectionless protocol such as UDP. It can also
represent a pool of transport protocol instance, e.g., a set of
TCP and QUIC connections to equivalent endpoints, or a stream of a
multi-streaming transport protocol instance.
o Listener: A Listener object accepts incoming transport protocol o Listener: A Listener object accepts incoming transport protocol
connections from remote systems and generates corresponding connections from remote systems and generates corresponding
Connection objects. It is created from a Preconnection object Connection objects. It is created from a Preconnection object
that specifies the type of incoming connections it will accept. that specifies the type of incoming connections it will accept.
4.1.2. Pre-Establishment 4.1.2. Pre-Establishment
o Endpoint: An Endpoint represents an identifier for one side of a o Endpoint: An Endpoint represents an identifier for one side of a
transport connection. Endpoints can be Local Endpoints or Remote transport connection. Endpoints can be Local Endpoints or Remote
skipping to change at page 23, line 11 skipping to change at page 23, line 11
Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric
Kinnear for their implementation and design efforts, including Happy Kinnear for their implementation and design efforts, including Happy
Eyeballs, that heavily influenced this work. Eyeballs, that heavily influenced this work.
8. Informative References 8. Informative References
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Jones, T., Tiesel, P., Perkins, C., and M. Welzl, Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", draft- "Implementing Interfaces to Transport Services", draft-
ietf-taps-impl-02 (work in progress), October 2018. ietf-taps-impl-03 (work in progress), March 2019.
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
Abstract Application Layer Interface to Transport Abstract Application Layer Interface to Transport
Services", draft-ietf-taps-interface-02 (work in Services", draft-ietf-taps-interface-03 (work in
progress), October 2018. progress), March 2019.
[I-D.ietf-taps-minset] [I-D.ietf-taps-minset]
Welzl, M. and S. Gjessing, "A Minimal Set of Transport Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", draft-ietf-taps-minset-11 (work Services for End Systems", draft-ietf-taps-minset-11 (work
in progress), September 2018. in progress), September 2018.
[I-D.ietf-taps-transport-security] [I-D.ietf-taps-transport-security]
Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K.
Rose, "A Survey of Transport Security Protocols", draft- Rose, "A Survey of Transport Security Protocols", draft-
ietf-taps-transport-security-06 (work in progress), March ietf-taps-transport-security-06 (work in progress), March
skipping to change at page 25, line 31 skipping to change at page 25, line 31
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Philipp S. Tiesel Philipp S. Tiesel
TU Berlin TU Berlin
Marchstrasse 23 Einsteinufer 25
10587 Berlin 10587 Berlin
Germany Germany
Email: philipp@inet.tu-berlin.de Email: philipp@tiesel.net
Chris Wood Chris Wood
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: cawood@apple.com Email: cawood@apple.com
 End of changes. 10 change blocks. 
16 lines changed or deleted 23 lines changed or added

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