draft-ietf-taps-arch-01.txt   draft-ietf-taps-arch-02.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: January 2, 2019 ETH Zurich Expires: April 25, 2019 ETH Zurich
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.
July 01, 2018 October 22, 2018
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-01 draft-ietf-taps-arch-02
Abstract Abstract
This document provides an overview of the architecture of Transport This document provides an overview of the architecture of Transport
Services, a system for exposing the features of transport protocols Services, a system for exposing the features of transport protocols
to applications. This architecture serves as a basis for Application to applications. This architecture serves as a basis for Application
Programming Interfaces (APIs) and implementations that provide Programming Interfaces (APIs) and implementations that provide
flexible transport networking services. It defines the common set of flexible transport networking services. It defines the common set of
terminology and concepts to be used in more detailed discussion of terminology and concepts to be used in more detailed discussion of
Transport Services. Transport Services.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 January 2, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Event-Driven API . . . . . . . . . . . . . . . . . . . . 5
3.1. Common APIs for Common Features . . . . . . . . . . . . . 4 1.3. Data Transfer Using Messages . . . . . . . . . . . . . . 5
3.2. Access to Specialized Features . . . . . . . . . . . . . 4 1.4. Flexibile Implementation . . . . . . . . . . . . . . . . 6
3.3. Scope for API and Implementation Definitions . . . . . . 5 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Transport Services Architecture and Concepts . . . . . . . . 6 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Transport Services API Concepts . . . . . . . . . . . . . 7 3.1. Common APIs for Common Features . . . . . . . . . . . . . 7
4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 9 3.2. Access to Specialized Features . . . . . . . . . . . . . 7
4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 10 3.3. Scope for API and Implementation Definitions . . . . . . 8
4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 11 4. Transport Services Architecture and Concepts . . . . . . . . 9
4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 11 4.1. Transport Services API Concepts . . . . . . . . . . . . . 10
4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 12 4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 12
4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 13 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 13
4.2. Transport System Implementation Concepts . . . . . . . . 13 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 14
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 14 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 14
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 14 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 15
4.3. Protocol Stack Equivalence . . . . . . . . . . . . . . . 15 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 16
4.3.1. Transport Security Equivalence . . . . . . . . . . . 16 4.2. Transport System Implementation Concepts . . . . . . . . 16
4.4. Message Framing, Parsing, and Serialization . . . . . . . 16 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4.3. Protocol Stack Equivalence . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Transport Security Equivalence . . . . . . . . . . . 19
8. Informative References . . . . . . . . . . . . . . . . . . . 18 4.4. Message Framing, Parsing, and Serialization . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Many APIs to perform transport networking have been deployed, perhaps Many application programming interfaces (APIs) to perform transport
the most widely known and imitated being the BSD socket() [POSIX] networking have been deployed, perhaps the most widely known and
interface. The names and functions between these APIs are not imitated being the BSD socket() [POSIX] interface. The names and
consistent, and vary depending on the protocol being used. For functions between these APIs are not consistent, and vary depending
example, sending and receiving on a stream of data is conceptually on the protocol being used. For example, sending and receiving on a
the same between operating on an unencrypted Transmission Control stream of data is conceptually the same between operating on an
Protocol (TCP) stream and operating on an encrypted Transport Layer unencrypted Transmission Control Protocol (TCP) stream and operating
Security (TLS) [I-D.ietf-tls-tls13] stream over TCP, but applications on an encrypted Transport Layer Security (TLS) [I-D.ietf-tls-tls13]
cannot use the same socket send() and recv() calls on top of both stream over TCP, but applications cannot use the same socket send()
kinds of connections. Similarly, terminology for the implementation and recv() calls on top of both kinds of connections. Similarly,
of protocols offering transport services vary based on the context of terminology for the implementation of protocols offering transport
the protocols themselves. This variety can lead to confusion when services vary based on the context of the protocols themselves. This
trying to understand the similarities and differences between variety can lead to confusion when trying to understand the
protocols, and how applications can use them effectively. similarities and differences between protocols, and how applications
can use them effectively.
The goal of the Transport Services architecture is to provide a The goal of the Transport Services architecture is to provide a
common, flexible, and reusable interface for transport protocols. As common, flexible, and reusable interface for transport protocols. As
applications adopt this interface, they will benefit from a wide set applications adopt this interface, they will benefit from a wide set
of transport features that can evolve over time, and ensure that the of transport features that can evolve over time, and ensure that the
system providing the interface can optimize its behavior based on the system providing the interface can optimize its behavior based on the
application requirements and network conditions. application requirements and network conditions.
This document is developed in parallel with the specification of the This document is developed in parallel with the specification of the
Transport Services API [I-D.ietf-taps-interface] and Implementation Transport Services API [I-D.ietf-taps-interface] and Implementation
[I-D.ietf-taps-impl] documents. [I-D.ietf-taps-impl] documents.
1.1. Overview
The model for using sockets for networking can be represented as
follows: applications create connections and transfer data using the
socket API, which provides the interface to the implementations of
UDP and TCP (typically implemented in the system's kernel), which in
turn send data over the available network layer interfaces.
+-----------------------------------------------------+
| Application |
+-----------------------------------------------------+
| |
+---------------------+ +-----------------------+
| Socket Stream API | | Socket Datagram API |
+---------------------+ +-----------------------+
| |
+-----------------------------------------------------+
| TCP UDP |
| Kernel Protocol Implementation |
+-----------------------------------------------------+
|
+-----------------------------------------------------+
| Network Layer Interface |
+-----------------------------------------------------+
The Transport Services architecture maintains this general model of
interaction, but aims to both modernize the API surface exposed for
transport protocols and enrich the capabilities of the transport
system implementation.
+-----------------------------------------------------+
| Application |
+-----------------------------------------------------+
|
+-----------------------------------------------------+
| Transport Services API |
+-----------------------------------------------------+
|
+-----------------------------------------------------+
| Transport System Implementation |
| (UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) |
+-----------------------------------------------------+
|
+-----------------------------------------------------+
| Network Layer Interface |
+-----------------------------------------------------+
The Transport Services API [I-D.ietf-taps-interface] defines the
mechanism for an application to create and monitor network
connections, and transfer data. The Implementation
[I-D.ietf-taps-impl] is responsible for mapping the API into the
various available transport protocols and managing the available
network interfaces and paths.
There are a few key departures that Transport Services makes from the
sockets API: it presents an asynchronous, event-driven API; it uses
messages for respresenting data transfer to applications; and it
assumes an implementation that can use multiple IP addresses,
multiple protocols, multiple paths, and provide multiple application
streams.
1.2. Event-Driven API
Originally, sockets presented a blocking interface for establishing
connections and transferring data. However, most modern applications
interact with the network asynchronously. When sockets are presented
as an asynchronous interface, they generally use a try-and-fail
model. If the application wants to read, but data has not yet been
received from the peer, the call to read will fail. The application
then waits for a notification that it should try again.
All interaction with a Transport Services system is expected to be
asynchronous, and use an event-driven model unlike sockets
Section 4.1.5. For example, if the application wants to read, its
call to read will not fail, but will deliver an event containing the
received data once it is available.
The Transport Services API also delivers events regarding the
lifetime of a connection and changes to available network links,
which were not previously made explicit in sockets.
Using asynchronous events allows for a much simpler interaction model
when establishing connections and transferring data. Events in time
more closely reflect the nature of interactions over networks, as
opposed to how sockets represent network resources as file system
objects that may be temporarily unavailable.
1.3. Data Transfer Using Messages
Sockets provide a message interface for datagram protocols like UDP,
but provide an unstructured stream abstraction for TCP. While TCP
does indeed provide the ability to send and receive data as streams,
most applications need to interpret structure within these streams.
HTTP/1.1 uses character delimiters to segment messages over a stream;
TLS record headers carry a version, content type, and length; and
HTTP/2 uses frames to segment its headers and bodies.
In order to more closely match the way applications use the network,
the Transport Services API respresents data as messages. Messages
seamlessly work with transport protocols that support datagrams or
records, but can also be used over a stream by defining the
application-layer framing being used Section 4.4.
1.4. Flexibile Implementation
Sockets, for protocols like TCP, are generally limited to connecting
to a single address over a single interface. They also present a
single stream to the application. Software layers built upon sockets
often propagate this limitation of a single-address single-stream
model. The Transport Services architecture is designed to handle
multiple candidate endpoints, protocols, and paths; and support
multipath and multistreaming protocols.
Transport Services implementations are meant to be flexible at
connection establishment time, considering many different options and
trying to select the most optimal combinations (Section 4.2.1 and
Section 4.2.2). This requires applications to provide higher-level
endpoints than IP addresses, such as hostnames and URLs, which are
used by a Transport Services implementation for resolution, path
selection, and racing.
Flexibility after connection establishment is also important.
Transport protocols that can migrate between multiple network layer
interfaces need to be able to process and react to interface changes.
Protocols that support multiple application-layer streams need to
support initiating and receiving new streams using existing
connections.
2. Background 2. Background
The Transport Services architecture is based on the survey of The Transport Services architecture is based on the survey of
Services Provided by IETF Transport Protocols and Congestion Control Services Provided by IETF Transport Protocols and Congestion Control
Mechanisms [RFC8095], and the distilled minimal set of the features Mechanisms [RFC8095], and the distilled minimal set of the features
offered by transport protocols [I-D.ietf-taps-minset]. This work has offered by transport protocols [I-D.ietf-taps-minset]. This work has
identified common features and patterns across all transport identified common features and patterns across all transport
protocols developed thus far in the IETF. protocols developed thus far in the IETF.
Since transport security is an increasingly relevant aspect of using Since transport security is an increasingly relevant aspect of using
skipping to change at page 4, line 22 skipping to change at page 7, line 24
interface between applications and transports in a way that allows interface between applications and transports in a way that allows
the transport layer to evolve and improve without fundamentally the transport layer to evolve and improve without fundamentally
changing the contract with the application. This requires a careful changing the contract with the application. This requires a careful
consideration of how to expose the capabilities of protocols. consideration of how to expose the capabilities of protocols.
There are several degrees in which a Transport Services system can There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features, it can use these multiple sets of protocols and protocol features, it can use these
protocols across multiple paths that may have different performance protocols across multiple paths that may have different performance
and functional characteristics, and it can communicate with different and functional characteristics, and it can communicate with different
Remote Endpoints to optimize performance. Beyond these, if the API Remote Endpoints to optimize performance, robustness to failure, or
for the system remains the same over time, new protocols and features some other metric. Beyond these, if the API for the system remains
may be added to the system's implementation without requiring changes the same over time, new protocols and features may be added to the
in applications for adoption. system's implementation without requiring changes in applications for
adoption.
The following considerations were used in the design of this The following considerations were used in the design of this
architecture. architecture.
3.1. Common APIs for Common Features 3.1. Common APIs for Common Features
Functionality that is common across multiple transport protocols Functionality that is common across multiple transport protocols
should be accessible through a unified set of API calls. An should be accessible through a unified set of API calls. An
application should be able to implement logic for its basic use of application should be able to implement logic for its basic use of
transport networking (establishing the transport, and sending and transport networking (establishing the transport, and sending and
receiving data) once, and expect that implementation to continue to receiving data) once, and expect that implementation to continue to
function as the transports change. function as the transports change.
Any Transport Services API must allow access to the distilled minimal Any Transport Services API must allow access to the distilled minimal
set of features offered by transport protocols set of features offered by transport protocols
[I-D.ietf-taps-minset]. [I-D.ietf-taps-minset].
3.2. Access to Specialized Features 3.2. Access to Specialized Features
Since applications will often need to control fine-grained details of There are applications that will need to control fine-grained details
transport protocols to optimize their behavior and ensure of transport protocols to optimize their behavior and ensure
compatibility with remote peers, a Transport Services system also compatibility with remote peers,. A Transport Services system will
needs to allow more specialized protocol features to be used. The therefore also needs to allow more specialized protocol features to
interface for these specialized options should be exposed differently be used. The interface for these specialized options should be
from the common options to ensure flexibility. exposed differently from the common options to ensure flexibility.
A specialized feature may be required by an application only when A specialized feature could be required by an application only when
using a specific protocol, and not when using others. For example, using a specific protocol, and not when using others. For example,
if an application is using UDP, it may require control over the if an application is using UDP, it could require control over the
checksum or fragmentation behavior for UDP; if it used a protocol to checksum or fragmentation behavior for UDP; if it used a protocol to
frame its data over a byte stream like TCP, it would not need these frame its data over a byte stream like TCP, it would not need these
options. In such cases, the API should expose the features in such a options. In such cases, the API should expose the features in such a
way that they take effect when a particular protocol is selected, but way that they take effect when a particular protocol is selected, but
do not imply that only that protocol may be used if there are do not imply that only that protocol could be used if there are
equivalent options. equivalent options.
Other specialized features, however, may be strictly required by an Other specialized features, however, may be strictly required by an
application and thus constrain the set of protocols that can be used. application and thus constrain the set of protocols that can be used.
For example, if an application requires encryption of its transport For example, if an application requires encryption of its transport
data, only protocol stacks that include some transport security data, only protocol stacks that include some transport security
protocol are eligible to be used. A Transport Services API must protocol are eligible to be used. A Transport Services API must
allow applications to define such requirements and constrain the allow applications to define such requirements and constrain the
system's options. Since such options are not part of the core/common system's options. Since such options are not part of the core/common
features, it should be simple for an application to modify its set of features, it should be simple for an application to modify its set of
skipping to change at page 5, line 45 skipping to change at page 8, line 47
[I-D.ietf-taps-impl] will vary due to system-specific support and the [I-D.ietf-taps-impl] will vary due to system-specific support and the
needs of the deployment scenario. It is expected that all needs of the deployment scenario. It is expected that all
implementations of Transport Services will offer the entire mandatory implementations of Transport Services will offer the entire mandatory
API, but that some features will not be functional in certain API, but that some features will not be functional in certain
implementations. All implementations must offer sufficient APIs to implementations. All implementations must offer sufficient APIs to
use the distilled minimal set of features offered by transport use the distilled minimal set of features offered by transport
protocols [I-D.ietf-taps-minset], including API support for TCP and protocols [I-D.ietf-taps-minset], including API support for TCP and
UDP transport, but it is possible that some very constrained devices UDP transport, but it is possible that some very constrained devices
might not have, for example, a full TCP implementation. might not have, for example, a full TCP implementation.
In order to preserve flexibility and compatibility with future To preserve flexibility and compatibility with future protocols, top-
protocols, top-level features in the Transport Services API should level features in the Transport Services API should avoid referencing
avoid referencing particular transport protocols. Mappings of these particular transport protocols. The mappings of these API features
API features in the Implementation document, on the other hand, must to specific implementations of each feature is explained in the
explain the ramifications of each feature on existing protocols. It [TAPS-IMPL], which also explain the implications of the feature
is expected that the Implementation document will be updated and provided by existing protocols. It is expected that this document
supplemented as new protocols and protocol features are developed. will be updated and supplemented as new protocols and protocol
features are developed.
It is important to note that neither the Transport Services API nor It is important to note that neither the Transport Services API nor
the Implementation document defines new protocols that require any the Implementation document defines new protocols that require any
changes on remote hosts. The Transport Services system must be changes to a remote host. The Transport Services system must be
deployable on one side only, as a way to allow an application to make deployable on one side only, as a way to allow an application to make
better use of available capabilities on a system and protocol better use of available capabilities on a system and protocol
features that may be supported by peers across the network. features that may be supported by peers across the network.
4. Transport Services Architecture and Concepts 4. Transport Services Architecture and Concepts
The concepts defined in this document are intended primarily for use The concepts defined in this document are intended primarily for use
in the documents and specifications that describe the Transport in the documents and specifications that describe the Transport
Services architecture and API. While the specific terminology may be Services architecture and API. While the specific terminology may be
used in some implementations, it is expected that there will remain a used in some implementations, it is expected that there will remain a
skipping to change at page 18, line 36 skipping to change at page 21, line 36
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-00 (work in progress), May 2018. ietf-taps-impl-01 (work in progress), July 2018.
[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-00 (work in Services", draft-ietf-taps-interface-01 (work in
progress), April 2018. progress), July 2018.
[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-04 (work Services for End Systems", draft-ietf-taps-minset-11 (work
in progress), June 2018. in progress), September 2018.
[I-D.ietf-taps-transport-security] [I-D.ietf-taps-transport-security]
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
of Transport Security Protocols", draft-ietf-taps- of Transport Security Protocols", draft-ietf-taps-
transport-security-02 (work in progress), June 2018. transport-security-02 (work in progress), June 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
skipping to change at page 19, line 43 skipping to change at page 22, line 43
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[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/info/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[TAPS-IMPL]
Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Jones, T., Tiesel, P., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", draft-
ietf-taps-impl-01 (work in progress), July 2018.
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)
ETH Zurich ETH Zurich
Gloriastrasse 35 Gloriastrasse 35
8092 Zurich 8092 Zurich
Switzerland Switzerland
Email: ietf@trammell.ch Email: ietf@trammell.ch
Anna Brunstrom Anna Brunstrom
Karlstad University Karlstad University
 End of changes. 19 change blocks. 
70 lines changed or deleted 212 lines changed or added

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