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/