draft-ietf-taps-interface-03.txt   draft-ietf-taps-interface-04.txt 
TAPS Working Group B. Trammell, Ed. TAPS Working Group B. Trammell, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Welzl, Ed. Intended status: Standards Track M. Welzl, Ed.
Expires: September 12, 2019 University of Oslo Expires: January 9, 2020 University of Oslo
T. Enghardt T. Enghardt
TU Berlin TU Berlin
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
M. Kuehlewind M. Kuehlewind
ETH Zurich ETH Zurich
C. Perkins C. Perkins
University of Glasgow University of Glasgow
P. Tiesel P. Tiesel
TU Berlin TU Berlin
C. Wood C. Wood
T. Pauly
Apple Inc. Apple Inc.
March 11, 2019 July 08, 2019
An Abstract Application Layer Interface to Transport Services An Abstract Application Layer Interface to Transport Services
draft-ietf-taps-interface-03 draft-ietf-taps-interface-04
Abstract Abstract
This document describes an abstract programming interface to the This document describes an abstract programming interface to the
transport layer, following the Transport Services Architecture. It transport layer, following the Transport Services Architecture. It
supports the asynchronous, atomic transmission of messages over supports the asynchronous, atomic transmission of messages over
transport protocols and network paths dynamically selected at transport protocols and network paths dynamically selected at
runtime. It is intended to replace the traditional BSD sockets API runtime. It is intended to replace the traditional BSD sockets API
as the lowest common denominator interface to the transport layer, in as the lowest common denominator interface to the transport layer, in
an environment where endpoints have multiple interfaces and potential an environment where endpoints have multiple interfaces and potential
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 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
3. Interface Design Principles . . . . . . . . . . . . . . . . . 6 3. Interface Design Principles . . . . . . . . . . . . . . . . . 6
4. API Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. API Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Usage Examples . . . . . . . . . . . . . . . . . . . . . 7 4.1. Usage Examples . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Server Example . . . . . . . . . . . . . . . . . . . 8 4.1.1. Server Example . . . . . . . . . . . . . . . . . . . 8
4.1.2. Client Example . . . . . . . . . . . . . . . . . . . 9 4.1.2. Client Example . . . . . . . . . . . . . . . . . . . 9
4.1.3. Peer Example . . . . . . . . . . . . . . . . . . . . 10 4.1.3. Peer Example . . . . . . . . . . . . . . . . . . . . 10
4.2. Transport Properties . . . . . . . . . . . . . . . . . . 11 4.2. Transport Properties . . . . . . . . . . . . . . . . . . 11
4.2.1. Transport Property Names . . . . . . . . . . . . . . 12 4.2.1. Transport Property Names . . . . . . . . . . . . . . 12
4.2.2. Transport Property Types . . . . . . . . . . . . . . 13 4.2.2. Transport Property Types . . . . . . . . . . . . . . 13
4.3. Scope of the Interface Definition . . . . . . . . . . . . 13 4.3. Scope of the Interface Definition . . . . . . . . . . . . 13
5. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 14 5. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 14
5.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 14 5.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 14
5.2. Specifying Transport Properties . . . . . . . . . . . . . 16 5.2. Specifying Transport Properties . . . . . . . . . . . . . 16
5.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 18 5.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 18
5.2.2. Preservation of Message Boundaries . . . . . . . . . 18 5.2.2. Preservation of Message Boundaries . . . . . . . . . 18
5.2.3. Configure per-Message reliability . . . . . . . . . . 18 5.2.3. Configure Per-Message Reliability . . . . . . . . . . 18
5.2.4. Preservation of data ordering . . . . . . . . . . . . 18 5.2.4. Preservation of Data Ordering . . . . . . . . . . . . 18
5.2.5. Use 0-RTT session establishment with an idempotent 5.2.5. Use 0-RTT Session Establishment with an Idempotent
Message . . . . . . . . . . . . . . . . . . . . . . . 19 Message . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6. Multistream Connections in Group . . . . . . . . . . 19 5.2.6. Multistream Connections in Group . . . . . . . . . . 19
5.2.7. Control checksum coverage on sending . . . . . . . . 19 5.2.7. Full Checksum Coverage on Sending . . . . . . . . . . 19
5.2.8. Control checksum coverage on receiving . . . . . . . 19 5.2.8. Full Checksum Coverage on Receiving . . . . . . . . . 19
5.2.9. Congestion control . . . . . . . . . . . . . . . . . 19 5.2.9. Congestion control . . . . . . . . . . . . . . . . . 19
5.2.10. Interface Instance or Type . . . . . . . . . . . . . 20 5.2.10. Interface Instance or Type . . . . . . . . . . . . . 20
5.2.11. Provisioning Domain Instance or Type . . . . . . . . 21 5.2.11. Provisioning Domain Instance or Type . . . . . . . . 21
5.2.12. Parallel Use of Multiple Paths . . . . . . . . . . . 21 5.2.12. Parallel Use of Multiple Paths . . . . . . . . . . . 21
5.2.13. Direction of communication . . . . . . . . . . . . . 22 5.2.13. Direction of communication . . . . . . . . . . . . . 22
5.2.14. Notification of excessive retransmissions . . . . . . 22 5.2.14. Notification of excessive retransmissions . . . . . . 22
5.2.15. Notification of ICMP soft error message arrival . . . 22 5.2.15. Notification of ICMP soft error message arrival . . . 22
5.3. Specifying Security Parameters and Callbacks . . . . . . 22 5.3. Specifying Security Parameters and Callbacks . . . . . . 22
5.3.1. Pre-Connection Parameters . . . . . . . . . . . . . . 23 5.3.1. Pre-Connection Parameters . . . . . . . . . . . . . . 23
5.3.2. Connection Establishment Callbacks . . . . . . . . . 24 5.3.2. Connection Establishment Callbacks . . . . . . . . . 24
6. Establishing Connections . . . . . . . . . . . . . . . . . . 24 6. Establishing Connections . . . . . . . . . . . . . . . . . . 24
6.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 24 6.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 24
6.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 26 6.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 26
6.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 27 6.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 27
6.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 28 6.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 28
7. Sending Data . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Sending Data . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Basic Sending . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Basic Sending . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Send Events . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. Sending Replies . . . . . . . . . . . . . . . . . . . . . 30
7.2.1. Sent . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3. Send Events . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.2. Expired . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.1. Sent . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.3. SendError . . . . . . . . . . . . . . . . . . . . . . 31 7.3.2. Expired . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. Message Properties . . . . . . . . . . . . . . . . . . . 31 7.3.3. SendError . . . . . . . . . . . . . . . . . . . . . . 31
7.3.1. Lifetime . . . . . . . . . . . . . . . . . . . . . . 32 7.4. Message Properties . . . . . . . . . . . . . . . . . . . 31
7.3.2. Priority . . . . . . . . . . . . . . . . . . . . . . 32 7.4.1. Lifetime . . . . . . . . . . . . . . . . . . . . . . 32
7.3.3. Ordered . . . . . . . . . . . . . . . . . . . . . . . 33 7.4.2. Priority . . . . . . . . . . . . . . . . . . . . . . 33
7.3.4. Idempotent . . . . . . . . . . . . . . . . . . . . . 33 7.4.3. Ordered . . . . . . . . . . . . . . . . . . . . . . . 33
7.3.5. Final . . . . . . . . . . . . . . . . . . . . . . . . 33 7.4.4. Idempotent . . . . . . . . . . . . . . . . . . . . . 34
7.3.6. Corruption Protection Length . . . . . . . . . . . . 34 7.4.5. Final . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3.7. Reliable Data Transfer (Message) . . . . . . . . . . 34 7.4.6. Corruption Protection Length . . . . . . . . . . . . 35
7.3.8. Message Capacity Profile Override . . . . . . . . . . 34 7.4.7. Reliable Data Transfer (Message) . . . . . . . . . . 35
7.3.9. Singular Transmission . . . . . . . . . . . . . . . . 35 7.4.8. Message Capacity Profile Override . . . . . . . . . . 35
7.4. Partial Sends . . . . . . . . . . . . . . . . . . . . . . 35 7.4.9. Singular Transmission . . . . . . . . . . . . . . . . 36
7.5. Batching Sends . . . . . . . . . . . . . . . . . . . . . 36 7.5. Partial Sends . . . . . . . . . . . . . . . . . . . . . . 36
7.6. Send on Active Open: InitiateWithSend . . . . . . . . . . 36 7.6. Batching Sends . . . . . . . . . . . . . . . . . . . . . 37
7.7. Sender-side Framing . . . . . . . . . . . . . . . . . . . 37 7.7. Send on Active Open: InitiateWithSend . . . . . . . . . . 37
8. Receiving Data . . . . . . . . . . . . . . . . . . . . . . . 37 8. Receiving Data . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Enqueuing Receives . . . . . . . . . . . . . . . . . . . 37 8.1. Enqueuing Receives . . . . . . . . . . . . . . . . . . . 38
8.2. Receive Events . . . . . . . . . . . . . . . . . . . . . 38 8.2. Receive Events . . . . . . . . . . . . . . . . . . . . . 39
8.2.1. Received . . . . . . . . . . . . . . . . . . . . . . 38 8.2.1. Received . . . . . . . . . . . . . . . . . . . . . . 39
8.2.2. ReceivedPartial . . . . . . . . . . . . . . . . . . . 39 8.2.2. ReceivedPartial . . . . . . . . . . . . . . . . . . . 39
8.2.3. ReceiveError . . . . . . . . . . . . . . . . . . . . 39 8.2.3. ReceiveError . . . . . . . . . . . . . . . . . . . . 40
8.3. Message Receive Context . . . . . . . . . . . . . . . . . 40 8.3. Receive Message Properties . . . . . . . . . . . . . . . 40
8.3.1. ECN . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.3.1. ECN . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3.2. Early Data . . . . . . . . . . . . . . . . . . . . . 40 8.3.2. Early Data . . . . . . . . . . . . . . . . . . . . . 41
8.3.3. Receiving Final Messages . . . . . . . . . . . . . . 40 8.3.3. Receiving Final Messages . . . . . . . . . . . . . . 41
8.4. Receiver-side De-framing over Stream Protocols . . . . . 41 9. Message Contexts . . . . . . . . . . . . . . . . . . . . . . 41
9. Managing Connections . . . . . . . . . . . . . . . . . . . . 41 10. Message Framers . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Generic Connection Properties . . . . . . . . . . . . . . 43 10.1. Defining Message Framers . . . . . . . . . . . . . . . . 43
9.1.1. Retransmission threshold before excessive 10.2. Adding Message Framers to Connections . . . . . . . . . 43
retransmission notification . . . . . . . . . . . . . 43 10.3. Framing Meta-Data . . . . . . . . . . . . . . . . . . . 43
9.1.2. Required minimum coverage of the Corruption 10.4. Message Framer Lifetime . . . . . . . . . . . . . . . . 44
Protection for receiving . . . . . . . . . . . . . . 43 10.5. Sender-side Message Framing . . . . . . . . . . . . . . 44
9.1.3. Priority (Connection) . . . . . . . . . . . . . . . . 44 10.6. Receiver-side Message Framing . . . . . . . . . . . . . 45
9.1.4. Timeout for aborting Connection . . . . . . . . . . . 44
9.1.5. Connection group transmission scheduler . . . . . . . 44 11. Managing Connections . . . . . . . . . . . . . . . . . . . . 46
9.1.6. Maximum message size concurrent with Connection 11.1. Generic Connection Properties . . . . . . . . . . . . . 47
establishment . . . . . . . . . . . . . . . . . . . . 44 11.1.1. Retransmission Threshold Before Excessive
9.1.7. Maximum Message size before fragmentation or Retransmission Notification . . . . . . . . . . . . 47
segmentation . . . . . . . . . . . . . . . . . . . . 44 11.1.2. Required Minimum Corruption Protection Coverage for
9.1.8. Maximum Message size on send . . . . . . . . . . . . 45 Receiving . . . . . . . . . . . . . . . . . . . . . 48
9.1.9. Maximum Message size on receive . . . . . . . . . . . 45 11.1.3. Priority (Connection) . . . . . . . . . . . . . . . 48
9.1.10. Capacity Profile . . . . . . . . . . . . . . . . . . 45 11.1.4. Timeout for Aborting Connection . . . . . . . . . . 48
9.1.11. Bounds on Send or Receive Rate . . . . . . . . . . . 47 11.1.5. Connection Group Transmission Scheduler . . . . . . 49
9.1.12. TCP-specific Property: User Timeout . . . . . . . . . 47 11.1.6. Maximum Message Size Concurrent with Connection
9.2. Soft Errors . . . . . . . . . . . . . . . . . . . . . . . 47 Establishment . . . . . . . . . . . . . . . . . . . 49
9.3. Excessive retransmissions . . . . . . . . . . . . . . . . 48 11.1.7. Maximum Message Size Before Fragmentation or
10. Connection Termination . . . . . . . . . . . . . . . . . . . 48 Segmentation . . . . . . . . . . . . . . . . . . . . 49
11. Connection State and Ordering of Operations and Events . . . 48 11.1.8. Maximum Message Size on Send . . . . . . . . . . . . 49
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 11.1.9. Maximum Message Size on Receive . . . . . . . . . . 49
13. Security Considerations . . . . . . . . . . . . . . . . . . . 50 11.1.10. Capacity Profile . . . . . . . . . . . . . . . . . . 50
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 11.1.11. Bounds on Send or Receive Rate . . . . . . . . . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.1.12. TCP-specific Property: User Timeout . . . . . . . . 52
15.1. Normative References . . . . . . . . . . . . . . . . . . 50 11.2. Soft Errors . . . . . . . . . . . . . . . . . . . . . . 52
15.2. Informative References . . . . . . . . . . . . . . . . . 51 11.3. Excessive retransmissions . . . . . . . . . . . . . . . 52
Appendix A. Additional Properties . . . . . . . . . . . . . . . 53 12. Connection Termination . . . . . . . . . . . . . . . . . . . 53
A.1. Experimental Transport Properties . . . . . . . . . . . . 53 13. Connection State and Ordering of Operations and Events . . . 53
A.1.1. Cost Preferences . . . . . . . . . . . . . . . . . . 53 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
Appendix B. Sample API definition in Go . . . . . . . . . . . . 54 15. Security Considerations . . . . . . . . . . . . . . . . . . . 54
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
17.1. Normative References . . . . . . . . . . . . . . . . . . 55
17.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Additional Properties . . . . . . . . . . . . . . . 57
A.1. Experimental Transport Properties . . . . . . . . . . . . 58
A.1.1. Cost Preferences . . . . . . . . . . . . . . . . . . 58
Appendix B. Sample API definition in Go . . . . . . . . . . . . 59
Appendix C. Relationship to the Minimal Set of Transport Appendix C. Relationship to the Minimal Set of Transport
Services for End Systems . . . . . . . . . . . . . . 54 Services for End Systems . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing
network sockets into the UNIX programming model, allowing anyone who network sockets into the UNIX programming model, allowing anyone who
knew how to write programs that dealt with sequential-access files to knew how to write programs that dealt with sequential-access files to
also write network applications, was a revolution in simplicity. The also write network applications, was a revolution in simplicity. The
simplicity of this API is a key reason the Internet won the protocol simplicity of this API is a key reason the Internet won the protocol
wars of the 1980s. SOCK_STREAM is tied to the Transmission Control wars of the 1980s. SOCK_STREAM is tied to the Transmission Control
Protocol (TCP), specified in 1981 [RFC0793]. TCP has scaled Protocol (TCP), specified in 1981 [RFC0793]. TCP has scaled
skipping to change at page 7, line 38 skipping to change at page 7, line 44
directional or unidirectional). Connections can be created from directional or unidirectional). Connections can be created from
Preconnections in three ways: by initiating the Preconnection (i.e., Preconnections in three ways: by initiating the Preconnection (i.e.,
actively opening, as in a client), through listening on the actively opening, as in a client), through listening on the
Preconnection (i.e., passively opening, as in a server), or Preconnection (i.e., passively opening, as in a server), or
rendezvousing on the Preconnection (i.e. peer to peer rendezvousing on the Preconnection (i.e. peer to peer
establishment). establishment).
Once a Connection is established, data can be sent on it in the form Once a Connection is established, data can be sent on it in the form
of Messages. The interface supports the preservation of message of Messages. The interface supports the preservation of message
boundaries both via explicit Protocol Stack support, and via boundaries both via explicit Protocol Stack support, and via
application support through a deframing callback which finds message application support through a Message Framer which finds message
boundaries in a stream. Messages are received asynchronously through boundaries in a stream. Messages are received asynchronously through
a callback registered by the application. Errors and other a callback registered by the application. Errors and other
notifications also happen asynchronously on the Connection. notifications also happen asynchronously on the Connection.
Section 5, Section 6, Section 7, Section 8, and Section 10 describe Section 5, Section 6, Section 7, Section 8, and Section 12 describe
the details of application interaction with Objects through Actions the details of application interaction with Objects through Actions
and Events in each phase of a Connection, following the phases and Events in each phase of a Connection, following the phases
described in [I-D.ietf-taps-arch]. described in [I-D.ietf-taps-arch].
4.1. Usage Examples 4.1. Usage Examples
The following usage examples illustrate how an application might use The following usage examples illustrate how an application might use
a Transport Services Interface to: a Transport Services Interface to:
o Act as a server, by listening for incoming connections, receiving o Act as a server, by listening for incoming connections, receiving
skipping to change at page 8, line 24 skipping to change at page 8, line 29
Messages, and receiving Messages, see Section 4.1.3. Messages, and receiving Messages, see Section 4.1.3.
The examples in this section presume that a transport protocol is The examples in this section presume that a transport protocol is
available between the endpoints which provides Reliable Data available between the endpoints which provides Reliable Data
Transfer, Preservation of data ordering, and Preservation of Message Transfer, Preservation of data ordering, and Preservation of Message
Boundaries. In this case, the application can choose to receive only Boundaries. In this case, the application can choose to receive only
complete messages. complete messages.
If none of the available transport protocols provides Preservation of If none of the available transport protocols provides Preservation of
Message Boundaries, but there is a transport protocol which provides Message Boundaries, but there is a transport protocol which provides
a reliable ordered octet stream, an application may receive this a reliable ordered byte stream, an application may receive this byte
octet stream as partial Messages and transform it into application- stream as partial Messages and transform it into application-layer
layer Messages. Alternatively, an application may provide a Messages. Alternatively, an application may provide a Message
Deframer, which is a function that transforms an octet stream into a Framer, which can transform a byte stream into a sequence of Messages
sequence of Messages, see Section 8.4. (Section 10.6).
4.1.1. Server Example 4.1.1. Server Example
This is an example of how an application might listen for incoming This is an example of how an application might listen for incoming
Connections using the Transport Services Interface, receive a Connections using the Transport Services Interface, receive a
request, and send a response. request, and send a response.
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("any") LocalSpecifier.WithInterface("any")
LocalSpecifier.WithService("https") LocalSpecifier.WithService("https")
skipping to change at page 9, line 23 skipping to change at page 9, line 23
SecurityParameters := NewSecurityParameters() SecurityParameters := NewSecurityParameters()
SecurityParameters.AddIdentity(identity) SecurityParameters.AddIdentity(identity)
SecurityParameters.AddPrivateKey(privateKey, publicKey) SecurityParameters.AddPrivateKey(privateKey, publicKey)
// Specifying a remote endpoint is optional when using Listen() // Specifying a remote endpoint is optional when using Listen()
Preconnection := NewPreconnection(LocalSpecifier, Preconnection := NewPreconnection(LocalSpecifier,
None, None,
TransportProperties, TransportProperties,
SecurityParameters) SecurityParameters)
Preconnection.Listen() Listener := Preconnection.Listen()
Preconnection -> ConnectionReceived<Connection> Listener -> ConnectionReceived<Connection>
// Only receive complete messages // Only receive complete messages
Connection.Receive() Connection.Receive()
Connection -> Received(messageDataRequest, messageContext) Connection -> Received(messageDataRequest, messageContext)
Connection.Send(messageDataResponse) Connection.Send(messageDataResponse)
Connection.Close() Connection.Close()
// Stop listening for incoming Connections // Stop listening for incoming Connections
Preconnection.Stop() Listener.Stop()
4.1.2. Client Example 4.1.2. Client Example
This is an example of how an application might connect to a remote This is an example of how an application might connect to a remote
application using the Transport Services Interface, send a request, application using the Transport Services Interface, send a request,
and receive a response. and receive a response.
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostname("example.com") RemoteSpecifier.WithHostname("example.com")
RemoteSpecifier.WithService("https") RemoteSpecifier.WithService("https")
skipping to change at page 11, line 51 skipping to change at page 11, line 51
Connection.Close() Connection.Close()
4.2. Transport Properties 4.2. Transport Properties
Each application using the Transport Services Interface declares its Each application using the Transport Services Interface declares its
preferences for how the transport service should operate using preferences for how the transport service should operate using
properties at each stage of the lifetime of a connection. During properties at each stage of the lifetime of a connection. During
pre-establishment, Selection Properties (see Section 5.2) are used to pre-establishment, Selection Properties (see Section 5.2) are used to
specify which paths and protocol stacks can be used and are preferred specify which paths and protocol stacks can be used and are preferred
by the application, and Connection Properties (see Section 9.1) can by the application, and Connection Properties (see Section 11.1) can
be used to influence decisions made during establishment and to fine- be used to influence decisions made during establishment and to fine-
tune the eventually established connection. These Connection tune the eventually established connection. These Connection
Properties can also be used later, to monitor and fine-tune Properties can also be used later, to monitor and fine-tune
established connections. The behavior of the selected protocol established connections. The behavior of the selected protocol
stack(s) when sending Messages is controlled by Message Properties stack(s) when sending Messages is controlled by Message Properties
(see Section 7.3). (see Section 7.4).
Collectively, Selection, Connection, and Message Properties can be Collectively, Selection, Connection, and Message Properties can be
referred to as Transport Properties. All Transport Properties, referred to as Transport Properties. All Transport Properties,
regardless of the phase in which they are used, are organized within regardless of the phase in which they are used, are organized within
a single namespace. This enables setting them as defaults in earlier a single namespace. This enables setting them as defaults in earlier
stages and querying them in later stages: - Connection Properties can stages and querying them in later stages: - Connection Properties can
be set on Preconnections - Message Properties can be set on be set on Preconnections - Message Properties can be set on
Preconnections and Connections - The effect of Selection Properties Preconnections and Connections - The effect of Selection Properties
can be queried on Connections and Messages can be queried on Connections and Messages
skipping to change at page 12, line 34 skipping to change at page 12, line 34
process. process.
4.2.1. Transport Property Names 4.2.1. Transport Property Names
Transport Properties are referred to by property names. These names Transport Properties are referred to by property names. These names
are lower-case strings whereby words are separated by hyphens. These are lower-case strings whereby words are separated by hyphens. These
names serve two purposes: names serve two purposes:
o Allow different components of a TAPS implementation to pass o Allow different components of a TAPS implementation to pass
Transport Properties, e.g., between a language frontend and a Transport Properties, e.g., between a language frontend and a
policy manager. policy manager, or as a representation of properties retrieved
from a file or other storage.
o Make code of different TAPS implementations look similar. o Make code of different TAPS implementations look similar.
Transport Property Names are hierarchically organized in the form Transport Property Names are hierarchically organized in the form
[<Namespace>.]<PropertyName>. [<Namespace>.]<PropertyName>.
o The Namespace part is empty for well known, generic properties, o The Namespace part is empty for well known, generic properties,
i.e., for properties defined by an RFC which are not protocol i.e., for properties defined by an RFC which are not protocol
specific. specific.
o Protocol Specific Properties must use the protocol acronym as o Protocol Specific Properties must use the protocol acronym as
Namespace, e.g., "tcp" for TCP specific Transport Properties. For Namespace, e.g., "tcp" for TCP specific Transport Properties. For
IETF protocols, property names under these namespaces should be IETF protocols, property names under these namespaces SHOULD be
defined in an RFC. defined in an RFC.
o Vendor or implementation specific properties must use a a string o Vendor or implementation specific properties must use a a string
identifying the vendor or implementation as Namespace. identifying the vendor or implementation as Namespace.
4.2.2. Transport Property Types 4.2.2. Transport Property Types
Transport Properties can have one of a set of data types: Transport Properties can have one of a set of data types:
o Boolean: can take the values "true" and "false"; representation is o Boolean: can take the values "true" and "false"; representation is
skipping to change at page 14, line 23 skipping to change at page 14, line 28
The pre-establishment phase allows applications to specify properties The pre-establishment phase allows applications to specify properties
for the Connections they are about to make, or to query the API about for the Connections they are about to make, or to query the API about
potential connections they could make. potential connections they could make.
A Preconnection Object represents a potential Connection. It has A Preconnection Object represents a potential Connection. It has
state that describes properties of a Connection that might exist in state that describes properties of a Connection that might exist in
the future. This state comprises Local Endpoint and Remote Endpoint the future. This state comprises Local Endpoint and Remote Endpoint
Objects that denote the endpoints of the potential Connection (see Objects that denote the endpoints of the potential Connection (see
Section 5.1), the Selection Properties (see Section 5.2), any Section 5.1), the Selection Properties (see Section 5.2), any
preconfigured Connection Properties (Section 9.1), and the security preconfigured Connection Properties (Section 11.1), and the security
parameters (see Section 5.3): parameters (see Section 5.3):
Preconnection := NewPreconnection(LocalEndpoint, Preconnection := NewPreconnection(LocalEndpoint,
RemoteEndpoint, RemoteEndpoint,
TransportProperties, TransportProperties,
SecurityParams) SecurityParams)
The Local Endpoint MUST be specified if the Preconnection is used to The Local Endpoint MUST be specified if the Preconnection is used to
Listen() for incoming Connections, but is OPTIONAL if it is used to Listen() for incoming Connections, but is OPTIONAL if it is used to
Initiate() connections. The Remote Endpoint MUST be specified if the Initiate() connections. The Remote Endpoint MUST be specified if the
Preconnection is used to Initiate() Connections, but is OPTIONAL if Preconnection is used to Initiate() Connections, but is OPTIONAL if
it is used to Listen() for incoming Connections. The Local Endpoint it is used to Listen() for incoming Connections. The Local Endpoint
and the Remote Endpoint MUST both be specified if a peer-to-peer and the Remote Endpoint MUST both be specified if a peer-to-peer
Rendezvous is to occur based on the Preconnection. Rendezvous is to occur based on the Preconnection.
Framers (see Section 7.7) and deframers (see Section 8.4), if Message Framers (see Section 10), if required, should be added to the
necessary, should be bound to the Preconnection during pre- Preconnection during pre-establishment.
establishment.
5.1. Specifying Endpoints 5.1. Specifying Endpoints
The transport services API uses the Local Endpoint and Remote The transport services API uses the Local Endpoint and Remote
Endpoint types to refer to the endpoints of a transport connection. Endpoint types to refer to the endpoints of a transport connection.
Subtypes of these represent various different types of endpoint Subtypes of these represent various different types of endpoint
identifiers, such as IP addresses, DNS names, and interface names, as identifiers, such as IP addresses, DNS names, and interface names, as
well as port numbers and service names. well as port numbers and service names.
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
skipping to change at page 17, line 10 skipping to change at page 17, line 10
paths that match a Prohibit, then exclude all protocols and paths paths that match a Prohibit, then exclude all protocols and paths
that do not match a Require, then sort candidates according to that do not match a Require, then sort candidates according to
Preferred properties, and then use Avoided properties as a Preferred properties, and then use Avoided properties as a
tiebreaker. Selection Properties which select paths take preference tiebreaker. Selection Properties which select paths take preference
over those which select protocols. For example, if an application over those which select protocols. For example, if an application
indicates a preference for a specific path by specifying an indicates a preference for a specific path by specifying an
interface, but also a preference for a protocol not available on this interface, but also a preference for a protocol not available on this
path, the transport system will try the path first, ignoring the path, the transport system will try the path first, ignoring the
preference. preference.
Both Selection and Connection Properties can be added to a Selection, and Connection Properties, as well as defaults for Message
Preconnection to configure the selection process, and to further Properties, can be added to a Preconnection to configure the
configure the eventually selected protocol stack(s). They are selection process, and to further configure the eventually selected
collected into a TransportProperties object to be passed into a protocol stack(s). They are collected into a TransportProperties
Preconnection object: object to be passed into a Preconnection object:
TransportProperties := NewTransportProperties() TransportProperties := NewTransportProperties()
Individual properties are then added to the TransportProperties Individual properties are then added to the TransportProperties
Object: Object:
TransportProperties.Add(property, value) TransportProperties.Add(property, value)
Selection Properties can be added to a TransportProperties object Selection Properties can be added to a TransportProperties object
using special actions for each preference level i.e, using special actions for each preference level i.e,
skipping to change at page 17, line 45 skipping to change at page 17, line 45
For an existing Connection, the Transport Properties can be queried For an existing Connection, the Transport Properties can be queried
any time by using the following call on the Connection Object: any time by using the following call on the Connection Object:
TransportProperties := Connection.GetTransportProperties() TransportProperties := Connection.GetTransportProperties()
A Connection gets its Transport Properties either by being explicitly A Connection gets its Transport Properties either by being explicitly
configured via a Preconnection, by configuration after establishment, configured via a Preconnection, by configuration after establishment,
or by inheriting them from an antecedent via cloning; see Section 6.4 or by inheriting them from an antecedent via cloning; see Section 6.4
for more. for more.
Section 9.1 provides a list of Connection Properties, while Selection Section 11.1 provides a list of Connection Properties, while
Properties are listed in the subsections below. Note that many Selection Properties are listed in the subsections below. Note that
properties are only considered during establishment, and can not be many properties are only considered during establishment, and can not
changed after a Connection is established; however, they can be be changed after a Connection is established; however, they can be
queried. Querying a Selection Property after establishment yields queried. Querying a Selection Property after establishment yields
the value Required for properties of the selected protocol and path, the value Required for properties of the selected protocol and path,
Avoid for properties avoided during selection, and Ignore for all Avoid for properties avoided during selection, and Ignore for all
other properties. other properties.
An implementation of this interface must provide sensible defaults An implementation of this interface must provide sensible defaults
for Selection Properties. The recommended defaults given for each for Selection Properties. The recommended defaults given for each
property below represent a configuration that can be implemented over property below represent a configuration that can be implemented over
TCP. An alternate set of default Protocol Selection Properties would TCP. An alternate set of default Protocol Selection Properties would
represent a configuration that can be implemented over UDP. represent a configuration that can be implemented over UDP.
skipping to change at page 18, line 31 skipping to change at page 18, line 31
Require Reliable Data Transfer. Require Reliable Data Transfer.
5.2.2. Preservation of Message Boundaries 5.2.2. Preservation of Message Boundaries
Name: preserve-msg-boundaries Name: preserve-msg-boundaries
This property specifies whether the application needs or prefers to This property specifies whether the application needs or prefers to
use a transport protocol that preserves message boundaries. The use a transport protocol that preserves message boundaries. The
recommended default is to Prefer Preservation of Message Boundaries. recommended default is to Prefer Preservation of Message Boundaries.
5.2.3. Configure per-Message reliability 5.2.3. Configure Per-Message Reliability
Name: per-msg-reliability Name: per-msg-reliability
This property specifies whether an application considers it useful to This property specifies whether an application considers it useful to
indicate its reliability requirements on a per-Message basis. This indicate its reliability requirements on a per-Message basis. This
property applies to Connections and Connection Groups. The property applies to Connections and Connection Groups. The
recommended default is to Ignore this option. recommended default is to Ignore this option.
5.2.4. Preservation of data ordering 5.2.4. Preservation of Data Ordering
Name: preserve-order Name: preserve-order
This property specifies whether the application wishes to use a This property specifies whether the application wishes to use a
transport protocol that can ensure that data is received by the transport protocol that can ensure that data is received by the
application on the other end in the same order as it was sent. The application on the other end in the same order as it was sent. The
recommended default is to Require Preservation of data ordering. recommended default is to Require Preservation of data ordering.
5.2.5. Use 0-RTT session establishment with an idempotent Message 5.2.5. Use 0-RTT Session Establishment with an Idempotent Message
Name: zero-rtt-msg Name: zero-rtt-msg
This property specifies whether an application would like to supply a This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment, Message to the transport protocol before Connection establishment,
which will then be reliably transferred to the other side before or which will then be reliably transferred to the other side before or
during Connection establishment, potentially multiple times. See during Connection establishment, potentially multiple times (i.e.,
also Section 7.3.4. The recommended default is to Prefer this multiple copies of the message data may be passed to the Remote
option. Endpoint). See also Section 7.4.4. The recommended default is to
Ignore this option. Note that disabling this property has no effect
for protocols that are not connection-oriented and do not protect
against duplicated messages, e.g., UDP.
5.2.6. Multistream Connections in Group 5.2.6. Multistream Connections in Group
Name: multistreaming Name: multistreaming
This property specifies that the application would prefer multiple This property specifies that the application would prefer multiple
Connections within a Connection Group to be provided by streams of a Connections within a Connection Group to be provided by streams of a
single underlying transport connection where possible. The single underlying transport connection where possible. The
recommended default is to Prefer have this option. recommended default is to Prefer this option.
5.2.7. Control checksum coverage on sending 5.2.7. Full Checksum Coverage on Sending
Name: per-msg-checksum-len-send Name: per-msg-checksum-len-send
This property specifies whether the application considers it useful This property specifies whether the application desires protection
to enable, disable, or configure a checksum when sending a Message. against corruption for all data transmitted on this Connection.
The recommended default is to Ignore this option. Disabling this property may enable to control checksum coverage later
(see Section 7.4.6). The recommended default is to Require this
option.
5.2.8. Control checksum coverage on receiving 5.2.8. Full Checksum Coverage on Receiving
Name: per-msg-checksum-len-recv Name: per-msg-checksum-len-recv
This property specifies whether the application considers it useful This property specifies whether the application desires protection
configure whether to require a checksum or not when receiving. The against corruption for all data received on this Connection. The
recommended default is to Ignore this option. recommended default is to Require this option.
5.2.9. Congestion control 5.2.9. Congestion control
Name: congestion-control Name: congestion-control
This property specifies whether the application would like the This property specifies whether the application would like the
Connection to be congestion controlled or not. Note that if a Connection to be congestion controlled or not. Note that if a
Connection is not congestion controlled, an application using such a Connection is not congestion controlled, an application using such a
Connection should itself perform congestion control in accordance Connection should itself perform congestion control in accordance
with [RFC2914]. Also note that reliability is usually combined with with [RFC2914]. Also note that reliability is usually combined with
skipping to change at page 25, line 48 skipping to change at page 25, line 51
and security parameters cannot be fulfilled on a Connection for and security parameters cannot be fulfilled on a Connection for
initiation (e.g. the set of available Paths and/or Protocol Stacks initiation (e.g. the set of available Paths and/or Protocol Stacks
meeting the constraints is empty) or reconciled with the local and/or meeting the constraints is empty) or reconciled with the local and/or
remote endpoints; when the remote specifier cannot be resolved; or remote endpoints; when the remote specifier cannot be resolved; or
when no transport-layer connection can be established to the remote when no transport-layer connection can be established to the remote
endpoint (e.g. because the remote endpoint is not accepting endpoint (e.g. because the remote endpoint is not accepting
connections, the application is prohibited from opening a Connection connections, the application is prohibited from opening a Connection
by the operating system, or the establishment attempt has timed out by the operating system, or the establishment attempt has timed out
for any other reason). for any other reason).
See also Section 7.6 to combine Connection establishment and See also Section 7.7 to combine Connection establishment and
transmission of the first message in a single action. transmission of the first message in a single action.
6.2. Passive Open: Listen 6.2. Passive Open: Listen
Passive open is the Action of waiting for Connections from remote Passive open is the Action of waiting for Connections from remote
endpoints, commonly used by servers in client-server interactions. endpoints, commonly used by servers in client-server interactions.
Passive open is supported by this interface through the Listen Passive open is supported by this interface through the Listen Action
Action: and returns a Listener object:
Preconnection.Listen() Listener := Preconnection.Listen()
Before calling Listen, the caller must have initialized the Before calling Listen, the caller must have initialized the
Preconnection during the pre-establishment phase with a Local Preconnection during the pre-establishment phase with a Local
Endpoint specifier, as well as all properties necessary for Protocol Endpoint specifier, as well as all properties necessary for Protocol
Stack selection. A Remote Endpoint may optionally be specified, to Stack selection. A Remote Endpoint may optionally be specified, to
constrain what Connections are accepted. The Listen() Action constrain what Connections are accepted. The Listen() Action returns
consumes the Preconnection. Once Listen() has been called, no a Listener object. Once Listen() has been called, properties added
further properties may be added to the Preconnection, and no to the Preconnection have no effect on the Listener and the
subsequent establishment call may be made on the Preconnection. Preconnection can be disposed of or reused.
Listening continues until the global context shuts down, or until the Listening continues until the global context shuts down, or until the
Stop action is performed on the same Preconnection: Stop action is performed on the Listener object:
Preconnection.Stop() Listener.Stop()
After Stop() is called, the preconnection can be disposed of. After Stop() is called, the Listener can be disposed of.
Preconnection -> ConnectionReceived<Connection> Listener -> ConnectionReceived<Connection>
The ConnectionReceived Event occurs when a Remote Endpoint has The ConnectionReceived Event occurs when a Remote Endpoint has
established a transport-layer connection to this Preconnection (for established a transport-layer connection to this Listener (for
Connection-oriented transport protocols), or when the first Message Connection-oriented transport protocols), or when the first Message
has been received from the Remote Endpoint (for Connectionless has been received from the Remote Endpoint (for Connectionless
protocols), causing a new Connection to be created. The resulting protocols), causing a new Connection to be created. The resulting
Connection is contained within the ConnectionReceived event, and is Connection is contained within the ConnectionReceived event, and is
ready to use as soon as it is passed to the application via the ready to use as soon as it is passed to the application via the
event. event.
Preconnection -> ListenError<> Listener -> ListenError<>
A ListenError occurs either when the Preconnection cannot be A ListenError occurs either when the Properties of the Preconnection
fulfilled for listening, when the Local Endpoint (or Remote Endpoint, cannot be fulfilled for listening, when the Local Endpoint (or Remote
if specified) cannot be resolved, or when the application is Endpoint, if specified) cannot be resolved, or when the application
prohibited from listening by policy. is prohibited from listening by policy.
Preconnection -> Stopped<> Listener -> Stopped<>
A Stopped event occurs after the Preconnection has stopped listening. A Stopped event occurs after the Listener has stopped listening.
6.3. Peer-to-Peer Establishment: Rendezvous 6.3. Peer-to-Peer Establishment: Rendezvous
Simultaneous peer-to-peer Connection establishment is supported by Simultaneous peer-to-peer Connection establishment is supported by
the Rendezvous() Action: the Rendezvous() Action:
Preconnection.Rendezvous() Preconnection.Rendezvous()
The Preconnection Object must be specified with both a Local Endpoint The Preconnection Object must be specified with both a Local Endpoint
and a Remote Endpoint, and also the transport properties and security and a Remote Endpoint, and also the transport properties and security
skipping to change at page 27, line 37 skipping to change at page 27, line 37
Preconnection -> RendezvousDone<Connection> Preconnection -> RendezvousDone<Connection>
The RendezvousDone<> Event occurs when a Connection is established The RendezvousDone<> Event occurs when a Connection is established
with the Remote Endpoint. For Connection-oriented transports, this with the Remote Endpoint. For Connection-oriented transports, this
occurs when the transport-layer connection is established; for occurs when the transport-layer connection is established; for
Connectionless transports, it occurs when the first Message is Connectionless transports, it occurs when the first Message is
received from the Remote Endpoint. The resulting Connection is received from the Remote Endpoint. The resulting Connection is
contained within the RendezvousDone<> Event, and is ready to use as contained within the RendezvousDone<> Event, and is ready to use as
soon as it is passed to the application via the Event. soon as it is passed to the application via the Event.
Preconnection -> RendezvousError<msgRef, error> Preconnection -> RendezvousError<messageContext, error>
An RendezvousError occurs either when the Preconnection cannot be An RendezvousError occurs either when the Preconnection cannot be
fulfilled for listening, when the Local Endpoint or Remote Endpoint fulfilled for listening, when the Local Endpoint or Remote Endpoint
cannot be resolved, when no transport-layer connection can be cannot be resolved, when no transport-layer connection can be
established to the Remote Endpoint, or when the application is established to the Remote Endpoint, or when the application is
prohibited from rendezvous by policy. prohibited from rendezvous by policy.
When using some NAT traversal protocols, e.g., Interactive When using some NAT traversal protocols, e.g., Interactive
Connectivity Establishment (ICE) [RFC5245], it is expected that the Connectivity Establishment (ICE) [RFC5245], it is expected that the
Local Endpoint will be configured with some method of discovering NAT Local Endpoint will be configured with some method of discovering NAT
skipping to change at page 28, line 18 skipping to change at page 28, line 18
represent the concrete addresses, local and server reflexive, on represent the concrete addresses, local and server reflexive, on
which a Rendezvous() for the Preconnection will listen for incoming which a Rendezvous() for the Preconnection will listen for incoming
Connections. These resolved Preconnections will share all other Connections. These resolved Preconnections will share all other
Properties with the Preconnection from which they are derived, though Properties with the Preconnection from which they are derived, though
some Properties may be made more-specific by the resolution process. some Properties may be made more-specific by the resolution process.
This list can be passed to a peer via a signalling protocol, such as This list can be passed to a peer via a signalling protocol, such as
SIP [RFC3261] or WebRTC [RFC7478], to configure the remote. SIP [RFC3261] or WebRTC [RFC7478], to configure the remote.
6.4. Connection Groups 6.4. Connection Groups
Groups of Connections can be created using the Clone Action: Entangled Connections can be created using the Clone Action:
Connection := Connection.Clone() Connection := Connection.Clone()
Calling Clone on a Connection yields a group of two Connections: the Calling Clone on a Connection yields a group of two Connections: the
parent Connection on which Clone was called, and the resulting cloned parent Connection on which Clone was called, and the resulting cloned
Connection. These connections are "entangled" with each other, and Connection. These connections are "entangled" with each other, and
become part of a Connection Group. Calling Clone on any of these two become part of a Connection Group. Calling Clone on any of these two
Connections adds a third Connection to the Connection Group, and so Connections adds a third Connection to the Connection Group, and so
on. Connections in a Connection Group share all Protocol Properties on. Connections in a Connection Group share all Protocol Properties
that are not applicable to a Message. that are not applicable to a Message.
In addition, incoming entangled Connections can be received by
creating a Listener on an existing connection:
Listener := Connection.Listen()
Changing one of these Protocol Properties on one Connection in the Changing one of these Protocol Properties on one Connection in the
group changes it for all others. Per-Message Protocol Properties, group changes it for all others. Per-Message Protocol Properties,
however, are not entangled. For example, changing "Timeout for however, are not entangled. For example, changing "Timeout for
aborting Connection" (see Section 9.1.4) on one Connection in a group aborting Connection" (see Section 11.1.4) on one Connection in a
will automatically change this Protocol Property for all Connections group will automatically change this Protocol Property for all
in the group in the same way. However, changing "Lifetime" (see Connections in the group in the same way. However, changing
Section 7.3.1) of a Message will only affect a single Message on a "Lifetime" (see Section 7.4.1) of a Message will only affect a single
single Connection, entangled or not. Message on a single Connection, entangled or not.
If the underlying protocol supports multi-streaming, it is natural to If the underlying protocol supports multi-streaming, it is natural to
use this functionality to implement Clone. In that case, entangled use this functionality to implement Clone. In that case, entangled
Connections are multiplexed together, giving them similar treatment Connections are multiplexed together, giving them similar treatment
not only inside endpoints but also across the end-to-end Internet not only inside endpoints but also across the end-to-end Internet
path. path.
If the underlying Protocol Stack does not support cloning, or cannot If the underlying Protocol Stack does not support cloning, or cannot
create a new stream on the given Connection, then attempts to clone a create a new stream on the given Connection, then attempts to clone a
connection will result in a CloneError: Connection will result in a CloneError:
Connection -> CloneError<> Connection -> CloneError<>
The Protocol Property "Priority" operates on entangled Connections as The Protocol Property "Priority" operates on entangled Connections as
in Section 7.3.2: when allocating available network capacity among in Section 7.4.2: when allocating available network capacity among
Connections in a Connection Group, sends on Connections with higher Connections in a Connection Group, sends on Connections with higher
Priority values will be prioritized over sends on Connections with Priority values will be prioritized over sends on Connections with
lower Priority values. An ideal transport system implementation lower Priority values. An ideal transport system implementation
would assign each Connection the capacity share (M-N) x C / M, where would assign each Connection the capacity share (M-N) x C / M, where
N is the Connection's Priority value, M is the maximum Priority value N is the Connection's Priority value, M is the maximum Priority value
used by all Connections in the group and C is the total available used by all Connections in the group and C is the total available
capacity. However, the Priority setting is purely advisory, and no capacity. However, the Priority setting is purely advisory, and no
guarantees are given about the way capacity is shared. Each guarantees are given about the way capacity is shared. Each
implementation is free to implement a way to share capacity that it implementation is free to implement a way to share capacity that it
sees fit. sees fit.
7. Sending Data 7. Sending Data
Once a Connection has been established, it can be used for sending Once a Connection has been established, it can be used for sending
data. Data is sent in terms of Messages, which allow the application data. Data is sent as Messages, which allow the application to
to communicate the boundaries of the data being transferred. By communicate the boundaries of the data being transferred. By
default, Send enqueues a complete Message, and takes optional per- default, Send enqueues a complete Message, and takes optional per-
Message properties (see Section 7.1). All Send actions are Message properties (see Section 7.1). All Send actions are
asynchronous, and deliver events (see Section 7.2). Sending partial asynchronous, and deliver events (see Section 7.3). Sending partial
Messages for streaming large data is also supported (see Messages for streaming large data is also supported (see
Section 7.4). Section 7.5).
Messages are sent on a Connection using the Send action: Messages are sent on a Connection using the Send action:
Connection.Send(messageData, messageContext?, endOfMessage?) messageContext := Connection.Send(messageData, messageContext?, endOfMessage?)
where messageData is the data object to send. The optional where messageData is the data object to send.
messageContext parameter supports per-message properties and is
described in Section 7.3. The optional endOfMessage parameter The optional messageContext parameter supports per-message properties
supports partial sending and is described in Section 7.4. and is described in Section 7.4. If provided, the Message Context
object returned is identical to the one that was passed.
The optional endOfMessage parameter supports partial sending and is
described in Section 7.5.
The MessageContext returned by Send can be used to identify send
events (see Section 7.3) related to a specific message or to inspect
meta-data related to the message sent.
7.1. Basic Sending 7.1. Basic Sending
The most basic form of sending on a connection involves enqueuing a The most basic form of sending on a connection involves enqueuing a
single Data block as a complete Message, with default Message single Data block as a complete Message, with default Message
Properties. Message data is created as an array of octets, and the Properties. Message data is transferred as an array of bytes, and
resulting object contains both the byte array and the length of the the resulting object contains both the byte array and the length of
array. the array.
messageData := "hello".octets() messageData := "hello".bytes()
Connection.Send(messageData) Connection.Send(messageData)
The interpretation of a Message to be sent is dependent on the The interpretation of a Message to be sent is dependent on the
implementation, and on the constraints on the Protocol Stacks implied implementation, and on the constraints on the Protocol Stacks implied
by the Connection's transport properties. For example, a Message may by the Connection's transport properties. For example, a Message may
be a single datagram for UDP Connections; or an HTTP Request for HTTP be a single datagram for UDP Connections; or an HTTP Request for HTTP
Connections. Connections.
Some transport protocols can deliver arbitrarily sized Messages, but Some transport protocols can deliver arbitrarily sized Messages, but
other protocols constrain the maximum Message size. Applications can other protocols constrain the maximum Message size. Applications can
query the protocol property Maximum Message Size on Send to determine query the Connection Property "Maximum Message size on send"
the maximum size allowed for a single Message. If a Message is too (Section 11.1.8) to determine the maximum size allowed for a single
large to fit in the Maximum Message Size for the Connection, the Send Message. If a Message is too large to fit in the Maximum Message
will fail with a SendError event (Section 7.2.3). For example, it is Size for the Connection, the Send will fail with a SendError event
invalid to send a Message over a UDP connection that is larger than (Section 7.3.3). For example, it is invalid to send a Message over a
the available datagram sending size. UDP connection that is larger than the available datagram sending
size.
7.2. Send Events 7.2. Sending Replies
When a message is sent in response to a message received, the
application may use the Message Context of the received Message to
construct a Message Context for the reply.
replyMessageContext := requestMessageContext.reply()
By using the "replyMessageContext", the transport system is informed
that the message to be sent is a response and can map the response to
the same underlying transport connection or stream the request was
received from. The concept of Message Contexts is described in
Section 9.
7.3. Send Events
Like all Actions in this interface, the Send Action is asynchronous. Like all Actions in this interface, the Send Action is asynchronous.
There are several events that can be delivered in response to Sending There are several Events that can be delivered in response to Sending
a Message. a Message.
Note that if partial Sends are used (Section 7.4), there will still Note that if partial Sends are used (Section 7.5), there will still
be exactly one Send Event delivered for each call to Send. For be exactly one Send Event delivered for each call to Send. For
example, if a Message expired while two requests to Send data for example, if a Message expired while two requests to Send data for
that Message are outstanding, there will be two Expired events that Message are outstanding, there will be two Expired events
delivered. delivered.
7.2.1. Sent 7.3.1. Sent
Connection -> Sent<msgRef> Connection -> Sent<messageContext>
The Sent Event occurs when a previous Send Action has completed, The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the through the underlying Protocol Stack and is no longer the
responsibility of the implementation of this interface. The exact responsibility of this interface. The exact disposition of the
disposition of the Message (i.e., whether it has actually been Message (i.e., whether it has actually been transmitted, moved into a
transmitted, moved into a buffer on the network interface, moved into buffer on the network interface, moved into a kernel buffer, and so
a kernel buffer, and so on) when the Sent Event occurs is on) when the Sent Event occurs is implementation-specific. The Sent
implementation-specific. The Sent Event contains an implementation- Event contains an implementation-specific reference to the Message to
specific reference to the Message to which it applies. which it applies.
Sent Events allow an application to obtain an understanding of the Sent Events allow an application to obtain an understanding of the
amount of buffering it creates. That is, if an application calls the amount of buffering it creates. That is, if an application calls the
Send Action multiple times without waiting for a Sent Event, it has Send Action multiple times without waiting for a Sent Event, it has
created more buffer inside the transport system than an application created more buffer inside the transport system than an application
that always waits for the Sent Event before calling the next Send that always waits for the Sent Event before calling the next Send
Action. Action.
7.2.2. Expired 7.3.2. Expired
Connection -> Expired<msgRef> Connection -> Expired<messageContext>
The Expired Event occurs when a previous Send Action expired before The Expired Event occurs when a previous Send Action expired before
completion; i.e. when the Message was not sent before its Lifetime completion; i.e. when the Message was not sent before its Lifetime
(see Section 7.3.1) expired. This is separate from SendError, as it (see Section 7.4.1) expired. This is separate from SendError, as it
is an expected behavior for partially reliable transports. The is an expected behavior for partially reliable transports. The
Expired Event contains an implementation-specific reference to the Expired Event contains an implementation-specific reference to the
Message to which it applies. Message to which it applies.
7.2.3. SendError 7.3.3. SendError
Connection -> SendError<msgRef> Connection -> SendError<messageContext>
A SendError occurs when a Message could not be sent due to an error A SendError occurs when a Message could not be sent due to an error
condition: an attempt to send a Message which is too large for the condition: an attempt to send a Message which is too large for the
system and Protocol Stack to handle, some failure of the underlying system and Protocol Stack to handle, some failure of the underlying
Protocol Stack, or a set of Message Properties not consistent with Protocol Stack, or a set of Message Properties not consistent with
the Connection's transport properties. The SendError contains an the Connection's transport properties. The SendError contains an
implementation-specific reference to the Message to which it applies. implementation-specific reference to the Message to which it applies.
7.3. Message Properties 7.4. Message Properties
Applications may need to annotate the Messages they send with extra Applications may need to annotate the Messages they send with extra
information to control how data is scheduled and processed by the information to control how data is scheduled and processed by the
transport protocols in the Connection. A MessageContext object transport protocols in the Connection. Therefore a message context
contains properties for sending Messages, and can be passed to the containing these properties can be passed to the Send Action. For
Send Action. Note that these properties are per-Message, not per- other uses of the message context, see Section 9.
Send if partial Messages are sent (Section 7.4). All data blocks
associated with a single Message share properties. For example, it
would not make sense to have the beginning of a Message expire, but
allow the end of a Message to still be sent.
messageData := "hello".octets() Note that message properties are per-Message, not per-Send if partial
Messages are sent (Section 7.5). All data blocks associated with a
single Message share properties specified in the Message Contexts.
For example, it would not make sense to have the beginning of a
Message expire, but allow the end of a Message to still be sent.
A MessageContext object contains metadata for Messages to be sent or
received.
messageData := "hello".bytes()
messageContext := NewMessageContext() messageContext := NewMessageContext()
messageContext.add(parameter, value) messageContext.add(parameter, value)
Connection.Send(messageData, messageContext) Connection.Send(messageData, messageContext)
The simpler form of Send that does not take any messageContext is The simpler form of Send, which does not take any messageContext, is
equivalent to passing a default MessageContext with not values added. equivalent to passing a default MessageContext without adding any
Message Properties to it.
If an application wants to override Message Properties for a specific If an application wants to override Message Properties for a specific
message, it can acquire an empty MessageContext Object and add all message, it can acquire an empty MessageContext Object and add all
desired Message Properties to that Object. It can then reuse the desired Message Properties to that Object. It can then reuse the
same messageContext Object for sending multiple Messages with the same messageContext Object for sending multiple Messages with the
same properties. same properties.
Properties may be added to a MessageContext object only before the Properties may be added to a MessageContext object only before the
context is used for sending. Once a messageContext has been used context is used for sending. Once a messageContext has been used
with a Send call, modifying any of its properties is invalid. with a Send call, modifying any of its properties is invalid.
Message Properties may be inconsistent with the properties of the Message Properties may be inconsistent with the properties of the
Protocol Stacks underlying the Connection on which a given Message is Protocol Stacks underlying the Connection on which a given Message is
sent. For example, a Connection must provide reliability to allow sent. For example, a Connection must provide reliability to allow
setting an infinitie value for the lifetime property of a Message. setting an infinitie value for the lifetime property of a Message.
Sending a Message with Message Properties inconsistent with the Sending a Message with Message Properties inconsistent with the
Selection Properties of the Connection yields an error. Selection Properties of the Connection yields an error.
The following Message Properties are supported: The following Message Properties are supported:
7.3.1. Lifetime 7.4.1. Lifetime
Name: msg-lifetime Name: msg-lifetime
Type: Integer Type: Integer
Recommended default: infinite
Lifetime specifies how long a particular Message can wait to be sent Lifetime specifies how long a particular Message can wait to be sent
to the remote endpoint before it is irrelevant and no longer needs to to the remote endpoint before it is irrelevant and no longer needs to
be (re-)transmitted. This is a hint to the transport system - it is be (re-)transmitted. This is a hint to the transport system - it is
not guaranteed that a Message will not be sent when its Lifetime has not guaranteed that a Message will not be sent when its Lifetime has
expired. expired.
Setting a Message's Lifetime to infinite indicates that the Setting a Message's Lifetime to infinite indicates that the
application does not wish to apply a time constraint on the application does not wish to apply a time constraint on the
transmission of the Message, but it does not express a need for transmission of the Message, but it does not express a need for
reliable delivery; reliability is adjustable per Message via the reliable delivery; reliability is adjustable per Message via the
"Reliable Data Transfer (Message)" property (see Section 7.3.7). The "Reliable Data Transfer (Message)" property (see Section 7.4.7). The
type and units of Lifetime are implementation-specific. type and units of Lifetime are implementation-specific.
7.3.2. Priority 7.4.2. Priority
Name: msg-prio Name: msg-prio
Type: Integer (non-negative) Type: Integer (non-negative)
Recommended default: 100
This property represents a hierarchy of priorities. It can specify This property represents a hierarchy of priorities. It can specify
the priority of a Message, relative to other Messages sent over the the priority of a Message, relative to other Messages sent over the
same Connection. same Connection.
A Message with Priority 0 will yield to a Message with Priority 1, A Message with Priority 0 will yield to a Message with Priority 1,
which will yield to a Message with Priority 2, and so on. Priorities which will yield to a Message with Priority 2, and so on. Priorities
may be used as a sender-side scheduling construct only, or be used to may be used as a sender-side scheduling construct only, or be used to
specify priorities on the wire for Protocol Stacks supporting specify priorities on the wire for Protocol Stacks supporting
prioritization. prioritization.
Note that this property is not a per-message override of the Note that this property is not a per-message override of the
connection Priority - see Section 9.1.3. Both Priority properties connection Priority - see Section 11.1.3. Both Priority properties
may interact, but can be used independently and be realized by may interact, but can be used independently and be realized by
different mechanisms. different mechanisms.
7.3.3. Ordered 7.4.3. Ordered
Name: msg-ordered Name: msg-ordered
Type: Boolean Type: Boolean
Default: true
If true, it specifies that the receiver-side transport protocol stack If true, it specifies that the receiver-side transport protocol stack
only deliver the Message to the receiving application after the only deliver the Message to the receiving application after the
previous ordered Message which was passed to the same Connection via previous ordered Message which was passed to the same Connection via
the Send Action, when such a Message exists. If false, the Message the Send Action, when such a Message exists. If false, the Message
may be delivered to the receiving application out of order. This may be delivered to the receiving application out of order. This
property is used for protocols that support preservation of data property is used for protocols that support preservation of data
ordering, see Section 5.2.4, but allow out-of-order delivery for ordering, see Section 5.2.4, but allow out-of-order delivery for
certain messages. certain messages.
7.3.4. Idempotent 7.4.4. Idempotent
Name: idempotent Name: idempotent
Type: Boolean Type: Boolean
Default: false
If true, it specifies that a Message is safe to send to the remote If true, it specifies that a Message is safe to send to the remote
endpoint more than once for a single Send Action. It is used to mark endpoint more than once for a single Send Action. It is used to mark
data safe for certain 0-RTT establishment techniques, where data safe for certain 0-RTT establishment techniques, where
retransmission of the 0-RTT data may cause the remote application to retransmission of the 0-RTT data may cause the remote application to
receive the Message multiple times. receive the Message multiple times.
7.3.5. Final Note that for protocols that do not protect against duplicated
messages, e.g., UDP, all messages MUST be marked as Idempotent. In
order to enable protocol selection to choose such a protocol,
Idempotent MUST be added to the TransportProperties passed to the
Preconnection. If such a protocol was chosen, disabling Idempotent
on individual messages MUST result in a SendError.
7.4.5. Final
Type: Boolean Type: Boolean
Name: final Name: final
Default: false
If true, this Message is the last one that the application will send If true, this Message is the last one that the application will send
on a Connection. This allows underlying protocols to indicate to the on a Connection. This allows underlying protocols to indicate to the
Remote Endpoint that the Connection has been effectively closed in Remote Endpoint that the Connection has been effectively closed in
the sending direction. For example, TCP-based Connections can send a the sending direction. For example, TCP-based Connections can send a
FIN once a Message marked as Final has been completely sent, FIN once a Message marked as Final has been completely sent,
indicated by marking endOfMessage. Protocols that do not support indicated by marking endOfMessage. Protocols that do not support
signalling the end of a Connection in a given direction will ignore signalling the end of a Connection in a given direction will ignore
this property. this property.
Note that a Final Message must always be sorted to the end of a list Note that a Final Message must always be sorted to the end of a list
of Messages. The Final property overrides Priority and any other of Messages. The Final property overrides Priority and any other
property that would re-order Messages. If another Message is sent property that would re-order Messages. If another Message is sent
after a Message marked as Final has already been sent on a after a Message marked as Final has already been sent on a
Connection, the Send Action for the new Message will cause a Connection, the Send Action for the new Message will cause a
SendError Event. SendError Event.
7.3.6. Corruption Protection Length 7.4.6. Corruption Protection Length
Name: msg-checksum-len Name: msg-checksum-len
Type: Integer (non-negative with -1 as special value) Type: Integer (non-negative with -1 as special value)
This property specifies the length of the section of the Message, Default: full coverage
starting from byte 0, that the application requires to be delivered
without corruption due to lower layer errors. It is used to specify
options for simple integrity protection via checksums. By default,
the entire Message is protected by a checksum. A value of 0 means
that no checksum is required, and a special value (e.g. -1) can be
used to indicate the default. Only full coverage is guaranteed, any
other requests are advisory.
7.3.7. Reliable Data Transfer (Message) This property specifies the minimum length of the section of the
Message, starting from byte 0, that the application requires to be
delivered without corruption due to lower layer errors. It is used
to specify options for simple integrity protection via checksums. A
value of 0 means that no checksum is required, and -1 means that the
entire Message is protected by a checksum. Only full coverage is
guaranteed, any other requests are advisory.
7.4.7. Reliable Data Transfer (Message)
Name: msg-reliable Name: msg-reliable
Type: Boolean Type: Boolean
Default: true
When true, this property specifies that a message should be sent in When true, this property specifies that a message should be sent in
such a way that the transport protocol ensures all data is received such a way that the transport protocol ensures all data is received
on the other side without corruption. Changing the 'Reliable Data on the other side without corruption. Changing the 'Reliable Data
Transfer' property on Messages is only possible for Connections that Transfer' property on Messages is only possible for Connections that
were established with the Selection Property 'Reliable Data Transfer were established with the Selection Property 'Reliable Data Transfer
(Connection)' enabled. When this is not the case, changing it will (Connection)' enabled. When this is not the case, changing it will
generate an error. Disabling this property indicates that the generate an error. Disabling this property indicates that the
transport system may disable retransmissions or other reliability transport system may disable retransmissions or other reliability
mechanisms for this particular Message, but such disabling is not mechanisms for this particular Message, but such disabling is not
guaranteed. guaranteed.
7.3.8. Message Capacity Profile Override 7.4.8. Message Capacity Profile Override
Name: msg-capacity-profile Name: msg-capacity-profile
Type: Enumeration Type: Enumeration
This enumerated property specifies the application's preferred This enumerated property specifies the application's preferred
tradeoffs for sending this Message; it is a per-Message override of tradeoffs for sending this Message; it is a per-Message override of
the Capacity Profile protocol and path selection property (see the Capacity Profile protocol and path selection property (see
Section 9.1.10). Section 11.1.10).
The following values are valid for Transmission Profile: The following values are valid for Transmission Profile:
Default: No special optimizations of the tradeoff between delay, Default: No special optimizations of the tradeoff between delay,
delay variation, and bandwidth efficiency should be made when delay variation, and bandwidth efficiency should be made when
sending this message. sending this message.
Low Latency: Response time (latency) should be optimized at the Low Latency: Response time (latency) should be optimized at the
expense of efficiently using the available capacity when sending expense of efficiently using the available capacity when sending
this message. This can be used by the system to disable the this message. This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's coalescing of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; to signal a endpoint when supported by the underlying transport; to signal a
preference for lower-latency, higher-loss treatment; and so on. preference for lower-latency, higher-loss treatment; and so on.
[TODO: This is inconsistent with {prop-cap-profile}} - needs to be [TODO: This is inconsistent with {prop-cap-profile}} - needs to be
fixed] fixed]
7.3.9. Singular Transmission 7.4.9. Singular Transmission
Name: singular-transmission Name: singular-transmission
Type: Boolean Type: Boolean
Default: false
This property specifies that a message should be sent and received as This property specifies that a message should be sent and received as
a single packet without transport-layer segmentation or network-layer a single packet without transport-layer segmentation or network-layer
fragmentation. Attempts to send a message with this property set fragmentation. Attempts to send a message with this property set
with a size greater to the transport's current estimate of its with a size greater to the transport's current estimate of its
maximum transmission segment size will result in a "SendError". When maximum transmission segment size will result in a "SendError". When
used with transports supporting this functionality and running over used with transports supporting this functionality and running over
IP version 4, the Don't Fragment bit will be set. IP version 4, the Don't Fragment bit will be set.
7.4. Partial Sends 7.5. Partial Sends
It is not always possible for an application to send all data It is not always possible for an application to send all data
associated with a Message in a single Send Action. The Message data associated with a Message in a single Send Action. The Message data
may be too large for the application to hold in memory at one time, may be too large for the application to hold in memory at one time,
or the length of the Message may be unknown or unbounded. or the length of the Message may be unknown or unbounded.
Partial Message sending is supported by passing an endOfMessage Partial Message sending is supported by passing an endOfMessage
boolean parameter to the Send Action. This value is always true by boolean parameter to the Send Action. This value is always true by
default, and the simpler forms of Send are equivalent to passing true default, and the simpler forms of Send are equivalent to passing true
for endOfMessage. for endOfMessage.
The following example sends a Message in two separate calls to Send. The following example sends a Message in two separate calls to Send.
messageContext := NewMessageContext() messageContext := NewMessageContext()
messageContext.add(parameter, value) messageContext.add(parameter, value)
messageData := "hel".octets() messageData := "hel".bytes()
endOfMessage := false endOfMessage := false
Connection.Send(messageData, messageContext, endOfMessage) Connection.Send(messageData, messageContext, endOfMessage)
messageData := "lo".octets() messageData := "lo".bytes()
endOfMessage := true endOfMessage := true
Connection.Send(messageData, messageContext, endOfMessage) Connection.Send(messageData, messageContext, endOfMessage)
All data sent with the same MessageContext object will be treated as All data sent with the same MessageContext object will be treated as
belonging to the same Message, and will constitute an in-order series belonging to the same Message, and will constitute an in-order series
until the endOfMessage is marked. Once the end of the Message is until the endOfMessage is marked. Once the end of the Message is
marked, the MessageContext object may be re-used as a new Message marked, the MessageContext object may be re-used as a new Message
with identical parameters. with identical parameters.
7.5. Batching Sends 7.6. Batching Sends
In order to reduce the overhead of sending multiple small Messages on To reduce the overhead of sending multiple small Messages on a
a Connection, the application may want to batch several Send actions Connection, the application may want to batch several Send actions
together. This provides a hint to the system that the sending of together. This provides a hint to the system that the sending of
these Messages should be coalesced when possible, and that sending these Messages should be coalesced when possible, and that sending
any of the batched Messages may be delayed until the last Message in any of the batched Messages may be delayed until the last Message in
the batch is enqueued. the batch is enqueued.
Connection.Batch( Connection.Batch(
Connection.Send(messageData) Connection.Send(messageData)
Connection.Send(messageData) Connection.Send(messageData)
) )
7.6. Send on Active Open: InitiateWithSend 7.7. Send on Active Open: InitiateWithSend
For application-layer protocols where the Connection initiator also For application-layer protocols where the Connection initiator also
sends the first message, the InitiateWithSend() action combines sends the first message, the InitiateWithSend() action combines
Connection initiation with a first Message sent: Connection initiation with a first Message sent:
Connection := Preconnection.InitiateWithSend(messageData, messageContext?, timeout?) Connection := Preconnection.InitiateWithSend(messageData, messageContext?, timeout?)
Whenever possible, a messageContext should be provided to declare the Whenever possible, a messageContext should be provided to declare the
message passed to InitiateWithSend as idempotent. This allows the message passed to InitiateWithSend as idempotent. This allows the
transport system to make use of 0-RTT establishment in case this is transport system to make use of 0-RTT establishment in case this is
skipping to change at page 37, line 15 skipping to change at page 38, line 15
Neither partial sends nor send batching are supported by Neither partial sends nor send batching are supported by
InitiateWithSend(). InitiateWithSend().
The Events that may be sent after InitiateWithSend() are equivalent The Events that may be sent after InitiateWithSend() are equivalent
to those that would be sent by an invocation of Initate() followed to those that would be sent by an invocation of Initate() followed
immediately by an invocation of Send(), with the caveat that a send immediately by an invocation of Send(), with the caveat that a send
failure that occurs because the Connection could not be established failure that occurs because the Connection could not be established
will not result in a SendError separate from the InitiateError will not result in a SendError separate from the InitiateError
signaling the failure of Connection establishment. signaling the failure of Connection establishment.
7.7. Sender-side Framing
Sender-side framing allows a caller to provide the interface with a
function that takes a Message of an appropriate application-layer
type and returns an array of octets, the on-the-wire representation
of the Message to be handed down to the Protocol Stack. It consists
of a Framer Object with a single Action, Frame. Since the Framer
depends on the protocol used at the application layer, it is bound to
the Preconnection during the pre-establishment phase:
Preconnection.FrameWith(Framer)
OctetArray := Framer.Frame(messageData)
Sender-side framing is a convenience feature of the interface, for
parity with receiver-side framing (see Section 8.4).
8. Receiving Data 8. Receiving Data
Once a Connection is established, it can be used for receiving data. Once a Connection is established, it can be used for receiving data.
As with sending, data is received in terms of Messages. Receiving is As with sending, data is received in terms of Messages. Receiving is
an asynchronous operation, in which each call to Receive enqueues a an asynchronous operation, in which each call to Receive enqueues a
request to receive new data from the connection. Once data has been request to receive new data from the connection. Once data has been
received, or an error is encountered, an event will be delivered to received, or an error is encountered, an event will be delivered to
complete the Receive request (see Section 8.2). complete the Receive request (see Section 8.2).
As with sending, the type of the Message to be passed is dependent on As with sending, the type of the Message to be passed is dependent on
skipping to change at page 38, line 4 skipping to change at page 38, line 35
the implementation, and on the constraints on the Protocol Stacks the implementation, and on the constraints on the Protocol Stacks
implied by the Connection's transport parameters. implied by the Connection's transport parameters.
8.1. Enqueuing Receives 8.1. Enqueuing Receives
Receive takes two parameters to specify the length of data that an Receive takes two parameters to specify the length of data that an
application is willing to receive, both of which are optional and application is willing to receive, both of which are optional and
have default values if not specified. have default values if not specified.
Connection.Receive(minIncompleteLength?, maxLength?) Connection.Receive(minIncompleteLength?, maxLength?)
By default, Receive will try to deliver complete Messages in a single By default, Receive will try to deliver complete Messages in a single
event (Section 8.2.1). event (Section 8.2.1).
The application can set a minIncompleteLength value to indicates the The application can set a minIncompleteLength value to indicates the
smallest partial Message data size in bytes that should be delivered smallest partial Message data size in bytes that should be delivered
in response to this Receive. By default, this value is infinite, in response to this Receive. By default, this value is infinite,
which means that only complete Messages should be delivered (see which means that only complete Messages should be delivered (see
Section 8.2.2 and Section 8.4 for more information on how this is Section 8.2.2 and Section 10.6 for more information on how this is
accomplished). If this value is set to some smaller value, the accomplished). If this value is set to some smaller value, the
associated receive event will be triggered only when at least that associated receive event will be triggered only when at least that
many bytes are available, or the Message is complete with fewer many bytes are available, or the Message is complete with fewer
bytes, or the system needs to free up memory. Applications should bytes, or the system needs to free up memory. Applications should
always check the length of the data delivered to the receive event always check the length of the data delivered to the receive event
and not assume it will be as long as minIncompleteLength in the case and not assume it will be as long as minIncompleteLength in the case
of shorter complete Messages or memory issues. of shorter complete Messages or memory issues.
The maxLength argument indicates the maximum size of a Message in The maxLength argument indicates the maximum size of a Message in
bytes the application is currently prepared to receive. The default bytes the application is currently prepared to receive. The default
skipping to change at page 38, line 46 skipping to change at page 39, line 31
provide backpressure to the transport stack when it is temporarily provide backpressure to the transport stack when it is temporarily
not ready to receive messages. not ready to receive messages.
8.2.1. Received 8.2.1. Received
Connection -> Received<messageData, messageContext> Connection -> Received<messageData, messageContext>
A Received event indicates the delivery of a complete Message. It A Received event indicates the delivery of a complete Message. It
contains two objects, the received bytes as messageData, and the contains two objects, the received bytes as messageData, and the
metadata and properties of the received Message as messageContext. metadata and properties of the received Message as messageContext.
See Section 8.3 for details about the received context.
The messageData object provides access to the bytes that were The messageData object provides access to the bytes that were
received for this Message, along with the length of the byte array. received for this Message, along with the length of the byte array.
The messageContext is provided to enable retrieving metadata about
the message and referring to the message, e.g., to send replies and
map responses to their requests. See Section 9 for details.
See Section 8.4 for handling Message framing in situations where the See Section 10.6 for handling Message framing in situations where the
Protocol Stack provides octet-stream transport only. Protocol Stack only provides a byte-stream transport.
8.2.2. ReceivedPartial 8.2.2. ReceivedPartial
Connection -> ReceivedPartial<messageData, messageContext, endOfMessage> Connection -> ReceivedPartial<messageData, messageContext, endOfMessage>
If a complete Message cannot be delivered in one event, one part of If a complete Message cannot be delivered in one event, one part of
the Message may be delivered with a ReceivedPartial event. In order the Message may be delivered with a ReceivedPartial event. In order
to continue to receive more of the same Message, the application must to continue to receive more of the same Message, the application must
invoke Receive again. invoke Receive again.
skipping to change at page 39, line 33 skipping to change at page 40, line 17
If the minIncompleteLength in the Receive request was set to be If the minIncompleteLength in the Receive request was set to be
infinite (indicating a request to receive only complete Messages), infinite (indicating a request to receive only complete Messages),
the ReceivedPartial event may still be delivered if one of the the ReceivedPartial event may still be delivered if one of the
following conditions is true: following conditions is true:
o the underlying Protocol Stack supports message boundary o the underlying Protocol Stack supports message boundary
preservation, and the size of the Message is larger than the preservation, and the size of the Message is larger than the
buffers available for a single message; buffers available for a single message;
o the underlying Protocol Stack does not support message boundary o the underlying Protocol Stack does not support message boundary
preservation, and the deframer (see Section 8.4) cannot determine preservation, and the Message Framer (see Section 10.6) cannot
the end of the message using the buffer space it has available; or determine the end of the message using the buffer space it has
available; or
o the underlying Protocol Stack does not support message boundary o the underlying Protocol Stack does not support message boundary
preservation, and no deframer was supplied by the application preservation, and no Message Framer was supplied by the
application
Note that in the absence of message boundary preservation or Note that in the absence of message boundary preservation or a
deframing, all bytes received on the Connection will be represented Message Framer, all bytes received on the Connection will be
as one large message of indeterminate length. represented as one large Message of indeterminate length.
8.2.3. ReceiveError 8.2.3. ReceiveError
Connection -> ReceiveError<messageContext> Connection -> ReceiveError<messageContext>
A ReceiveError occurs when data is received by the underlying A ReceiveError occurs when data is received by the underlying
Protocol Stack that cannot be fully retrieved or deframed, or when Protocol Stack that cannot be fully retrieved or parsed, or when some
some other indication is received that reception has failed. Such other indication is received that reception has failed. Such
conditions that irrevocably lead to the termination of the Connection conditions that irrevocably lead to the termination of the Connection
are signaled using ConnectionError instead (see Section 10). are signaled using ConnectionError instead (see Section 12).
The ReceiveError event passes an optional associated MessageContext. The ReceiveError event passes an optional associated MessageContext.
This may indicate that a Message that was being partially received This may indicate that a Message that was being partially received
previously, but had not completed, encountered an error and will not previously, but had not completed, encountered an error and will not
be completed. be completed.
8.3. Message Receive Context 8.3. Receive Message Properties
Each Received Message Context may contain metadata from protocols in Each Message Context may contain metadata from protocols in the
the Protocol Stack; which metadata is available is Protocol Stack Protocol Stack; which metadata is available is Protocol Stack
dependent. The following metadata values are supported: dependent. These are exposed though additional read-only Message
Properties that can be queried from the MessageContext object (see
Section 9) passed by the receive event. The following metadata
values are supported:
8.3.1. ECN 8.3.1. ECN
When available, Message metadata carries the value of the Explicit When available, Message metadata carries the value of the Explicit
Congestion Notification (ECN) field. This information can be used Congestion Notification (ECN) field. This information can be used
for logging and debugging purposes, and for building applications for logging and debugging purposes, and for building applications
which need access to information about the transport internals for which need access to information about the transport internals for
their own operation. their own operation.
8.3.2. Early Data 8.3.2. Early Data
skipping to change at page 40, line 42 skipping to change at page 41, line 31
Thus, receivers may wish to perform additional checks for early data Thus, receivers may wish to perform additional checks for early data
to ensure it is idempotent or not replayed. If TLS 1.3 is available to ensure it is idempotent or not replayed. If TLS 1.3 is available
and the recipient Message was sent as part of early data, the and the recipient Message was sent as part of early data, the
corresponding metadata carries a flag indicating as such. If early corresponding metadata carries a flag indicating as such. If early
data is enabled, applications should check this metadata field for data is enabled, applications should check this metadata field for
Messages received during connection establishment and respond Messages received during connection establishment and respond
accordingly. accordingly.
8.3.3. Receiving Final Messages 8.3.3. Receiving Final Messages
The Received Message Context can indicate whether or not this Message The Message Context can indicate whether or not this Message is the
is the Final Message on a Connection. For any Message that is marked Final Message on a Connection. For any Message that is marked as
as Final, the application can assume that there will be no more Final, the application can assume that there will be no more Messages
Messages received on the Connection once the Message has been received on the Connection once the Message has been completely
completely delivered. This corresponds to the Final property that delivered. This corresponds to the Final property that may be marked
may be marked on a sent Message Section 7.3.5. on a sent Message Section 7.4.5.
Some transport protocols and peers may not support signaling of the Some transport protocols and peers may not support signaling of the
Final property. Applications therefore should not rely on receiving Final property. Applications therefore should not rely on receiving
a Message marked Final to know that the other endpoint is done a Message marked Final to know that the other endpoint is done
sending on a connection. sending on a connection.
Any calls to Receive once the Final Message has been delivered will Any calls to Receive once the Final Message has been delivered will
result in errors. result in errors.
8.4. Receiver-side De-framing over Stream Protocols 9. Message Contexts
The Receive Event is intended to be fired once per application-layer Using the MessageContext object, the application can set and retrieve
Message sent by the remote endpoint; i.e., it is a desired property meta-data of the message, including Message Properties (see
of this interface that a Send at one end of a Connection maps to Section 7.4) and framing meta-data (see Section 10.3). Therefore, a
exactly one Receive on the other end. This is possible with Protocol MessageContext object can be passed to the Send action and is retuned
Stacks that provide message boundary preservation, but is not the by each Send and Receive related events.
case over Protocol Stacks that provide a simple octet stream
transport.
For preserving message boundaries over stream transports, this Message properties can be set and queried using the Message Context:
interface provides receiver-side de-framing. This facility is based
on the observation that, since many of our current application
protocols evolved over TCP, which does not provide message boundary
preservation, and since many of these protocols require message
boundaries to function, each application layer protocol has defined
its own framing. A Deframer allows an application to push this de-
framing down into the interface, in order to transform an octet
stream into a sequence of Messages.
Concretely, receiver-side de-framing allows a caller to provide the MessageContext.add(scope?, parameter, value)
interface with a function that takes an octet stream, as provided by PropertyValue := MessageContext.get(scope?, property)
the underlying Protocol Stack, reads and returns a single Message of
an appropriate type for the application and platform, and leaves the
octet stream at the start of the next Message to deframe. It
consists of a Deframer Object with a single Action, Deframe. Since
the Deframer depends on the protocol used at the application layer,
it is bound to the Preconnection during the pre-establishment phase:
Preconnection.DeframeWith(Deframer) To get or set Message Properties, the optional scope parameter is
left empty, for framing meta-data, the framer is passed.
{messageData} := Deframer.Deframe(OctetStream) For MessageContexts returned by send events (see Section 7.3) and
receive events (see Section 8.2), the application can query
information about the local and remote endpoint:
9. Managing Connections RemoteEndpoint := MessageContext.GetRemoteEndpoint()
LocalEndpoint := MessageContext.GetLocalEndpoint()
Message Contexts can also be used to send messages that are flagged
as a reply to other messages, see Section 7.2 for details. If the
message received was send by the remote endpoint as a reply to an
earlier message and the transports provides this information, the
MessageContext of the original request can be accessed using the
Message Context of the reply:
RequestMessageContext := MessageContext.GetOriginalRequest()
10. Message Framers
Message Framers are pieces of code that define simple transformations
between application Message data and raw transport protocol data. A
Framer can encapsulate or encode outbound Messages, and decapsulate
or decode inbound data into Messages.
Message Framers allow message boundaries to be preserved when using a
Connection object, even when using byte-stream transports. This
facility is designed based on the fact that many of the current
application protocols evolved over TCP, which does not provide
message boundary preservation, and since many of these protocols
require message boundaries to function, each application layer
protocol has defined its own framing.
While many protocols can be represented as Message Framers, for the
purposes of the Transport Services interface these are ways for
applications or application frameworks to define their own Message
parsing to be included within a Connection's Protocol Stack. As an
example, TLS can serve the purpose of framing data over TCP, but is
exposed as a protocol natively supported by the Transport Services
interface.
Most Message Framers fall into one of two categories: - Header-
prefixed record formats, such as a basic Type-Length-Value (TLV)
structure - Delimeter-separated formats, such as HTTP/1.1.
Note that while Message Framers add the most value when placed above
a protocol that otherwise does not preserve message boundaries, they
can also be used with datagram- or message-based protocols. In these
cases, they add an additional transformation to further encode or
encapsulate, and can potentially support packing multiple
application-layer Messages into individual transport datagrams.
10.1. Defining Message Framers
A Message Framer is primarily defined by the set of code that handles
events for a framer implementation, specifically how it handles
inbound and outbound data parsing.
Applications can instantiate a Message Framer upon which they will
receive framing events, or use a Message Framer defined by another
library.
framer := NewMessageFramer()
Message Framer objects will deliver events to code that is written
either as part of the application or a helper library. This piece of
code will be referred to as the "framer implementation".
10.2. Adding Message Framers to Connections
The Message Framer object can be added to one or more Preconnections
to run on top of transport protocols. Multiple Framers may be added.
If multiple Framers are added, the last one added runs first when
framing outbound messages, and last when parsing inbound data.
Preconnection.AddFramer(framer)
Framers have the ability to also dynamically modify Protocol Stacks,
as described in Section 10.4.
10.3. Framing Meta-Data
When sending Messages, applications can add specific Message values
to a MessageContext (Section 9) that is intended for a Framer. This
can be used, for example, to set the type of a Message for a TLV
format. The namespace of values is custom for each unique Message
Framer.
messageContext := NewMessageContext()
messageContext.add(framer, key, value)
Connection.Send(messageData, messageContext)
When an application receives a MessageContext in a Receive event, it
can also look to see if a value was set by a specific Message Framer.
messageContext.get(framer, key) -> value
10.4. Message Framer Lifetime
When a Connection establishment attempt begins, an event is delivered
to notify the framer implementation that a new Connection is being
created. Similarly, a stop event is delivered when a Connection is
being torn down. The framer implementation can use the Connection
object to look up specific properties of the Connection or the
network being used that may influence how to frame Messages.
MessageFramer -> Start(Connection)
MessageFramer -> Stop(Connection)
When Message Framer generates a "Start" event, the framer
implementation has the opportunity to start writing some data prior
to the Connection delivering its "Ready" event. This allows the
implementation to communicate control data to the remote endpoint
that can be used to parse Messages.
MessageFramer.MakeConnectionReady(Connection)
At any time if the implementation encounters a fatal error, it can
also cause the Connection to fail and provide an error.
MessageFramer.FailConnection(Connection, Error)
Before an implementation marks a Message Framer as ready, it can also
dynamically add a protocol or framer above it in the stack. This
allows protocols like STARTTLS, that need to add TLS conditionally,
to modify the Protocol Stack based on a handshake result.
otherFramer := NewMessageFramer()
MessageFramer.PrependFramer(Connection, otherFramer)
10.5. Sender-side Message Framing
Message Framers generate an event whenever a Connection sends a new
Message.
MessageFramer -> NewSentMessage<Connection, MessageData, MessageContext, IsEndOfMessage>
Upon receiving this event, a framer implementation is responsible for
performing any necessary transformations and sending the resulting
data to the next protocol. Implementations SHOULD ensure that there
is a way to pass the original data through without copying to improve
performance.
MessageFramer.Send(Connection, Data)
To provide an example, a simple protocol that adds a length as a
header would receive the "NewSentMessage" event, create a data
representation of the length of the Message data, and then send a
block of data that is the concatenation of the length header and the
original Message data.
10.6. Receiver-side Message Framing
In order to parse an received flow of data into Messages, the Message
Framer notifies the framer implementation whenever new data is
available to parse.
MessageFramer -> HandleReceivedData<Connection>
Upon receiving this event, the framer implementation can inspect the
inbound data. The data is parsed from a particular cursor
representing the unprocessed data. The application requests a
specific amount of data it needs to have available in order to parse.
If the data is not available, the parse fails.
MessageFramer.Parse(Connection, MinimumIncompleteLength, MaximumLength) -> (Data, MessageContext, IsEndOfMessage)
The framer implementation can directly advance the receive cursor
once it has parsed data to effectively discard data (for example,
discard a header once the content has been parsed).
To deliver a Message to the application, the framer implementation
can either directly deliever data that it has allocated, or deliver a
range of data directly from the underlying transport and
simulatenously advance the receive cursor.
MessageFramer.AdvanceReceiveCursor(Connection, Length)
MessageFramer.DeliverAndAdvanceReceiveCursor(Connection, MessageContext, Length, IsEndOfMessage)
MessageFramer.Deliver(Connection, MessageContext, Data, IsEndOfMessage)
Note that "MessageFramer.DeliverAndAdvanceReceiveCursor" allows the
framer implementation to earmark bytes as part of a Message even
before they are received by the transport. This allows the delivery
of very large Messages without requiring the implementation to
directly inspect all of the bytes.
To provide an example, a simple protocol that parses a length as a
header value would receive the "HandleReceivedData" event, and call
"Parse" with a minimum and maximum set to the length of the header
field. Once the parse succeeded, it would call
"AdvanceReceiveCursor" with the length of the header field, and then
call "DeliverAndAdvanceReceiveCursor" with the length of the body
that was parsed from the header, marking the new Message as complete.
11. Managing Connections
During pre-establishment and after establishment, connections can be During pre-establishment and after establishment, connections can be
configured and queried using Connection Properties, and asynchronous configured and queried using Connection Properties, and asynchronous
information may be available about the state of the connection via information may be available about the state of the connection via
Soft Errors. Soft Errors.
Connection Properties represent the configuration and state of the Connection Properties represent the configuration and state of the
selected Protocol Stack(s) backing a Connection. These Connection selected Protocol Stack(s) backing a Connection. These Connection
Properties may be Generic, applying regardless of transport protocol, Properties may be Generic, applying regardless of transport protocol,
or Specific, applicable to a single implementation of a single or Specific, applicable to a single implementation of a single
transport protocol stack. Generic Connection Properties are defined transport protocol stack. Generic Connection Properties are defined
in Section 9.1 below. Specific Protocol Properties are defined in a in Section 11.1 below. Specific Protocol Properties are defined in a
transport- and implementation-specific way, and must not be assumed transport- and implementation-specific way, and must not be assumed
to apply across different protocols. Attempts to set Specific to apply across different protocols. Attempts to set Specific
Protocol Properties on a protocol stack not containing that specific Protocol Properties on a protocol stack not containing that specific
protocol are simply ignored, and do not raise an error; however, too protocol are simply ignored, and do not raise an error; however, too
much reliance by an application on Specific Protocol Properties may much reliance by an application on Specific Protocol Properties may
significantly reduce the flexibility of a transport services significantly reduce the flexibility of a transport services
implementation. implementation.
The application can set and query Connection Properties on a per- The application can set and query Connection Properties on a per-
Connection basis. Connection Properties that are not read-only can Connection basis. Connection Properties that are not read-only can
skipping to change at page 42, line 34 skipping to change at page 47, line 6
Depending on the status of the connection, the queried Connection Depending on the status of the connection, the queried Connection
Properties will include different information: Properties will include different information:
o The connection state, which can be one of the following: o The connection state, which can be one of the following:
Establishing, Established, Closing, or Closed. Establishing, Established, Closing, or Closed.
o Whether the connection can be used to send data. A connection can o Whether the connection can be used to send data. A connection can
not be used for sending if the connection was created with the not be used for sending if the connection was created with the
Selection Property "Direction of Communication" set to Selection Property "Direction of Communication" set to
"unidirectional receive" or if a Message marked as "Final" was "unidirectional receive" or if a Message marked as "Final" was
sent over this connection, see Section 7.3.5. sent over this connection, see Section 7.4.5.
o Whether the connection can be used to receive data. A connection o Whether the connection can be used to receive data. A connection
can not be used for reading if the connection was created with the can not be used for reading if the connection was created with the
Selection Property "Direction of Communication" set to Selection Property "Direction of Communication" set to
"unidirectional send" or if a Message marked as "Final" was "unidirectional send" or if a Message marked as "Final" was
received, see Section 8.3.3. The latter is only supported by received, see Section 8.3.3. The latter is only supported by
certain transport protocols, e.g., by TCP as half-closed certain transport protocols, e.g., by TCP as half-closed
connection. connection.
o For Connections that are Establishing: Transport Properties that o For Connections that are Establishing: Transport Properties that
the application specified on the Preconnection, see Section 5.2. the application specified on the Preconnection, see Section 5.2.
o For Connections that are Established, Closing, or Closed: o For Connections that are Established, Closing, or Closed:
Selection (Section 5.2) and Connection Properties (Section 9.1) of Selection (Section 5.2) and Connection Properties (Section 11.1)
the actual protocols that were selected and instantiated. of the actual protocols that were selected and instantiated.
Selection Properties indicate whether or not the Connection has or Selection Properties indicate whether or not the Connection has or
offers a certain Selection Property. Note that the actually offers a certain Selection Property. Note that the actually
instantiated protocol stack may not match all Protocol Selection instantiated protocol stack may not match all Protocol Selection
Properties that the application specified on the Preconnection. Properties that the application specified on the Preconnection.
For example, a certain Protocol Selection Property that an For example, a certain Protocol Selection Property that an
application specified as Preferred may not actually be present in application specified as Preferred may not actually be present in
the chosen protocol stack because none of the currently available the chosen protocol stack because none of the currently available
transport protocols had this feature. transport protocols had this feature.
o For Connections that are Established, additional properties of the o For Connections that are Established, additional properties of the
path(s) in use. These properties can be derived from the local path(s) in use. These properties can be derived from the local
provisioning domain [RFC7556], measurements by the Protocol Stack, provisioning domain [RFC7556], measurements by the Protocol Stack,
or other sources. or other sources.
9.1. Generic Connection Properties 11.1. Generic Connection Properties
The Connection Properties defined as independent, and available on The Connection Properties defined as independent, and available on
all Connections are defined in the subsections below. all Connections are defined in the subsections below.
Note that many protocol properties have a corresponding selection Note that many protocol properties have a corresponding selection
property, which prefers protocols providing a specific transport property, which prefers protocols providing a specific transport
feature that controlled by that protocol property. [EDITOR'S NOTE: feature that controlled by that protocol property. [EDITOR'S NOTE:
todo: add these cross-references up to Section 5.2] todo: add these cross-references up to Section 5.2]
9.1.1. Retransmission threshold before excessive retransmission 11.1.1. Retransmission Threshold Before Excessive Retransmission
notification Notification
Name: retransmit-notify-threshold Name: retransmit-notify-threshold
Type: Integer Type: Integer
Default: -1
This property specifies after how many retransmissions to inform the This property specifies after how many retransmissions to inform the
application about "Excessive Retransmissions". application about "Excessive Retransmissions". The special value -1
means that this notification is disabled.
9.1.2. Required minimum coverage of the Corruption Protection for 11.1.2. Required Minimum Corruption Protection Coverage for Receiving
receiving
Name: recv-checksum-len Name: recv-checksum-len
Type: Integer Type: Integer
Default: -1
This property specifies the part of the received data that needs to This property specifies the part of the received data that needs to
be covered by a checksum. It is given in Bytes. A value of 0 means be covered by a checksum. It is given in Bytes. A value of 0 means
that no checksum is required, and a special value (e.g., -1) that no checksum is required, and the special value -1 indicates full
indicates full checksum coverage. checksum coverage.
9.1.3. Priority (Connection) 11.1.3. Priority (Connection)
Name: conn-prio Name: conn-prio
Type: Integer Type: Integer
Default: 100
This Property is a non-negative integer representing the relative This Property is a non-negative integer representing the relative
inverse priority of this Connection relative to other Connections in inverse priority of this Connection relative to other Connections in
the same Connection Group. It has no effect on Connections not part the same Connection Group. It has no effect on Connections not part
of a Connection Group. As noted in Section 6.4, this property is not of a Connection Group. As noted in Section 6.4, this property is not
entangled when Connections are cloned. entangled when Connections are cloned.
9.1.4. Timeout for aborting Connection 11.1.4. Timeout for Aborting Connection
Name: conn-timeout Name: conn-timeout
Type: Numeric Type: Numeric
Default: -1
This property specifies how long to wait before deciding that a This property specifies how long to wait before deciding that a
Connection has failed when trying to reliably deliver data to the Connection has failed when trying to reliably deliver data to the
destination. Adjusting this Property will only take effect when the destination. Adjusting this Property will only take effect when the
underlying stack supports reliability. underlying stack supports reliability. The special value -1 means
that this timeout is not scheduled to happen.
9.1.5. Connection group transmission scheduler 11.1.5. Connection Group Transmission Scheduler
Name: conn-scheduler Name: conn-scheduler
Type: Enumeration Type: Enumeration
Default: Weighted Fair Queueing (see Section 3.6 in [RFC8260])
This property specifies which scheduler should be used among This property specifies which scheduler should be used among
Connections within a Connection Group, see Section 6.4. The set of Connections within a Connection Group, see Section 6.4. The set of
schedulers can be taken from [I-D.ietf-tsvwg-sctp-ndata]. schedulers can be taken from [RFC8260].
9.1.6. Maximum message size concurrent with Connection establishment 11.1.6. Maximum Message Size Concurrent with Connection Establishment
Name: zero-rtt-msg-max-len Name: zero-rtt-msg-max-len
Type: Integer (read only) Type: Integer (read only)
This property represents the maximum Message size that can be sent This property represents the maximum Message size that can be sent
before or during Connection establishment, see also Section 7.3.4. before or during Connection establishment, see also Section 7.4.4.
It is given in Bytes. It is given in Bytes.
9.1.7. Maximum Message size before fragmentation or segmentation 11.1.7. Maximum Message Size Before Fragmentation or Segmentation
Name: singular-transmission-msg-max-len Name: singular-transmission-msg-max-len
Type: Integer (read only) Type: Integer (read only)
This property, if applicable, represents the maximum Message size This property, if applicable, represents the maximum Message size
that can be sent without incurring network-layer fragmentation or that can be sent without incurring network-layer fragmentation or
transport layer segmentation at the sender. transport layer segmentation at the sender.
9.1.8. Maximum Message size on send 11.1.8. Maximum Message Size on Send
Name: send-msg-max-len Name: send-msg-max-len
Type: Integer (read only) Type: Integer (read only)
This property represents the maximum Message size that can be sent. This property represents the maximum Message size that can be sent.
9.1.9. Maximum Message size on receive 11.1.9. Maximum Message Size on Receive
Name: recv-msg-max-len Name: recv-msg-max-len
Type: Integer (read only) Type: Integer (read only)
This numeric property represents the maximum Message size that can be This numeric property represents the maximum Message size that can be
received. received.
9.1.10. Capacity Profile 11.1.10. Capacity Profile
Name: conn-capacity-profile Name: conn-capacity-profile
This property specifies the desired network treatment for traffic This property specifies the desired network treatment for traffic
sent by the application and the tradeoffs the application is prepared sent by the application and the tradeoffs the application is prepared
to make in path and protocol selection to receive that desired to make in path and protocol selection to receive that desired
treatment. When the capacity profile is set to a value other than treatment. When the capacity profile is set to a value other than
Default, the transport system should select paths and profiles to Default, the transport system should select paths and profiles to
optimize for the capacity profile specified. The following values optimize for the capacity profile specified. The following values
are valid for the Capacity Profile: are valid for the Capacity Profile:
Default: The application makes no representation about its expected Default: The application makes no representation about its expected
capacity profile. No special optimizations of the tradeoff capacity profile. No special optimizations of the tradeoff
between delay, delay variation, and bandwidth efficiency should be between delay, delay variation, and bandwidth efficiency should be
made when selecting and configuring transport protocol stacks. made when selecting and configuring transport protocol stacks.
Transport system implementations that map the requested capacity Transport system implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing profile onto per-connection DSCP signaling without multiplexing
SHOULD assign the DSCP Default Forwarding [RFC2474] PHB; when the SHOULD assign the DSCP Default Forwarding [RFC2474] PHB; when the
Connection is multiplexed, the guidelines in section 6 of Connection is multiplexed, the guidelines in Section 6 of
[RFC7657] apply. [RFC7657] apply.
Scavenger: The application is not interactive. It expects to send Scavenger: The application is not interactive. It expects to send
and/or receive data without any urgency. This can, for example, and/or receive data without any urgency. This can, for example,
be used to select protocol stacks with scavenger transmission be used to select protocol stacks with scavenger transmission
control and/or to assign the traffic to a lower-effort service. control and/or to assign the traffic to a lower-effort service.
Transport system implementations that map the requested capacity Transport system implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing profile onto per-connection DSCP signaling without multiplexing
SHOULD assign the DSCP Less than Best Effort [LE-PHB] PHB; when SHOULD assign the DSCP Less than Best Effort [LE-PHB] PHB; when
the Connection is multiplexed, the guidelines in section 6 of the Connection is multiplexed, the guidelines in Section 6 of
[RFC7657] apply. [RFC7657] apply.
Low Latency/Interactive: The application is interactive, and prefers Low Latency/Interactive: The application is interactive, and prefers
loss to latency. Response time should be optimized at the expense loss to latency. Response time should be optimized at the expense
of bandwidth efficiency and delay variation when sending on this of bandwidth efficiency and delay variation when sending on this
connection. This can be used by the system to disable the connection. This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's coalescing of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; and so on. endpoint when supported by the underlying transport; and so on.
Transport system implementations that map the requested capacity Transport system implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing profile onto per-connection DSCP signaling without multiplexing
SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; when SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; when
the Connection is multiplexed, the guidelines in section 6 of the Connection is multiplexed, the guidelines in Section 6 of
[RFC7657] apply. [RFC7657] apply.
Low Latency/Non-Interactive: The application prefers loss to latency Low Latency/Non-Interactive: The application prefers loss to latency
but is not interactive. Response time should be optimized at the but is not interactive. Response time should be optimized at the
expense of bandwidth efficiency and delay variation when sending expense of bandwidth efficiency and delay variation when sending
on this connection.Transport system implementations that map the on this connection.Transport system implementations that map the
requested capacity profile onto per-connection DSCP signaling requested capacity profile onto per-connection DSCP signaling
without multiplexing SHOULD assign a DSCP Assured Forwarding without multiplexing SHOULD assign a DSCP Assured Forwarding
(AF21,AF22,AF23,AF24) [RFC2597] PHB; when the Connection is (AF21,AF22,AF23,AF24) [RFC2597] PHB; when the Connection is
multiplexed, the guidelines in section 6 of [RFC7657] apply. multiplexed, the guidelines in Section 6 of [RFC7657] apply.
Constant-Rate Streaming: The application expects to send/receive Constant-Rate Streaming: The application expects to send/receive
data at a constant rate after Connection establishment. Delay and data at a constant rate after Connection establishment. Delay and
delay variation should be minimized at the expense of bandwidth delay variation should be minimized at the expense of bandwidth
efficiency. This implies that the Connection may fail if the efficiency. This implies that the Connection may fail if the
desired rate cannot be maintained across the Path. A transport desired rate cannot be maintained across the Path. A transport
may interpret this capacity profile as preferring a circuit may interpret this capacity profile as preferring a circuit
breaker [RFC8084] to a rate-adaptive congestion controller. breaker [RFC8084] to a rate-adaptive congestion controller.
Transport system implementations that map the requested capacity Transport system implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing profile onto per-connection DSCP signaling without multiplexing
SHOULD assign a DSCP Assured Forwarding (AF31,AF32,AF33,AF34) SHOULD assign a DSCP Assured Forwarding (AF31,AF32,AF33,AF34)
[RFC2597] PHB; when the Connection is multiplexed, the guidelines [RFC2597] PHB; when the Connection is multiplexed, the guidelines
in section 6 of [RFC7657] apply. in Section 6 of [RFC7657] apply.
High Throughput Data: The application expects to send/receive data High Throughput Data: The application expects to send/receive data
at the maximum rate allowed by its congestion controller over a at the maximum rate allowed by its congestion controller over a
relatively long period of time. Transport system implementations relatively long period of time. Transport system implementations
that map the requested capacity profile onto per-connection DSCP that map the requested capacity profile onto per-connection DSCP
signaling without multiplexing SHOULD assign a DSCP Assured signaling without multiplexing SHOULD assign a DSCP Assured
Forwarding (AF11,AF12,AF13,AF14) [RFC2597] PHB per section 4.8 of Forwarding (AF11,AF12,AF13,AF14) [RFC2597] PHB per Section 4.8 of
[RFC4594]. When the Connection is multiplexed, the guidelines in [RFC4594]. When the Connection is multiplexed, the guidelines in
section 6 of [RFC7657] apply. Section 6 of [RFC7657] apply.
The Capacity Profile for a selected protocol stack may be modified on The Capacity Profile for a selected protocol stack may be modified on
a per-Message basis using the Transmission Profile Message Property; a per-Message basis using the Transmission Profile Message Property;
see Section 7.3.8. see Section 7.4.8.
9.1.11. Bounds on Send or Receive Rate 11.1.11. Bounds on Send or Receive Rate
Name: max-send-rate / max-recv-rate Name: max-send-rate / max-recv-rate
Type: Integer (positive) Type: Numeric / Numeric
Default: -1 / -1 (unlimited, for both values)
This property specifies an upper-bound rate that a transfer is not This property specifies an upper-bound rate that a transfer is not
expected to exceed (even if flow control and congestion control allow expected to exceed (even if flow control and congestion control allow
higher rates), and/or a lower-bound rate below which the application higher rates), and/or a lower-bound rate below which the application
does not deem a data transfer useful. It is given in bits per does not deem a data transfer useful. It is given in bits per
second. second. The special value -1 indicates that no bound is specified.
9.1.12. TCP-specific Property: User Timeout 11.1.12. TCP-specific Property: User Timeout
This property specifies, for the case TCP becomes the chosen This property specifies, for the case TCP becomes the chosen
transport protocol: transport protocol:
Advertised User Timeout (name: tcp.user-timeout-value, type: Advertised User Timeout (name: tcp.user-timeout-value, type:
Integer): Integer):
a time value to be advertised via the User Timeout Option (UTO) a time value (default: the TCP default) to be advertised via the
for the TCP at the remote endpoint to adapt its own "Timeout for User Timeout Option (UTO) for the TCP at the remote endpoint to
aborting Connection" (see Section 9.1.4) value accordingly adapt its own "Timeout for aborting Connection" (see
Section 11.1.4) value accordingly.
User Timeout Enabled (name: tcp.user-timeout, type: Boolean): a bool User Timeout Enabled (name: tcp.user-timeout, type: Boolean): a bool
ean (default false) to control whether the UTO option is enabled ean (default false) to control whether the UTO option is enabled
for a connection. This applies to both sending and receiving. for a connection. This applies to both sending and receiving.
Changeable (name: tcp.user-timeout-recv, type: Boolean): a boolean Changeable (name: tcp.user-timeout-recv, type: Boolean): a boolean
(default true) which controls whether the "Timeout for aborting (default true) which controls whether the "Timeout for aborting
Connection" (see Section 9.1.4) may be changed based on a UTO Connection" (see Section 11.1.4) may be changed based on a UTO
option received from the remote peer. This boolean becomes false option received from the remote peer. This boolean becomes false
when "Timeout for aborting Connection" (see Section 9.1.4) is when "Timeout for aborting Connection" (see Section 11.1.4) is
used. used.
All of the above parameters are optional (e.g., it is possible to All of the above parameters are optional (e.g., it is possible to
specify "User Timeout Enabled" as true, but not specify an Advertised specify "User Timeout Enabled" as true, but not specify an Advertised
User Timeout value; in this case, the TCP default will be used). User Timeout value; in this case, the TCP default will be used).
9.2. Soft Errors 11.2. Soft Errors
Asynchronous introspection is also possible, via the SoftError Event. Asynchronous introspection is also possible, via the SoftError Event.
This event informs the application about the receipt of an ICMP error This event informs the application about the receipt of an ICMP error
message related to the Connection. This will only happen if the message related to the Connection. This will only happen if the
underlying protocol stack supports access to soft errors; however, underlying protocol stack supports access to soft errors; however,
even if the underlying stack supports it, there is no guarantee that even if the underlying stack supports it, there is no guarantee that
a soft error will be signaled. a soft error will be signaled.
Connection -> SoftError<> Connection -> SoftError<>
9.3. Excessive retransmissions 11.3. Excessive retransmissions
This event notifies the application of excessive retransmissions, This event notifies the application of excessive retransmissions,
based on a configured threshold (see Section 9.1.1). This will only based on a configured threshold (see Section 11.1.1). This will only
happen if the underlying protocol stack supports reliability and, happen if the underlying protocol stack supports reliability and,
with it, such notifications. with it, such notifications.
Connection -> ExcessiveRetransmission<> Connection -> ExcessiveRetransmission<>
10. Connection Termination 12. Connection Termination
Close terminates a Connection after satisfying all the requirements Close terminates a Connection after satisfying all the requirements
that were specified regarding the delivery of Messages that the that were specified regarding the delivery of Messages that the
application has already given to the transport system. For example, application has already given to the transport system. For example,
if reliable delivery was requested for a Message handed over before if reliable delivery was requested for a Message handed over before
calling Close, the transport system will ensure that this Message is calling Close, the transport system will ensure that this Message is
indeed delivered. If the Remote Endpoint still has data to send, it indeed delivered. If the Remote Endpoint still has data to send, it
cannot be received after this call. cannot be received after this call.
Connection.Close() Connection.Close()
skipping to change at page 48, line 47 skipping to change at page 53, line 34
Connection.Abort() Connection.Abort()
A ConnectionError informs the application that data to could not be A ConnectionError informs the application that data to could not be
delivered after a timeout, or the other side has aborted the delivered after a timeout, or the other side has aborted the
Connection; however, there is no guarantee that an Abort will indeed Connection; however, there is no guarantee that an Abort will indeed
be signaled. be signaled.
Connection -> ConnectionError<> Connection -> ConnectionError<>
11. Connection State and Ordering of Operations and Events 13. Connection State and Ordering of Operations and Events
As this interface is designed to be independent of an As this interface is designed to be independent of an
implementation's concurrency model, the details of how exactly implementation's concurrency model, the details of how exactly
actions are handled, and on which threads/callbacks events are actions are handled, and on which threads/callbacks events are
dispatched, are implementation dependent. dispatched, are implementation dependent.
Each transition of connection state is associated with one of more Each transition of connection state is associated with one of more
events: events:
o Ready<> occurs when a Connection created with Initiate() or o Ready<> occurs when a Connection created with Initiate() or
skipping to change at page 50, line 5 skipping to change at page 54, line 36
o No events will occur on a Connection after it is Closed; i.e., o No events will occur on a Connection after it is Closed; i.e.,
after a Closed<> event, an InitiateError<> or ConnectionError<> on after a Closed<> event, an InitiateError<> or ConnectionError<> on
that connection. To ensure this ordering, Closed<> will not occur that connection. To ensure this ordering, Closed<> will not occur
on a Connection while other events on the Connection are still on a Connection while other events on the Connection are still
locally outstanding (i.e., known to the interface and waiting to locally outstanding (i.e., known to the interface and waiting to
be dealt with by the application). ConnectionError<> may occur be dealt with by the application). ConnectionError<> may occur
after Closed<>, but the interface must gracefully handle all cases after Closed<>, but the interface must gracefully handle all cases
where application ignores these errors. where application ignores these errors.
12. IANA Considerations 14. IANA Considerations
RFC-EDITOR: Please remove this section before publication. RFC-EDITOR: Please remove this section before publication.
This document has no Actions for IANA. Later versions of this This document has no Actions for IANA. Later versions of this
document may create IANA registries for generic transport property document may create IANA registries for generic transport property
names and transport property namespaces (see Section 4.2.1). names and transport property namespaces (see Section 4.2.1).
13. Security Considerations 15. Security Considerations
This document describes a generic API for interacting with a This document describes a generic API for interacting with a
transport services (TAPS) system. Part of this API includes transport services (TAPS) system. Part of this API includes
configuration details for transport security protocols, as discussed configuration details for transport security protocols, as discussed
in Section 5.3. It does not recommend use (or disuse) of specific in Section 5.3. It does not recommend use (or disuse) of specific
algorithms or protocols. Any API-compatible transport security algorithms or protocols. Any API-compatible transport security
protocol should work in a TAPS system. protocol should work in a TAPS system.
14. Acknowledgements 16. Acknowledgements
This work has received funding from the European Union's Horizon 2020 This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreements No. 644334 research and innovation programme under grant agreements No. 644334
(NEAT) and No. 688421 (MAMI). (NEAT) and No. 688421 (MAMI).
This work has been supported by Leibniz Prize project funds of DFG - This work has been supported by Leibniz Prize project funds of DFG -
German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ
FE 570/4-1). FE 570/4-1).
This work has been supported by the UK Engineering and Physical This work has been supported by the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
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. Thanks to Laurent Chuat Eyeballs, that heavily influenced this work. Thanks to Laurent Chuat
and Jason Lee for initial work on the Post Sockets interface, from and Jason Lee for initial work on the Post Sockets interface, from
which this work has evolved. which this work has evolved.
15. References 17. References
15.1. Normative References 17.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-02 (work in Transport Services", draft-ietf-taps-arch-03 (work in
progress), October 2018. progress), March 2019.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
qos-18 (work in progress), August 2016. qos-18 (work in progress), August 2016.
[I-D.ietf-tsvwg-sctp-ndata]
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", draft-ietf-tsvwg-
sctp-ndata-13 (work in progress), September 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
15.2. Informative References 17.2. Informative References
[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 53, line 20 skipping to change at page 57, line 40
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[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>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", RFC 8260,
DOI 10.17487/RFC8260, November 2017,
<https://www.rfc-editor.org/info/rfc8260>.
Appendix A. Additional Properties Appendix A. Additional Properties
The interface specified by this document represents the minimal The interface specified by this document represents the minimal
common interface to an endpoint in the transport services common interface to an endpoint in the transport services
architecture [I-D.ietf-taps-arch], based upon that architecture and architecture [I-D.ietf-taps-arch], based upon that architecture and
on the minimal set of transport service features elaborated in on the minimal set of transport service features elaborated in
[I-D.ietf-taps-minset]. However, the interface has been designed [I-D.ietf-taps-minset]. However, the interface has been designed
with extension points to allow the implementation of features beyond with extension points to allow the implementation of features beyond
those in the minimal common interface: Protocol Selection Properties, those in the minimal common interface: Protocol Selection Properties,
Path Selection Properties, and Message Properties are open sets. Path Selection Properties, and Message Properties are open sets.
skipping to change at page 53, line 45 skipping to change at page 58, line 22
used to enhance transport protocol and/or path selection, or the used to enhance transport protocol and/or path selection, or the
transmission of messages given a Protocol Stack that implements them. transmission of messages given a Protocol Stack that implements them.
These are not part of the interface, and may be removed from the These are not part of the interface, and may be removed from the
final document, but are presented here to support discussion within final document, but are presented here to support discussion within
the TAPS working group as to whether they should be added to a future the TAPS working group as to whether they should be added to a future
revision of the base specification. revision of the base specification.
A.1. Experimental Transport Properties A.1. Experimental Transport Properties
The following Transport Properties might be made available in The following Transport Properties might be made available in
addition to those specified in Section 5.2, Section 9.1, and addition to those specified in Section 5.2, Section 11.1, and
Section 7.3. Section 7.4.
A.1.1. Cost Preferences A.1.1. Cost Preferences
[EDITOR'S NOTE: At IETF 103, opinions were that this property should [EDITOR'S NOTE: At IETF 103, opinions were that this property should
stay, but it was also said that this is maybe not "on the right stay, but it was also said that this is maybe not "on the right
level". If / when moving it to the main text, note that this is level". If / when moving it to the main text, note that this is
meant to be applicable to a Preconnection or a Message.] meant to be applicable to a Preconnection or a Message.]
Name: cost-preferences Name: cost-preferences
skipping to change at page 57, line 28 skipping to change at page 62, line 4
o Configurable Message Reliability: o Configurable Message Reliability:
The "Lifetime" Message Property implements a time-based way to The "Lifetime" Message Property implements a time-based way to
configure message reliability. configure message reliability.
o "Ordered message delivery (potentially slower than unordered)" and o "Ordered message delivery (potentially slower than unordered)" and
"Unordered message delivery (potentially faster than ordered)": "Unordered message delivery (potentially faster than ordered)":
The two transport features are controlled via the Message property The two transport features are controlled via the Message property
"Ordered". "Ordered".
o Request not to delay the acknowledgement (SACK) of a message: o Request not to delay the acknowledgement (SACK) of a message:
Should the protocol support it, this is one of the transport Should the protocol support it, this is one of the transport
features the transport system can use when an application uses the features the transport system can use when an application uses the
Capacity Profile Property with value "Low Latency/Interactive". Capacity Profile Property with value "Low Latency/Interactive".
o Receive data (with no message delimiting): o Receive data (with no message delimiting):
"Received" Event without using a Deframer. "Received" Event without using a Message Framer.
o Receive a message: o Receive a message:
"Received" Event. Section 5.1 of [I-D.ietf-taps-minset] discusses "Received" Event. Section 5.1 of [I-D.ietf-taps-minset] discusses
how messages can be obtained from a bytestream in case of how messages can be obtained from a bytestream in case of
implementation over TCP. Here, this is dealt with by Framers and implementation over TCP. Here, this is dealt with by Message
Deframers. Framers.
o Information about partial message arrival: o Information about partial message arrival:
"ReceivedPartial" Event. "ReceivedPartial" Event.
o Notification of send failures: o Notification of send failures:
"Expired" and "SendError" Events. "Expired" and "SendError" Events.
o Notification that the stack has no more user data to send: o Notification that the stack has no more user data to send:
Applications can obtain this information via the "Sent" Event. Applications can obtain this information via the "Sent" Event.
skipping to change at page 59, line 14 skipping to change at page 63, line 39
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.
1 Infinite Loop 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
Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: tpauly@apple.com
 End of changes. 185 change blocks. 
352 lines changed or deleted 600 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/