draft-ietf-taps-impl-02.txt   draft-ietf-taps-impl-03.txt 
TAPS Working Group A. Brunstrom, Ed. TAPS Working Group A. Brunstrom, Ed.
Internet-Draft Karlstad University Internet-Draft Karlstad University
Intended status: Informational T. Pauly, Ed. Intended status: Informational T. Pauly, Ed.
Expires: April 25, 2019 Apple Inc. Expires: September 12, 2019 Apple Inc.
T. Enghardt T. Enghardt
TU Berlin TU Berlin
K-J. Grinnemo K-J. Grinnemo
Karlstad University Karlstad University
T. Jones T. Jones
University of Aberdeen University of Aberdeen
P. Tiesel P. Tiesel
TU Berlin TU Berlin
C. Perkins C. Perkins
University of Glasgow University of Glasgow
M. Welzl M. Welzl
University of Oslo University of Oslo
October 22, 2018 March 11, 2019
Implementing Interfaces to Transport Services Implementing Interfaces to Transport Services
draft-ietf-taps-impl-02 draft-ietf-taps-impl-03
Abstract Abstract
The Transport Services architecture [I-D.ietf-taps-arch] defines a The Transport Services architecture [I-D.ietf-taps-arch] defines a
system that allows applications to use transport networking protocols system that allows applications to use transport networking protocols
flexibly. This document serves as a guide to implementation on how flexibly. This document serves as a guide to implementation on how
to build such a system. to build such a system.
Status of This Memo Status of This Memo
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 April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementing Basic Objects . . . . . . . . . . . . . . . . . 3 2. Implementing Basic Objects . . . . . . . . . . . . . . . . . 3
3. Implementing Pre-Establishment . . . . . . . . . . . . . . . 4 3. Implementing Pre-Establishment . . . . . . . . . . . . . . . 4
3.1. Configuration-time errors . . . . . . . . . . . . . . . . 4 3.1. Configuration-time errors . . . . . . . . . . . . . . . . 5
3.2. Role of system policy . . . . . . . . . . . . . . . . . . 5 3.2. Role of system policy . . . . . . . . . . . . . . . . . . 5
4. Implementing Connection Establishment . . . . . . . . . . . . 6 4. Implementing Connection Establishment . . . . . . . . . . . . 6
4.1. Candidate Gathering . . . . . . . . . . . . . . . . . . . 7 4.1. Candidate Gathering . . . . . . . . . . . . . . . . . . . 7
4.1.1. Structuring Options as a Tree . . . . . . . . . . . . 7 4.1.1. Structuring Options as a Tree . . . . . . . . . . . . 7
4.1.2. Branch Types . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Branch Types . . . . . . . . . . . . . . . . . . . . 9
4.2. Branching Order-of-Operations . . . . . . . . . . . . . . 11 4.2. Branching Order-of-Operations . . . . . . . . . . . . . . 11
4.3. Sorting Branches . . . . . . . . . . . . . . . . . . . . 12 4.3. Sorting Branches . . . . . . . . . . . . . . . . . . . . 12
4.4. Candidate Racing . . . . . . . . . . . . . . . . . . . . 13 4.4. Candidate Racing . . . . . . . . . . . . . . . . . . . . 13
4.4.1. Delayed Racing . . . . . . . . . . . . . . . . . . . 14 4.4.1. Delayed . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.2. Failover . . . . . . . . . . . . . . . . . . . . . . 15 4.4.2. Failover . . . . . . . . . . . . . . . . . . . . . . 15
4.5. Completing Establishment . . . . . . . . . . . . . . . . 15 4.5. Completing Establishment . . . . . . . . . . . . . . . . 15
4.5.1. Determining Successful Establishment . . . . . . . . 16 4.5.1. Determining Successful Establishment . . . . . . . . 16
4.6. Establishing multiplexed connections . . . . . . . . . . 17 4.6. Establishing multiplexed connections . . . . . . . . . . 17
4.7. Handling racing with "unconnected" protocols . . . . . . 17 4.7. Handling racing with "unconnected" protocols . . . . . . 17
4.8. Implementing listeners . . . . . . . . . . . . . . . . . 18 4.8. Implementing listeners . . . . . . . . . . . . . . . . . 18
4.8.1. Implementing listeners for Connected Protocols . . . 18 4.8.1. Implementing listeners for Connected Protocols . . . 18
4.8.2. Implementing listeners for Unconnected Protocols . . 18 4.8.2. Implementing listeners for Unconnected Protocols . . 18
4.8.3. Implementing listeners for Multiplexed Protocols . . 19 4.8.3. Implementing listeners for Multiplexed Protocols . . 18
5. Implementing Data Transfer . . . . . . . . . . . . . . . . . 19 5. Implementing Data Transfer . . . . . . . . . . . . . . . . . 19
5.1. Data transfer for streams, datagrams, and frames . . . . 19 5.1. Data transfer for streams, datagrams, and frames . . . . 19
5.1.1. Sending Messages . . . . . . . . . . . . . . . . . . 19 5.1.1. Sending Messages . . . . . . . . . . . . . . . . . . 19
5.1.2. Receiving Messages . . . . . . . . . . . . . . . . . 21 5.1.2. Receiving Messages . . . . . . . . . . . . . . . . . 21
5.2. Handling of data for fast-open protocols . . . . . . . . 22 5.2. Handling of data for fast-open protocols . . . . . . . . 22
6. Implementing Maintenance . . . . . . . . . . . . . . . . . . 23 6. Implementing Maintenance . . . . . . . . . . . . . . . . . . 23
6.1. Changing Protocol Properties . . . . . . . . . . . . . . 23 6.1. Managing Connections . . . . . . . . . . . . . . . . . . 23
6.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 24 6.2. Handling Path Changes . . . . . . . . . . . . . . . . . . 24
7. Implementing Termination . . . . . . . . . . . . . . . . . . 24 7. Implementing Termination . . . . . . . . . . . . . . . . . . 24
8. Cached State . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Cached State . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Protocol state caches . . . . . . . . . . . . . . . . . . 25 8.1. Protocol state caches . . . . . . . . . . . . . . . . . . 26
8.2. Performance caches . . . . . . . . . . . . . . . . . . . 26 8.2. Performance caches . . . . . . . . . . . . . . . . . . . 26
9. Specific Transport Protocol Considerations . . . . . . . . . 27 9. Specific Transport Protocol Considerations . . . . . . . . . 27
9.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.5. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.5. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.6. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.6. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.7. HTTP/2 transport . . . . . . . . . . . . . . . . . . . . 29 9.7. HTTP/2 transport . . . . . . . . . . . . . . . . . . . . 30
10. Rendezvous and Environment Discovery . . . . . . . . . . . . 30 10. Rendezvous and Environment Discovery . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12.1. Considerations for Candidate Gathering . . . . . . . . . 32 12.1. Considerations for Candidate Gathering . . . . . . . . . 32
12.2. Considerations for Candidate Racing . . . . . . . . . . 32 12.2. Considerations for Candidate Racing . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 33 14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 34 14.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Additional Properties . . . . . . . . . . . . . . . 34 Appendix A. Additional Properties . . . . . . . . . . . . . . . 35
A.1. Properties Affecting Sorting of Branches . . . . . . . . 35 A.1. Properties Affecting Sorting of Branches . . . . . . . . 35
A.2. Send Parameters . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The Transport Services architecture [I-D.ietf-taps-arch] defines a The Transport Services architecture [I-D.ietf-taps-arch] defines a
system that allows applications to use transport networking protocols system that allows applications to use transport networking protocols
flexibly. The interface such a system exposes to applications is flexibly. The interface such a system exposes to applications is
defined as the Transport Services API [I-D.ietf-taps-interface]. defined as the Transport Services API [I-D.ietf-taps-interface].
This API is designed to be generic across multiple transport This API is designed to be generic across multiple transport
protocols and sets of protocols features. protocols and sets of protocols features.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
stream, or an HTTP/2 stream. stream, or an HTTP/2 stream.
Listener objects are created with a Preconnection, at which point Listener objects are created with a Preconnection, at which point
their configuration should be considered immutable by the their configuration should be considered immutable by the
implementation. The process of listening is described in implementation. The process of listening is described in
Section 4.8. Section 4.8.
3. Implementing Pre-Establishment 3. Implementing Pre-Establishment
During pre-establishment the application specifies the Endpoints to During pre-establishment the application specifies the Endpoints to
be used for communication as well as its preferences regarding be used for communication as well as its preferences via Selection
Protocol and Path Selection. The implementation stores these objects Properties and, if desired, also Connection Properties. Generally,
and properties as part of the Preconnection object for use during Connection Properties should be configured as early as possible, as
connection establishment. For Protocol and Path Selection Properties they may serve as input to decisions that are made by the
that are not provided by the application, the implementation must use implementation (the Capacity Profile may guide usage of a protocol
the default values specified in the Transport Services API offering scavenger-type congestion control, for example). In the
([I-D.ietf-taps-interface]). remainder of this document, we only refer to Selection Properties
because they are the more typical case and have to be handled by all
implementations.
The implementation stores these objects and properties as part of the
Preconnection object for use during connection establishment. For
Selection Properties that are not provided by the application, the
implementation must use the default values specified in the Transport
Services API ([I-D.ietf-taps-interface]).
3.1. Configuration-time errors 3.1. Configuration-time errors
The transport system should have a list of supported protocols The transport system should have a list of supported protocols
available, which each have transport features reflecting the available, which each have transport features reflecting the
capabilities of the protocol. Once an application specifies its capabilities of the protocol. Once an application specifies its
Transport Parameters, the transport system should match the required Transport Parameters, the transport system should match the required
and prohibited properties against the transport features of the and prohibited properties against the transport features of the
available protocols. available protocols.
skipping to change at page 5, line 30 skipping to change at page 5, line 39
"Configure Reliability per Message", this mismatch should result "Configure Reliability per Message", this mismatch should result
in an error. in an error.
It is important to fail as early as possible in such cases in order It is important to fail as early as possible in such cases in order
to avoid allocating resources, e.g., to endpoint resolution, only to to avoid allocating resources, e.g., to endpoint resolution, only to
find out later that there is no protocol that satisfies the find out later that there is no protocol that satisfies the
requirements. requirements.
3.2. Role of system policy 3.2. Role of system policy
The properties specified during pre-establishment has a close The properties specified during pre-establishment have a close
connection to system policy. The implementation is responsible for connection to system policy. The implementation is responsible for
combining and reconciling several different sources of preferences combining and reconciling several different sources of preferences
when establishing Connections. These include, but are not limited when establishing Connections. These include, but are not limited
to: to:
1. Application preferences, i.e., preferences specified during the 1. Application preferences, i.e., preferences specified during the
pre-establishment such as Local Endpoint, Remote Endpoint, Path pre-establishment via Selection Properties.
Selection Properties, and Protocol Selection Properties.
2. Dynamic system policy, i.e., policy compiled from internally and 2. Dynamic system policy, i.e., policy compiled from internally and
externally acquired information about available network externally acquired information about available network
interfaces, supported transport protocols, and current/previous interfaces, supported transport protocols, and current/previous
Connections. Examples of ways to externally retrieve policy- Connections. Examples of ways to externally retrieve policy-
support information are through OS-specific statistics/ support information are through OS-specific statistics/
measurement tools and tools that reside on middleboxes and measurement tools and tools that reside on middleboxes and
routers. routers.
3. Default implementation policy, i.e., predefined policy by OS or 3. Default implementation policy, i.e., predefined policy by OS or
skipping to change at page 7, line 32 skipping to change at page 7, line 38
Any one of these sub-entries on the aggregate connection attempt Any one of these sub-entries on the aggregate connection attempt
would satisfy the original application intent. The concern of this would satisfy the original application intent. The concern of this
section is the algorithm defining which of these options to try, section is the algorithm defining which of these options to try,
when, and in what order. when, and in what order.
4.1. Candidate Gathering 4.1. Candidate Gathering
The step of gathering candidates involves identifying which paths, The step of gathering candidates involves identifying which paths,
protocols, and endpoints may be used for a given Connection. This protocols, and endpoints may be used for a given Connection. This
list is determined by the requirements, prohibitions, and preferences list is determined by the requirements, prohibitions, and preferences
of the application as specified in the Path Selection Properties and of the application as specified in the Selection Properties.
Protocol Selection Properties.
4.1.1. Structuring Options as a Tree 4.1.1. Structuring Options as a Tree
When an implementation responsible for connection establishment needs When an implementation responsible for connection establishment needs
to consider multiple options, it should logically structure these to consider multiple options, it should logically structure these
options as a hierarchical tree. Each leaf node of the tree options as a hierarchical tree. Each leaf node of the tree
represents a single, coherent connection attempt, with an Endpoint, a represents a single, coherent connection attempt, with an Endpoint, a
Path, and a set of protocols that can directly negotiate and send Path, and a set of protocols that can directly negotiate and send
data on the network. Each node in the tree that is not a leaf data on the network. Each node in the tree that is not a leaf
represents a connection attempt that is either underspecified, or represents a connection attempt that is either underspecified, or
skipping to change at page 12, line 20 skipping to change at page 12, line 25
Furthermore, the protocol stacks being attempted may influence or Furthermore, the protocol stacks being attempted may influence or
altogether change the endpoints being used. Adding a proxy to a altogether change the endpoints being used. Adding a proxy to a
connection's branch will change the endpoint to the proxy's IP connection's branch will change the endpoint to the proxy's IP
address or hostname. Choosing an alternate protocol may also modify address or hostname. Choosing an alternate protocol may also modify
the ports that should be selected. the ports that should be selected.
Branching for derived endpoints is the final step, and may have Branching for derived endpoints is the final step, and may have
multiple layers of derivation or resolution, such as DNS service multiple layers of derivation or resolution, such as DNS service
resolution and DNS hostname resolution. resolution and DNS hostname resolution.
For example, if the application has indicated both a preference for
WiFi over LTE and for a feature only available in SCTP, branches will
be first sorted accord to path selection, with WiFi at the top.
Then, branches with SCTP will be sorted to the top within their
subtree according to the properties influencing protocol selection.
However, if the implementation has cached the information that SCTP
is not available on the path over WiFi, there is no SCTP node in the
WiFi subtree. Here, the path over WiFi will be tried first, and, if
connection establishment succeeds, TCP will be used. So the
Selection Property of preferring WiFi takes precedence over the
Property that led to a preference for SCTP.
1. [www.example.com:80, Any, Any Stream]
1.1 [192.0.2.1:80, Wi-Fi, Any Stream]
1.1.1 [192.0.2.1:80, Wi-Fi, TCP]
1.2 [192.0.3.1:80, LTE, Any Stream]
1.2.1 [192.0.3.1:80, LTE, SCTP]
1.2.2 [192.0.3.1:80, LTE, TCP]
4.3. Sorting Branches 4.3. Sorting Branches
Implementations should sort the branches of the tree of connection Implementations should sort the branches of the tree of connection
options in order of their preference rank. Leaf nodes on branches options in order of their preference rank. Leaf nodes on branches
with higher rankings represent connection attempts that will be raced with higher rankings represent connection attempts that will be raced
first. Implementations should order the branches to reflect the first. Implementations should order the branches to reflect the
preferences expressed by the application for its new connection, preferences expressed by the application for its new connection,
including Protocol and Path Selection Properties, which are specified including Selection Properties, which are specified in
in [I-D.ietf-taps-interface]. [I-D.ietf-taps-interface].
In addition to the properties provided by the application, an In addition to the properties provided by the application, an
implementation may include additional criteria such as cached implementation may include additional criteria such as cached
performance estimates, see Section 8.2, or system policy, see performance estimates, see Section 8.2, or system policy, see
Section 3.2, in the ranking. Two examples of how the Protocol and Section 3.2, in the ranking. Two examples of how Selection and
Path Selection Properties may be used to sort branches are provided Connection Properties may be used to sort branches are provided
below: below:
o Interface Type: If the application specifies an interface type to o "Interface Instance or Type": If the application specifies an
be preferred or avoided, implementations should rank paths interface type to be preferred or avoided, implementations should
accordingly. If the application specifies an interface type to be rank paths accordingly. If the application specifies an interface
required or prohibited, we expect an implementation to not include type to be required or prohibited, we expect an implementation to
the non-conforming paths into the three. not include the non-conforming paths into the three.
o Capacity Profile: An implementation may use the Capacity Profile o "Capacity Profile": An implementation may use the Capacity Profile
to prefer paths optimized for the application's expected traffic to prefer paths optimized for the application's expected traffic
pattern according to cached performance estimates, see pattern according to cached performance estimates, see
Section 8.2: Section 8.2:
* Interactive/Low Latency: Prefer paths with the lowest expected * Scavenger: Prefer paths with the highest expected available
Round Trip Time bandwidth, based on observed maximum throughput
* Constant Rate: Prefer paths that can satisfy the requested
Stream Send or Stream Receive Bitrate, based on observed
maximum throughput
* Scavenger/Bulk: Prefer paths with the highest expected * Low Latency/Interactive: Prefer paths with the lowest expected
available bandwidth, based on observed maximum throughput Round Trip Time
[Note: See Appendix A.1 for additional examples related to Properties * Constant-Rate Streaming: Prefer paths that can satisfy the
under discussion.] requested Stream Send or Stream Receive Bitrate, based on
observed maximum throughput
Implementations should process properties in the following order: Implementations should process properties in the following order:
Prohibit, Require, Prefer, Avoid. If Protocol or Path Selection Prohibit, Require, Prefer, Avoid. If Selection Properties contain
Properties contain any prohibited properties, the implementation any prohibited properties, the implementation should first purge
should first purge branches containing nodes with these properties. branches containing nodes with these properties. For required
For required properties, it should only keep branches that satisfy properties, it should only keep branches that satisfy these
these requirements. Finally, it should order branches according to requirements. Finally, it should order branches according to
preferred properties, and finally use avoided properties as a preferred properties, and finally use avoided properties as a
tiebreaker. tiebreaker.
For Require and Avoid, Path Selection Properties take precedence over
Protocol Selection Properties. For example, if the application has
indicated both a preference for WiFi over LTE and for a feature only
available in SCTP, branches will be first sorted accord to the Path
Selection Property, with WiFi at the top. Then, branches with SCTP
will be sorted to the top within their subtree according to the
Protocol Selection Property. However, if the implementation has
cached the information that SCTP is not available on the path over
WiFi, there is no SCTP node in the WiFi subtree. Here, the path over
WiFi will be tried first, and, if connection establishment succeeds,
TCP will be used. So the Path Selection Property of preferring WiFi
takes precedence over the Protocol Selection Property of preferring
SCTP.
1. [www.example.com:80, Any, Any Stream]
1.1 [192.0.2.1:80, Wi-Fi, Any Stream]
1.1.1 [192.0.2.1:80, Wi-Fi, TCP]
1.2 [192.0.3.1:80, LTE, Any Stream]
1.2.1 [192.0.3.1:80, LTE, SCTP]
1.2.2 [192.0.3.1:80, LTE, TCP]
4.4. Candidate Racing 4.4. Candidate Racing
The primary goal of the Candidate Racing process is to successfully The primary goal of the Candidate Racing process is to successfully
negotiate a protocol stack to an endpoint over an interface--to negotiate a protocol stack to an endpoint over an interface--to
connect a single leaf node of the tree--with as little delay and as connect a single leaf node of the tree--with as little delay and as
few unnecessary connections attempts as possible. Optimizing these few unnecessary connections attempts as possible. Optimizing these
two factors improves the user experience, while minimizing network two factors improves the user experience, while minimizing network
load. load.
This section covers the dynamic aspect of connection establishment. This section covers the dynamic aspect of connection establishment.
skipping to change at page 14, line 30 skipping to change at page 14, line 30
Each approach is appropriate in different use-cases and branch types. Each approach is appropriate in different use-cases and branch types.
However, to avoid consuming unnecessary network resources, However, to avoid consuming unnecessary network resources,
implementations should not use immediate racing as a default implementations should not use immediate racing as a default
approach. approach.
The timing algorithms for racing should remain independent across The timing algorithms for racing should remain independent across
branches of the tree. Any timers or racing logic is isolated to a branches of the tree. Any timers or racing logic is isolated to a
given parent node, and is not ordered precisely with regards to other given parent node, and is not ordered precisely with regards to other
children of other nodes. children of other nodes.
4.4.1. Delayed Racing 4.4.1. Delayed
Delayed racing can be used whenever a single node of the tree has Delayed racing can be used whenever a single node of the tree has
multiple child nodes. Based on the order determined when building multiple child nodes. Based on the order determined when building
the tree, the first child node will be initiated immediately, the tree, the first child node will be initiated immediately,
followed by the next child node after some delay. Once that second followed by the next child node after some delay. Once that second
child node is initiated, the third child node (if present) will begin child node is initiated, the third child node (if present) will begin
after another delay, and so on until all child nodes have been after another delay, and so on until all child nodes have been
initiated, or one of the child nodes successfully completes its initiated, or one of the child nodes successfully completes its
negotiation. negotiation.
skipping to change at page 18, line 12 skipping to change at page 18, line 12
Stack. This can be viewed as an application-driven form of Protocol Stack. This can be viewed as an application-driven form of Protocol
Stack racing. Stack racing.
4.8. Implementing listeners 4.8. Implementing listeners
When an implementation is asked to Listen, it registers with the When an implementation is asked to Listen, it registers with the
system to wait for incoming traffic to the Local Endpoint. If no system to wait for incoming traffic to the Local Endpoint. If no
Local Endpoint is specified, the implementation should either use an Local Endpoint is specified, the implementation should either use an
ephemeral port or generate an error. ephemeral port or generate an error.
If the Path Selection Properties do not require a single network If the Selection Properties do not require a single network interface
interface or path, but allow the use of multiple paths, the Listener or path, but allow the use of multiple paths, the Listener object
object should register for incoming traffic on all of the network should register for incoming traffic on all of the network interfaces
interfaces or paths that conform to the Path Selection Properties. or paths that conform to the Properties. The set of available paths
The set of available paths can change over time, so the can change over time, so the implementation should monitor network
implementation should monitor network path changes and register and path changes and register and de-register the Listener across all
de-register the Listener across all usable paths. When using usable paths. When using multiple paths, the Listener is generally
multiple paths, the Listener is generally expected to use the same expected to use the same port for listening on each.
port for listening on each.
If the Protocol Selection Properties allow multiple protocols to be If the Selection Properties allow multiple protocols to be used for
used for listening, and the implementation supports it, the Listener listening, and the implementation supports it, the Listener object
object should register across the eligble protocols for each path. should register across the eligble protocols for each path. This
This means that inbound Connections delivered by the implementation means that inbound Connections delivered by the implementation may
may have heterogeneous protocol stacks. have heterogeneous protocol stacks.
4.8.1. Implementing listeners for Connected Protocols 4.8.1. Implementing listeners for Connected Protocols
Connected protocols such as TCP and TLS-over-TCP have a strong Connected protocols such as TCP and TLS-over-TCP have a strong
mapping between the Local and Remote Endpoints (five-tuple) and their mapping between the Local and Remote Endpoints (five-tuple) and their
protocol connection state. These map well into Connection objects. protocol connection state. These map well into Connection objects.
Whenever a new inbound handshake is being started, the Listener Whenever a new inbound handshake is being started, the Listener
should generate a new Connection object and pass it to the should generate a new Connection object and pass it to the
application. application.
skipping to change at page 20, line 5 skipping to change at page 19, line 43
5.1.1. Sending Messages 5.1.1. Sending Messages
The effect of the application sending a Message is determined by the The effect of the application sending a Message is determined by the
top-level protocol in the established Protocol Stack. That is, if top-level protocol in the established Protocol Stack. That is, if
the top-level protocol provides an abstraction of framed messages the top-level protocol provides an abstraction of framed messages
over a connection, the receiving application will be able to obtain over a connection, the receiving application will be able to obtain
multiple Messages on that connection, even if the framing protocol is multiple Messages on that connection, even if the framing protocol is
built on a byte-stream protocol like TCP. built on a byte-stream protocol like TCP.
5.1.1.1. Send Parameters 5.1.1.1. Message Properties
o Lifetime: this should be implemented by removing the Message from o Lifetime: this should be implemented by removing the Message from
its queue of pending Messages after the Lifetime has expired. A its queue of pending Messages after the Lifetime has expired. A
queue of pending Messages within the transport system queue of pending Messages within the transport system
implementation that have yet to be handed to the Protocol Stack implementation that have yet to be handed to the Protocol Stack
can always support this property, but once a Message has been sent can always support this property, but once a Message has been sent
into the send buffer of a protocol, only certain protocols may into the send buffer of a protocol, only certain protocols may
support de-queueing a message. For example, TCP cannot remove support de-queueing a message. For example, TCP cannot remove
bytes from its send buffer, while in case of SCTP, such control bytes from its send buffer, while in case of SCTP, such control
over the SCTP send buffer can be exercised using the partial over the SCTP send buffer can be exercised using the partial
reliability extension [RFC8303]. When there is no standing queue reliability extension [RFC8303]. When there is no standing queue
of Messages within the system, and the Protocol Stack does not of Messages within the system, and the Protocol Stack does not
support removing a Message from its buffer, this property may be support removing a Message from its buffer, this property may be
ignored. ignored.
o Niceness: this represents the ability to de-prioritize a Message o Priority: this represents the ability to prioritize a Message over
in favor of other Messages. This can be implemented by the system other Messages. This can be implemented by the system re-ordering
re-ordering Messages that have yet to be handed to the Protocol Messages that have yet to be handed to the Protocol Stack, or by
Stack, or by giving relative priority hints to protocols that giving relative priority hints to protocols that support
support priorities per Message. For example, an implementation of priorities per Message. For example, an implementation of HTTP/2
HTTP/2 could choose to send Messages of different niceness on could choose to send Messages of different Priority on streams of
streams of different priority. different priority.
o Ordered: when this is false, it disables the requirement of in- o Ordered: when this is false, it disables the requirement of in-
order-delivery for protocols that support configurable ordering. order-delivery for protocols that support configurable ordering.
o Idempotent: when this is true, it means that the Message can be o Idempotent: when this is true, it means that the Message can be
used by mechanisms that might transfer it multiple times - e.g., used by mechanisms that might transfer it multiple times - e.g.,
as a result of racing multiple transports or as part of TCP Fast as a result of racing multiple transports or as part of TCP Fast
Open. Open.
o Final: when this is true, it means that a transport connection can
be closed immediately after its transmission.
o Corruption Protection Length: when this is set to any value other o Corruption Protection Length: when this is set to any value other
than -1, it limits the required checksum in protocols that allow than -1, it limits the required checksum in protocols that allow
limiting the checksum length (e.g. UDP-Lite). limiting the checksum length (e.g. UDP-Lite).
o Immediate Acknowledgement: this informs the implementation that o Transmission Profile: TBD - because it's not final in the API yet.
the sender intends to execute tight control over the send buffer, Old text follows: when this is set to "Interactive/Low Latency",
and therefore wants to avoid delayed acknowledgements. In case of the Message should be sent immediately, even when this comes at
SCTP, a request to immediately send acknowledgements can be the cost of using the network capacity less efficiently. For
implemented using the "sack-immediately flag" described in example, small messages can sometimes be bundled to fit into a
Section 4.2 of [RFC8303] for the SEND.SCTP primitive. single data packet for the sake of reducing header overhead; such
bundling should not be used. For example, in case of TCP, the
o Instantaneous Capacity Profile: when this is set to "Interactive/ Nagle algorithm should be disabled when Interactive/Low Latency is
Low Latency", the Message should be sent immediately, even when selected as the capacity profile. Scavenger/Bulk can translate
this comes at the cost of using the network capacity less into usage of a congestion control mechanism such as LEDBAT, and/
efficiently. For example, small messages can sometimes be bundled or the capacity profile can lead to a choice of a DSCP value as
to fit into a single data packet for the sake of reducing header described in [I-D.ietf-taps-minset]).
overhead; such bundling should not be used. For example, in case
of TCP, the Nagle algorithm should be disabled when Interactive/
Low Latency is selected as the capacity profile. Scavenger/Bulk
can translate into usage of a congestion control mechanism such as
LEDBAT, and/or the capacity profile can lead to a choice of a DSCP
value as described in [I-D.ietf-taps-minset]).
[Note: See also Appendix A.2 for additional Send Parameters under o Singular Transmission: when this is true, the application requests
discussion.] to avoid transport-layer segmentation or network-layer
fragmentation. Some transports implement network-layer
fragmentation avoidance (Path MTU Discovery) without exposing this
functionality to the application; in this case, only transport-
layer segmentation should be avoided, by fitting the message into
a single transport-layer segment or otherwise failing. Otherwise,
network-layer fragmentation should be avoided--e.g. by requesting
the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4
(SET_DF in [RFC8304]).
5.1.1.2. Send Completion 5.1.1.2. Send Completion
The application should be notified whenever a Message or partial The application should be notified whenever a Message or partial
Message has been consumed by the Protocol Stack, or has failed to Message has been consumed by the Protocol Stack, or has failed to
send. The meaning of the Message being consumed by the stack may send. The meaning of the Message being consumed by the stack may
vary depending on the protocol. For a basic datagram protocol like vary depending on the protocol. For a basic datagram protocol like
UDP, this may correspond to the time when the packet is sent into the UDP, this may correspond to the time when the packet is sent into the
interface driver. For a protocol that buffers data in queues, like interface driver. For a protocol that buffers data in queues, like
TCP, this may correspond to when the data has entered the send TCP, this may correspond to when the data has entered the send
skipping to change at page 22, line 17 skipping to change at page 22, line 14
If a Connection becomes finished before a requested Receive action If a Connection becomes finished before a requested Receive action
can be satisfied, the implementation should deliver any partial can be satisfied, the implementation should deliver any partial
Message content outstanding, or if none is available, an indication Message content outstanding, or if none is available, an indication
that there will be no more received Messages. that there will be no more received Messages.
5.2. Handling of data for fast-open protocols 5.2. Handling of data for fast-open protocols
Several protocols allow sending higher-level protocol or application Several protocols allow sending higher-level protocol or application
data within the first packet of their protocol establishment, such as data within the first packet of their protocol establishment, such as
TCP Fast Open [RFC7413] and TLS 1.3 [I-D.ietf-tls-tls13]. This TCP Fast Open [RFC7413] and TLS 1.3 [RFC8446]. This approach is
approach is referred to as sending Zero-RTT (0-RTT) data. This is a referred to as sending Zero-RTT (0-RTT) data. This is a desirable
desirable property, but poses challenges to an implementation that property, but poses challenges to an implementation that uses racing
uses racing during connection establishment. during connection establishment.
If the application has 0-RTT data to send in any protocol handshakes, If the application has 0-RTT data to send in any protocol handshakes,
it needs to provide this data before the handshakes have begun. When it needs to provide this data before the handshakes have begun. When
racing, this means that the data should be provided before the racing, this means that the data should be provided before the
process of connection establishment has begun. If the application process of connection establishment has begun. If the application
wants to send 0-RTT data, it must indicate this to the implementation wants to send 0-RTT data, it must indicate this to the implementation
by setting the Idempotent send parameter to true when sending the by setting the Idempotent send parameter to true when sending the
data. In general, 0-RTT data may be replayed (for example, if a TCP data. In general, 0-RTT data may be replayed (for example, if a TCP
SYN contains data, and the SYN is retransmitted, the data will be SYN contains data, and the SYN is retransmitted, the data will be
retransmitted as well), but racing means that different leaf nodes retransmitted as well), but racing means that different leaf nodes
skipping to change at page 23, line 13 skipping to change at page 23, line 11
attempt must use a different ticket. In effect, each leaf node will attempt must use a different ticket. In effect, each leaf node will
send the same early application data, yet encoded (encrypted) send the same early application data, yet encoded (encrypted)
differently on the wire. differently on the wire.
6. Implementing Maintenance 6. Implementing Maintenance
Maintenance encompasses changes that the application can request to a Maintenance encompasses changes that the application can request to a
Connection, or that a Connection can react to based on system and Connection, or that a Connection can react to based on system and
network changes. network changes.
6.1. Changing Protocol Properties 6.1. Managing Connections
Appendix A.1 of [I-D.ietf-taps-minset] explains, using primitives Appendix A.1 of [I-D.ietf-taps-minset] explains, using primitives
that are described in [RFC8303] and [RFC8304], how to implement from [RFC8303] and [RFC8304], how to implement changing some of the
changing the following protocol properties of an established following protocol properties of an established connection with TCP
connection with TCP and UDP. Below, we amend this description for and UDP. Below, we amend this description for other protocols (if
other protocols (if applicable): applicable) and extend it with Connection Properties that are not
contained in [I-D.ietf-taps-minset].
o Relative niceness: for SCTP, this can be done using the primitive
CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of
[RFC8303].
o Timeout for aborting Connection: for SCTP, this can be done using
the primitive CHANGE_TIMEOUT.SCTP described in section 4 of
[RFC8303].
o Abort timeout to suggest to the Remote Endpoint: for TCP, this can o Notification of excessive retransmissions: TODO
be done using the primitive CHANGE_TIMEOUT.TCP described in
section 4 of [RFC8303].
o Retransmission threshold before excessive retransmission o Retransmission threshold before excessive retransmission
notification: for TCP, this can be done using ERROR.TCP described notification: TODO; for TCP, this can be done using ERROR.TCP
in section 4 of [RFC8303]. described in section 4 of [RFC8303].
o Notification of ICMP soft error message arrival: TODO
o Required minimum coverage of the checksum for receiving: for UDP- o Required minimum coverage of the checksum for receiving: for UDP-
Lite, this can be done using the primitive Lite, this can be done using the primitive
SET_MIN_CHECKSUM_COVERAGE.UDP-Lite described in section 4 of SET_MIN_CHECKSUM_COVERAGE.UDP-Lite described in section 4 of
[RFC8303]. [RFC8303].
o Priority (Connection): TODO; for SCTP, this can be done using the
primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4
of [RFC8303].
o Timeout for aborting Connection: for SCTP, this can be done using
the primitive CHANGE_TIMEOUT.SCTP described in section 4 of
[RFC8303].
o Connection group transmission scheduler: for SCTP, this can be o Connection group transmission scheduler: for SCTP, this can be
done using the primitive SET_STREAM_SCHEDULER.SCTP described in done using the primitive SET_STREAM_SCHEDULER.SCTP described in
section 4 of [RFC8303]. section 4 of [RFC8303].
o Maximum message size concurrent with Connection establishment:
TODO
o Maximum Message size before fragmentation or segmentation: TODO
o Maximum Message size on send: TODO
o Maximum Message size on receive: TODO
o Capacity Profile: TODO
o Bounds on Send or Receive Rate: TODO
o TCP-specific Property: User Timeout: for TCP, this can be
configured using the primitive CHANGE_TIMEOUT.TCP described in
section 4 of [RFC8303].
It may happen that the application attempts to set a Protocol It may happen that the application attempts to set a Protocol
Property which does not apply to the actually chosen protocol. In Property which does not apply to the actually chosen protocol. In
this case, the implementation should fail gracefully, i.e., it may this case, the implementation should fail gracefully, i.e., it may
give a warning to the application, but it should not terminate the give a warning to the application, but it should not terminate the
Connection. Connection.
6.2. Handling Path Changes 6.2. Handling Path Changes
When a path change occurs, the Transport Services implementation is When a path change occurs, the Transport Services implementation is
responsible for notifying Protocol Instances in the Protocol Stack. responsible for notifying Protocol Instances in the Protocol Stack.
If the Protocol Stack includes a transport protocol that supports If the Protocol Stack includes a transport protocol that supports
multipath connectivity, an update to the available paths should multipath connectivity, an update to the available paths should
inform the Protocol Instance of the new set of paths that are inform the Protocol Instance of the new set of paths that are
permissible based on the Path Selection Properties passed by the permissible based on the Selection Properties passed by the
application. A multipath protocol can establish new subflows over application. A multipath protocol can establish new subflows over
new paths, and should tear down subflows over paths that are no new paths, and should tear down subflows over paths that are no
longer available. If the Protocol Stack includes a transport longer available. If the Protocol Stack includes a transport
protocol that does not support multipath, but support migrating protocol that does not support multipath, but support migrating
between paths, the update to available paths can be used as the between paths, the update to available paths can be used as the
trigger to migrating the connection. For protocols that do not trigger to migrating the connection. For protocols that do not
support multipath or migration, the Protocol Instances may be support multipath or migration, the Protocol Instances may be
informed of the path change, but should not be forcibly disconnected informed of the path change, but should not be forcibly disconnected
if the previously used path becomes unavailable. An exception to if the previously used path becomes unavailable. An exception to
this case is if the System Policy changes to prohibit traffic from this case is if the System Policy changes to prohibit traffic from
skipping to change at page 33, line 16 skipping to change at page 33, line 29
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.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", draft-ietf-taps-arch-01 (work in Transport Services", draft-ietf-taps-arch-02 (work in
progress), July 2018. progress), October 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-01 (work in Services", draft-ietf-taps-interface-02 (work in
progress), July 2018. progress), October 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-11 (work Services for End Systems", draft-ietf-taps-minset-11 (work
in progress), September 2018. in progress), September 2018.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, Transmission Protocol (SCTP)", RFC 6458,
DOI 10.17487/RFC6458, December 2011, DOI 10.17487/RFC6458, December 2011,
skipping to change at page 34, line 20 skipping to change at page 34, line 31
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP- User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>. <https://www.rfc-editor.org/info/rfc8304>.
[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/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-15 (work and Secure Transport", draft-ietf-quic-transport-18 (work
in progress), October 2018. in progress), January 2019.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[NEAT-flow-mapping] [NEAT-flow-mapping]
"Transparent Flow Mapping for NEAT (in Workshop on Future "Transparent Flow Mapping for NEAT (in Workshop on Future
of Internet Transport (FIT 2017))", n.d.. of Internet Transport (FIT 2017))", n.d..
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>. <https://www.rfc-editor.org/info/rfc5245>.
skipping to change at page 35, line 13 skipping to change at page 35, line 25
presented here to support discussion within the TAPS working group as presented here to support discussion within the TAPS working group as
to whether they should be added to a future revision of the base to whether they should be added to a future revision of the base
specification. specification.
A.1. Properties Affecting Sorting of Branches A.1. Properties Affecting Sorting of Branches
In addition to the Protocol and Path Selection Properties discussed In addition to the Protocol and Path Selection Properties discussed
in Section 4.3, the following properties under discussion can in Section 4.3, the following properties under discussion can
influence branch sorting: influence branch sorting:
o Size to be Sent or Received: An implementation may use the Size to o Bounds on Send or Receive Rate: If the application indicates a
be Sent or Received in combination with cached performance bound on the expected Send or Receive bitrate, an implementation
estimates, see Section 8.2, e.g. the observed Round Trip Time and may prefer a path that can likely provide the desired bandwidth,
the observed maximum throughput, to compute an estimate of the based on cached maximum throughput, see Section 8.2. The
completion time of a transfer over different available paths. It application may know the Send or Receive Bitrate from metadata in
may then prefer the path with the shorter expected completion adaptive HTTP streaming, such as MPEG-DASH.
time. This property may be used instead of the Capacity profile,
as the application does not always know whether its transfer will
be latency-bound or bandwidth-bound, and thus may not be able to
specify a Capacity Profile. However, the application may know the
Size to be Sent or Received from metadata, e.g., in adaptive HTTP
streaming such as MPEG-DASH, or in operating system upgrades. A
related paper is currently under submission.
o Send / Receive Bitrate: If the application indicates an expected
send or receive bitrate, an implementation may prefer a path that
can likely provide the desired bandwidth, based on cached maximum
throughput, see Section 8.2. The application may know the Send or
Receive Bitrate from metadata in adaptive HTTP streaming, such as
MPEG-DASH.
o Cost Preferences: If the application indicates a preference to o Cost Preferences: If the application indicates a preference to
avoid expensive paths, and some paths are associated with a avoid expensive paths, and some paths are associated with a
monetary cost, an implementation should decrease the ranking of monetary cost, an implementation should decrease the ranking of
such paths. If the application indicates that it prohibits using such paths. If the application indicates that it prohibits using
expensive paths, paths that are associated with a cost should be expensive paths, paths that are associated with a cost should be
purged from the decision tree. purged from the decision tree.
A.2. Send Parameters
In addition to the Send Parameters listed in Section 5.1.1.1, the
following Send Parameters are under discussion:
o Send Bitrate: If an application indicates a certain bitrate it
wants to send on the connection, the implementation may limit the
bitrate of the outgoing communication to that rate, for example by
setting an upper bound for the TCP congestion window of a
connection calculated from the Send Bitrate and the Round Trip
Time. This helps to avoid bursty traffic patterns on video
streaming servers, see [Trickle].
Authors' Addresses Authors' Addresses
Anna Brunstrom (editor) Anna Brunstrom (editor)
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
651 88 Karlstad 651 88 Karlstad
Sweden Sweden
Email: anna.brunstrom@kau.se Email: anna.brunstrom@kau.se
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
Theresa Enghardt Theresa Enghardt
TU Berlin TU Berlin
 End of changes. 53 change blocks. 
186 lines changed or deleted 178 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/