draft-ietf-taps-minset-03.txt | draft-ietf-taps-minset-04.txt | |||
---|---|---|---|---|
TAPS M. Welzl | TAPS M. Welzl | |||
Internet-Draft S. Gjessing | Internet-Draft S. Gjessing | |||
Intended status: Informational University of Oslo | Intended status: Informational University of Oslo | |||
Expires: September 22, 2018 March 21, 2018 | Expires: December 7, 2018 June 5, 2018 | |||
A Minimal Set of Transport Services for TAPS Systems | A Minimal Set of Transport Services for End Systems | |||
draft-ietf-taps-minset-03 | draft-ietf-taps-minset-04 | |||
Abstract | Abstract | |||
This draft recommends a minimal set of IETF Transport Services | This draft recommends a minimal set of Transport Services offered by | |||
offered by end systems supporting TAPS, and gives guidance on | end systems, and gives guidance on choosing among the available | |||
choosing among the available mechanisms and protocols. It is based | mechanisms and protocols. It is based on the set of transport | |||
on the set of transport features in RFC 8303. | features in RFC 8303. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 22, 2018. | This Internet-Draft will expire on December 7, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 46 ¶ | skipping to change at page 2, line 46 ¶ | |||
A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 42 | A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 42 | |||
A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 43 | A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 43 | |||
A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 43 | A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 43 | |||
A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 44 | A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 44 | |||
A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 44 | A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 44 | |||
Appendix B. Revision information . . . . . . . . . . . . . . . . 45 | Appendix B. Revision information . . . . . . . . . . . . . . . . 45 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
1. Introduction | 1. Introduction | |||
The task of any system that implements TAPS is to offer transport | The task of a transport system is to offer transport services to its | |||
services to its applications, i.e. the applications running on top of | applications, i.e. the applications running on top of the transport | |||
the transport system, without binding them to a particular transport | system. Ideally, it does so without statically binding applications | |||
protocol. Currently, the set of transport services that most | to particular transport protocols. Currently, the set of transport | |||
applications use is based on TCP and UDP (and protocols that are | services that most applications use is based on TCP and UDP (and | |||
layered on top of them); this limits the ability for the network | protocols that are layered on top of them); this limits the ability | |||
stack to make use of features of other transport protocols. For | for the network stack to make use of features of other transport | |||
example, if a protocol supports out-of-order message delivery but | protocols. For example, if a protocol supports out-of-order message | |||
applications always assume that the network provides an ordered | delivery but applications always assume that the network provides an | |||
bytestream, then the network stack can not immediately deliver a | ordered bytestream, then the network stack can not immediately | |||
message that arrives out-of-order: doing so would break a fundamental | deliver a message that arrives out-of-order: doing so would break a | |||
assumption of the application. The net result is unnecessary head- | fundamental assumption of the application. The net result is | |||
of-line blocking delay. | unnecessary head-of-line blocking delay. | |||
By exposing the transport services of multiple transport protocols, a | By exposing the transport services of multiple transport protocols, a | |||
TAPS transport system can make it possible to use these services | transport system can make it possible to use these services without | |||
without having to statically bind an application to a specific | having to statically bind an application to a specific transport | |||
transport protocol. The first step towards the design of such a | protocol. The first step towards the design of such a system was | |||
system was taken by [RFC8095], which surveys a large number of | taken by [RFC8095], which surveys a large number of transports, and | |||
transports, and [RFC8303] as well as [RFC8304], which identify the | [RFC8303] as well as [RFC8304], which identify the specific transport | |||
specific transport features that are exposed to applications by the | features that are exposed to applications by the protocols TCP, | |||
protocols TCP, MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT | MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control | |||
congestion control mechanism. This memo is based on these documents | mechanism. This memo is based on these documents and follows the | |||
and follows the same terminology (also listed below). Because the | same terminology (also listed below). Because the considered | |||
considered transport protocols conjointly cover a wide range of | transport protocols conjointly cover a wide range of transport | |||
transport features, there is reason to hope that the resulting set | features, there is reason to hope that the resulting set (and the | |||
(and the reasoning that led to it) will also apply to many aspects of | reasoning that led to it) will also apply to many aspects of other | |||
other transport protocols. | transport protocols. | |||
The number of transport features of current IETF transports is large, | The number of transport features of current IETF transports is large, | |||
and exposing all of them has a number of disadvantages: generally, | and exposing all of them has a number of disadvantages: generally, | |||
the more functionality is exposed, the less freedom a transport | the more functionality is exposed, the less freedom a transport | |||
system has to automate usage of the various functions of its | system has to automate usage of the various functions of its | |||
available set of transport protocols. Some functions only exist in | available set of transport protocols. Some functions only exist in | |||
one particular protocol, and if an application would use them, this | one particular protocol, and if an application used them, this would | |||
would statically tie the application to this protocol, counteracting | statically tie the application to this protocol, limiting the | |||
the purpose of TAPS. Also, if the number of exposed features is | flexibility of the transport system. Also, if the number of exposed | |||
exceedingly large, a transport system might become very difficult to | features is exceedingly large, a transport system might become very | |||
use for an application programmer. Taking [RFC8303] as a basis, this | difficult to use for an application programmer. Taking [RFC8303] as | |||
document therefore develops a minimal set of transport features, | a basis, this document therefore develops a minimal set of transport | |||
removing the ones that could be harmful to the purpose of TAPS but | features, removing the ones that could get in the way of transport | |||
keeping the ones that must be retained for applications to benefit | flexibility but keeping the ones that must be retained for | |||
from useful transport functionality. | applications to benefit from useful transport functionality. | |||
Applications use a wide variety of APIs today. The transport | Applications use a wide variety of APIs today. The transport | |||
features in the minimal set in this document must be reflected in | features in the minimal set in this document must be reflected in | |||
*all* network APIs in order for the underlying functionality to | *all* network APIs in order for the underlying functionality to | |||
become usable everywhere. For example, it does not help an | become usable everywhere. For example, it does not help an | |||
application that talks to a middleware if only the Berkeley Sockets | application that talks to a library which offers its own | |||
API is extended to offer "unordered message delivery", but the | communication interface if only the underlying Berkeley Sockets API | |||
middleware only offers an ordered bytestream. Both the Berkeley | is extended to offer "unordered message delivery", but the library | |||
Sockets API and the middleware would have to expose the "unordered | only exposes an ordered bytestream. Both the Berkeley Sockets API | |||
message delivery" transport feature (alternatively, there may be ways | and the library would have to expose the "unordered message delivery" | |||
for certain types of middleware to use this transport feature without | transport feature (alternatively, there may be ways for certain types | |||
exposing it, based on knowledge about the applications -- but this is | of libraries to use this transport feature without exposing it, based | |||
not the general case). In most situations, in the interest of being | on knowledge about the applications -- but this is not the general | |||
as flexible and efficient as possible, the best choice will be for a | case). In most situations, in the interest of being as flexible and | |||
middleware or library to expose at least all of the transport | efficient as possible, the best choice will be for a library to | |||
features that are recommended as a "minimal set" here. | expose at least all of the transport features that are recommended as | |||
a "minimal set" here. | ||||
This "minimal set" can be implemented one-sided over TCP (or UDP, if | This "minimal set" can be implemented one-sided over TCP (or UDP, if | |||
certain limitations are put in place). This means that a sender-side | certain limitations are put in place). This means that a sender-side | |||
TAPS system implementing it can talk to a non-TAPS TCP (or UDP) | transport system can talk to a standard TCP (or UDP) receiver, and a | |||
receiver, and a receiver-side TAPS system implementing it can talk to | receiver-side transport system can talk to a standard TCP (or UDP) | |||
a non-TAPS TCP (or UDP) sender. | sender. | |||
2. Terminology | 2. Terminology | |||
The following terms are used throughout this document, and in | ||||
subsequent documents produced by TAPS that describe the composition | ||||
and decomposition of transport services. | ||||
Transport Feature: a specific end-to-end feature that the transport | Transport Feature: a specific end-to-end feature that the transport | |||
layer provides to an application. Examples include | layer provides to an application. Examples include | |||
confidentiality, reliable delivery, ordered delivery, message- | confidentiality, reliable delivery, ordered delivery, message- | |||
versus-stream orientation, etc. | versus-stream orientation, etc. | |||
Transport Service: a set of Transport Features, without an | Transport Service: a set of Transport Features, without an | |||
association to any given framing protocol, which provides a | association to any given framing protocol, which provides a | |||
complete service to an application. | complete service to an application. | |||
Transport Protocol: an implementation that provides one or more | Transport Protocol: an implementation that provides one or more | |||
different transport services using a specific framing and header | different transport services using a specific framing and header | |||
format on the wire. | format on the wire. | |||
skipping to change at page 5, line 7 ¶ | skipping to change at page 5, line 7 ¶ | |||
Socket: the combination of a destination IP address and a | Socket: the combination of a destination IP address and a | |||
destination port number. | destination port number. | |||
Moreover, throughout the document, the protocol name "UDP(-Lite)" is | Moreover, throughout the document, the protocol name "UDP(-Lite)" is | |||
used when discussing transport features that are equivalent for UDP | used when discussing transport features that are equivalent for UDP | |||
and UDP-Lite; similarly, the protocol name "TCP" refers to both TCP | and UDP-Lite; similarly, the protocol name "TCP" refers to both TCP | |||
and MPTCP. | and MPTCP. | |||
3. The Minimal Set of Transport Features | 3. The Minimal Set of Transport Features | |||
Based on the categorization, reduction and discussion in Appendix A, | Based on the categorization, reduction, and discussion in Appendix A, | |||
this section describes the minimal set of transport features that is | this section describes a minimal set of transport features that end | |||
offered by end systems supporting TAPS. The described transport | systems should offer. The described transport system can be | |||
system can be implemented over TCP; elements of the system that may | implemented over TCP. Elements of the system that are not marked | |||
prohibit implementation over UDP are marked with "!UDP". To | with "!UDP" can also be implemented over UDP. | |||
implement a transport system that can also work over UDP, these | ||||
marked transport features should be excluded. | ||||
As in Appendix A, Appendix A.2 and [RFC8303], we categorize the | As in Appendix A, Appendix A.2 and [RFC8303], we categorize the | |||
minimal set of transport features as 1) CONNECTION related | minimal set of transport features as 1) CONNECTION related | |||
(ESTABLISHMENT, AVAILABILITY, MAINTENANCE, TERMINATION) and 2) DATA | (ESTABLISHMENT, AVAILABILITY, MAINTENANCE, TERMINATION) and 2) DATA | |||
Transfer related (Sending Data, Receiving Data, Errors). Here, the | Transfer related (Sending Data, Receiving Data, Errors). Here, the | |||
focus is on connections that the transport system offers, as opposed | focus is on connections that the transport system offers as an | |||
to connections of transport protocols that the transport system uses. | abstraction to the application, as opposed to connections of | |||
transport protocols that the transport system uses. | ||||
3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION | 3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION | |||
A connection must first be "created" to allow for some initial | A connection must first be "created" to allow for some initial | |||
configuration to be carried out before the transport system can | configuration to be carried out before the transport system can | |||
actively or passively establish communication with a remote endpoint. | actively or passively establish communication with a remote endpoint. | |||
All configuration parameters in Section 3.2 can be used initially, | All configuration parameters in Section 3.2 can be used initially, | |||
although some of them may only take effect when a connection has been | although some of them may only take effect when a connection has been | |||
established with a chosen transport protocol. Configuring a | established with a chosen transport protocol. Configuring a | |||
connection early helps a transport system make the right decisions. | connection early helps a transport system make the right decisions. | |||
skipping to change at page 7, line 11 ¶ | skipping to change at page 7, line 11 ¶ | |||
decision. We caution implementers to be aware of the full set of | decision. We caution implementers to be aware of the full set of | |||
trade-offs, for which we recommend consulting the list in | trade-offs, for which we recommend consulting the list in | |||
Appendix A.2.1 when deciding how to initialize a connection. | Appendix A.2.1 when deciding how to initialize a connection. | |||
To summarize, the following parameters serve as input for the | To summarize, the following parameters serve as input for the | |||
transport system to help it choose and configure a suitable protocol: | transport system to help it choose and configure a suitable protocol: | |||
o Reliability: a boolean that should be set to true when any of the | o Reliability: a boolean that should be set to true when any of the | |||
following will be useful to the application: reliably transfer | following will be useful to the application: reliably transfer | |||
data; notify the peer of closing/aborting; preserve data ordering. | data; notify the peer of closing/aborting; preserve data ordering. | |||
o Checksum_coverage: a boolean to specify whether it will be useful | o Checksum coverage: a boolean to specify whether it will be useful | |||
to the application to specify checksum coverage when sending or | to the application to specify checksum coverage when sending or | |||
receiving. | receiving. | |||
o Config_msg_prio: a boolean that should be set to true when any of | o Configure message priority: a boolean that should be set to true | |||
the following per-message configuration or prioritization | when any of the following per-message configuration or | |||
mechanisms will be useful to the application: choosing a scheduler | prioritization mechanisms will be useful to the application: | |||
to operate between grouped connections, with the possibility to | choosing a scheduler to operate between grouped connections, with | |||
configure a priority or weight per connection; configurable | the possibility to configure a priority or weight per connection; | |||
message reliability; unordered message delivery; requesting not to | configurable message reliability; unordered message delivery; | |||
delay the acknowledgement (SACK) of a message. | requesting not to delay the acknowledgement (SACK) of a message. | |||
o Earlymsg_timeout_notifications: a boolean that should be set to | o Early message timeout notifications: a boolean that should be set | |||
true when any of the following will be useful to the application: | to true when any of the following will be useful to the | |||
hand over a message to reliably transfer (possibly multiple times) | application: hand over a message to reliably transfer (possibly | |||
before connection establishment; suggest timeout to the peer; | multiple times) before connection establishment; suggest timeout | |||
notification of excessive retransmissions (early warning below | to the peer; notification of excessive retransmissions (early | |||
abortion threshold); notification of ICMP error message arrival. | warning below abortion threshold); notification of ICMP error | |||
message arrival. | ||||
Once a connection is created, it can be queried for the maximum | Once a connection is created, it can be queried for the maximum | |||
amount of data that an application can possibly expect to have | amount of data that an application can possibly expect to have | |||
reliably transmitted before or during transport connection | reliably transmitted before or during transport connection | |||
establishment (with zero being a possible answer) (see | establishment (with zero being a possible answer) (see | |||
Section 3.2.1). An application can also give the connection a | Section 3.2.1). An application can also give the connection a | |||
message for reliable transmission before or during connection | message for reliable transmission before or during connection | |||
establishment (!UDP); the transport system will then try to transmit | establishment (!UDP); the transport system will then try to transmit | |||
it as early as possible. An application can facilitate sending a | it as early as possible. An application can facilitate sending a | |||
message particularly early by marking it as "idempotent" (see | message particularly early by marking it as "idempotent" (see | |||
skipping to change at page 8, line 16 ¶ | skipping to change at page 8, line 19 ¶ | |||
after reliably delivering all remaining data to the peer (if reliable | after reliably delivering all remaining data to the peer (if reliable | |||
data delivery was requested earlier (!UDP)), in which case the peer | data delivery was requested earlier (!UDP)), in which case the peer | |||
is notified that the connection is closed. Alternatively, a | is notified that the connection is closed. Alternatively, a | |||
connection can be aborted without delivering outstanding data to the | connection can be aborted without delivering outstanding data to the | |||
peer. In case reliable or partially reliable data delivery was | peer. In case reliable or partially reliable data delivery was | |||
requested earlier (!UDP), the peer is notified that the connection is | requested earlier (!UDP), the peer is notified that the connection is | |||
aborted. A timeout can be configured to abort a connection when data | aborted. A timeout can be configured to abort a connection when data | |||
could not be delivered for too long (!UDP); however, timeout-based | could not be delivered for too long (!UDP); however, timeout-based | |||
abortion does not notify the peer application that the connection has | abortion does not notify the peer application that the connection has | |||
been aborted. Because half-closed connections are not supported, | been aborted. Because half-closed connections are not supported, | |||
when a host implementing TAPS receives a notification that the peer | when a host implementing a transport system receives a notification | |||
is closing or aborting the connection (!UDP), its peer may not be | that the peer is closing or aborting the connection (!UDP), its peer | |||
able to read outstanding data. This means that unacknowledged data | may not be able to read outstanding data. This means that | |||
residing a transport system's send buffer may have to be dropped from | unacknowledged data residing a transport system's send buffer may | |||
that buffer upon arrival of a "close" or "abort" notification from | have to be dropped from that buffer upon arrival of a "close" or | |||
the peer. | "abort" notification from the peer. | |||
3.2. MAINTENANCE | 3.2. MAINTENANCE | |||
A transport system must offer means to group connections, but it | A transport system must offer means to group connections, but it | |||
cannot guarantee truly grouping them using the transport protocols | cannot guarantee truly grouping them using the transport protocols | |||
that it uses (e.g., it cannot be guaranteed that connections become | that it uses (e.g., it cannot be guaranteed that connections become | |||
multiplexed as streams on a single SCTP association when SCTP may not | multiplexed as streams on a single SCTP association when SCTP may not | |||
be available). The transport system must therefore ensure that | be available). The transport system must therefore ensure that | |||
group- versus non-group-configurations are handled correctly in some | group- versus non-group-configurations are handled correctly in some | |||
way (e.g., by applying the configuration to all grouped connections | way (e.g., by applying the configuration to all grouped connections | |||
skipping to change at page 12, line 7 ¶ | skipping to change at page 12, line 10 ¶ | |||
Different from TCP's semantics, if the sending application has | Different from TCP's semantics, if the sending application has | |||
allowed that messages are not fully reliably transferred, or | allowed that messages are not fully reliably transferred, or | |||
delivered out of order, then such re-ordering or unreliability may be | delivered out of order, then such re-ordering or unreliability may be | |||
reflected per message in the arriving data. Messages will always | reflected per message in the arriving data. Messages will always | |||
stay intact - i.e. if an incomplete message is contained at the end | stay intact - i.e. if an incomplete message is contained at the end | |||
of the arriving data block, this message is guaranteed to continue in | of the arriving data block, this message is guaranteed to continue in | |||
the next arriving data block. | the next arriving data block. | |||
4. Conclusion | 4. Conclusion | |||
By decoupling applications from transport protocols, a TAPS transport | By decoupling applications from transport protocols, a transport | |||
system provides a different abstraction level than the Berkeley | system provides a different abstraction level than the Berkeley | |||
sockets interface. As with high- vs. low-level programming | sockets interface. As with high- vs. low-level programming | |||
languages, a higher abstraction level allows more freedom for | languages, a higher abstraction level allows more freedom for | |||
automation below the interface, yet it takes some control away from | automation below the interface, yet it takes some control away from | |||
the application programmer. This is the design trade-off that a | the application programmer. This is the design trade-off that a | |||
transport system developer is facing, and this document provides | transport system developer is facing, and this document provides | |||
guidance on the design of this abstraction level. Some transport | guidance on the design of this abstraction level. Some transport | |||
features are currently rarely offered by APIs, yet they must be | features are currently rarely offered by APIs, yet they must be | |||
offered or they can never be used ("functional" transport features). | offered or they can never be used ("functional" transport features). | |||
Other transport features are offered by the APIs of the protocols | Other transport features are offered by the APIs of the protocols | |||
covered here, but not exposing them in a TAPS API would allow for | covered here, but not exposing them in an API would allow for more | |||
more freedom to automate protocol usage in a transport system. The | freedom to automate protocol usage in a transport system. The | |||
minimal set presented in this document is an effort to find a middle | minimal set presented in this document is an effort to find a middle | |||
ground that can be recommended for transport systems to implement, on | ground that can be recommended for transport systems to implement, on | |||
the basis of the transport features discussed in [RFC8303]. | the basis of the transport features discussed in [RFC8303]. | |||
5. Acknowledgements | 5. Acknowledgements | |||
The authors would like to thank all the participants of the TAPS | The authors would like to thank all the participants of the TAPS | |||
Working Group and the NEAT and MAMI research projects for valuable | Working Group and the NEAT and MAMI research projects for valuable | |||
input to this document. We especially thank Michael Tuexen for help | input to this document. We especially thank Michael Tuexen for help | |||
with connection connection establishment/teardown and Gorry Fairhurst | with connection connection establishment/teardown and Gorry Fairhurst | |||
skipping to change at page 13, line 4 ¶ | skipping to change at page 13, line 7 ¶ | |||
Authentication, confidentiality protection, and integrity protection | Authentication, confidentiality protection, and integrity protection | |||
are identified as transport features by [RFC8095]. As currently | are identified as transport features by [RFC8095]. As currently | |||
deployed in the Internet, these features are generally provided by a | deployed in the Internet, these features are generally provided by a | |||
protocol or layer on top of the transport protocol; no current full- | protocol or layer on top of the transport protocol; no current full- | |||
featured standards-track transport protocol provides all of these | featured standards-track transport protocol provides all of these | |||
transport features on its own. Therefore, these transport features | transport features on its own. Therefore, these transport features | |||
are not considered in this document, with the exception of native | are not considered in this document, with the exception of native | |||
authentication capabilities of TCP and SCTP for which the security | authentication capabilities of TCP and SCTP for which the security | |||
considerations in [RFC5925] and [RFC4895] apply. The minimum | considerations in [RFC5925] and [RFC4895] apply. The minimum | |||
security requirements for a taps system are discussed in a separate | security requirements for a transport system are discussed in a | |||
security document [I-D.pauly-taps-transport-security]. | separate document [I-D.ietf-taps-transport-security]. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of | [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of | |||
Transport Features Provided by IETF Transport Protocols", | Transport Features Provided by IETF Transport Protocols", | |||
RFC 8303, DOI 10.17487/RFC8303, February 2018, | RFC 8303, DOI 10.17487/RFC8303, February 2018, | |||
<https://www.rfc-editor.org/info/rfc8303>. | <https://www.rfc-editor.org/info/rfc8303>. | |||
8.2. Informative References | 8.2. Informative References | |||
[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte | [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte | |||
Stuffing", September 1997, | Stuffing", September 1997, | |||
<http://stuartcheshire.org/papers/COBSforToN.pdf>. | <http://stuartcheshire.org/papers/COBSforToN.pdf>. | |||
[I-D.ietf-taps-transport-security] | ||||
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey | ||||
of Transport Security Protocols", draft-ietf-taps- | ||||
transport-security-01 (work in progress), May 2018. | ||||
[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.pauly-taps-transport-security] | ||||
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey | ||||
of Transport Security Protocols", draft-pauly-taps- | ||||
transport-security-02 (work in progress), March 2018. | ||||
[LBE-draft] | [LBE-draft] | |||
Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", | Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", | |||
Internet-draft draft-tsvwg-le-phb-03, February 2018. | Internet-draft draft-tsvwg-le-phb-03, February 2018. | |||
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, | [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, | |||
RFC 2914, DOI 10.17487/RFC2914, September 2000, | RFC 2914, DOI 10.17487/RFC2914, September 2000, | |||
<https://www.rfc-editor.org/info/rfc2914>. | <https://www.rfc-editor.org/info/rfc2914>. | |||
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. | [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. | |||
Conrad, "Stream Control Transmission Protocol (SCTP) | Conrad, "Stream Control Transmission Protocol (SCTP) | |||
skipping to change at page 16, line 37 ¶ | skipping to change at page 16, line 41 ¶ | |||
Finally, some transport features are aggregated and/or slightly | Finally, some transport features are aggregated and/or slightly | |||
changed in the description below. These transport features are | changed in the description below. These transport features are | |||
marked as "ADDED". The corresponding transport features are | marked as "ADDED". The corresponding transport features are | |||
automatable, and they are listed immediately below the "ADDED" | automatable, and they are listed immediately below the "ADDED" | |||
transport feature. | transport feature. | |||
In this description, transport services are presented following the | In this description, transport services are presented following the | |||
nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", | nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", | |||
equivalent to "pass 2" in [RFC8303]. We also sketch how some of the | equivalent to "pass 2" in [RFC8303]. We also sketch how some of the | |||
TAPS transport features can be implemented by a transport system. | transport features can be implemented by a transport system. For all | |||
For all transport features that are categorized as "functional" or | transport features that are categorized as "functional" or | |||
"optimizing", and for which no matching TCP and/or UDP primitive | "optimizing", and for which no matching TCP and/or UDP primitive | |||
exists in "pass 2" of [RFC8303], a brief discussion on how to | exists in "pass 2" of [RFC8303], a brief discussion on how to | |||
implement them over TCP and/or UDP is included. | implement them over TCP and/or UDP is included. | |||
We designate some transport features as "automatable" on the basis of | We designate some transport features as "automatable" on the basis of | |||
a broader decision that affects multiple transport features: | a broader decision that affects multiple transport features: | |||
o Most transport features that are related to multi-streaming were | o Most transport features that are related to multi-streaming were | |||
designated as "automatable". This was done because the decision | designated as "automatable". This was done because the decision | |||
on whether to use multi-streaming or not does not depend on | on whether to use multi-streaming or not does not depend on | |||
skipping to change at page 44, line 28 ¶ | skipping to change at page 44, line 28 ¶ | |||
A.3.6. Security | A.3.6. Security | |||
Both TCP and SCTP offer authentication. TCP authenticates complete | Both TCP and SCTP offer authentication. TCP authenticates complete | |||
segments. SCTP allows to configure which of SCTP's chunk types must | segments. SCTP allows to configure which of SCTP's chunk types must | |||
always be authenticated -- if this is exposed as such, it creates an | always be authenticated -- if this is exposed as such, it creates an | |||
undesirable dependency on the transport protocol. For compatibility | undesirable dependency on the transport protocol. For compatibility | |||
with TCP, a transport system should only allow to configure complete | with TCP, a transport system should only allow to configure complete | |||
transport layer packets, including headers, IP pseudo-header (if any) | transport layer packets, including headers, IP pseudo-header (if any) | |||
and payload. | and payload. | |||
Security is discussed in a separate TAPS document | Security is discussed in a separate document | |||
[I-D.pauly-taps-transport-security]. The minimal set presented in | [I-D.ietf-taps-transport-security]. The minimal set presented in the | |||
the present document therefore excludes all security related | present document therefore excludes all security related transport | |||
transport features: "Configure authentication", "Change | features: "Configure authentication", "Change authentication | |||
authentication parameters", "Obtain authentication information" and | parameters", "Obtain authentication information" and and "Set Cookie | |||
and "Set Cookie life value" as well as "Specifying a key id to be | life value" as well as "Specifying a key id to be used to | |||
used to authenticate a message". | authenticate a message". | |||
A.3.7. Packet Size | A.3.7. Packet Size | |||
UDP(-Lite) has a transport feature called "Specify DF field". This | UDP(-Lite) has a transport feature called "Specify DF field". This | |||
yields an error message in case of sending a message that exceeds the | yields an error message in case of sending a message that exceeds the | |||
Path MTU, which is necessary for a UDP-based application to be able | Path MTU, which is necessary for a UDP-based application to be able | |||
to implement Path MTU Discovery (a function that UDP-based | to implement Path MTU Discovery (a function that UDP-based | |||
applications must do by themselves). The "Get max. transport-message | applications must do by themselves). The "Get max. transport-message | |||
size that may be sent using a non-fragmented IP packet from the | size that may be sent using a non-fragmented IP packet from the | |||
configured interface" transport feature yields an upper limit for the | configured interface" transport feature yields an upper limit for the | |||
skipping to change at page 46, line 14 ¶ | skipping to change at page 46, line 14 ¶ | |||
appendix and [RFC8303], and changed style of section 4 to be even | appendix and [RFC8303], and changed style of section 4 to be even | |||
shorter and less interface-like. Updated reference draft-ietf-tsvwg- | shorter and less interface-like. Updated reference draft-ietf-tsvwg- | |||
sctp-ndata to RFC8260. | sctp-ndata to RFC8260. | |||
WG -02: rephrased "the TAPS system" and "TAPS connection" etc. to | WG -02: rephrased "the TAPS system" and "TAPS connection" etc. to | |||
more generally talk about transport after the intro (mostly replacing | more generally talk about transport after the intro (mostly replacing | |||
"TAPS system" with "transport system" and "TAPS connection" with | "TAPS system" with "transport system" and "TAPS connection" with | |||
"connection". Merged sections 3 and 4 to form a new section 3. | "connection". Merged sections 3 and 4 to form a new section 3. | |||
WG -03: updated sentence referencing | WG -03: updated sentence referencing | |||
[I-D.pauly-taps-transport-security] to say that "the minimum security | [I-D.ietf-taps-transport-security] to say that "the minimum security | |||
requirements for a taps system are discussed in a separate security | requirements for a taps system are discussed in a separate security | |||
document", wrote "example" in the paragraph introducing the decision | document", wrote "example" in the paragraph introducing the decision | |||
tree. Removed reference draft-grinnemo-taps-he-03 and the sentence | tree. Removed reference draft-grinnemo-taps-he-03 and the sentence | |||
that referred to it. | that referred to it. | |||
WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As | ||||
part of that, removed "TAPS" as a term everywhere (abstract, intro, | ||||
..). | ||||
Authors' Addresses | Authors' Addresses | |||
Michael Welzl | Michael Welzl | |||
University of Oslo | University of Oslo | |||
PO Box 1080 Blindern | PO Box 1080 Blindern | |||
Oslo N-0316 | Oslo N-0316 | |||
Norway | Norway | |||
Phone: +47 22 85 24 20 | Phone: +47 22 85 24 20 | |||
Email: michawe@ifi.uio.no | Email: michawe@ifi.uio.no | |||
End of changes. 24 change blocks. | ||||
110 lines changed or deleted | 111 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |