draft-ietf-taps-minset-02.txt   draft-ietf-taps-minset-03.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 1, 2018 February 28, 2018 Expires: September 22, 2018 March 21, 2018
A Minimal Set of Transport Services for TAPS Systems A Minimal Set of Transport Services for TAPS Systems
draft-ietf-taps-minset-02 draft-ietf-taps-minset-03
Abstract Abstract
This draft recommends a minimal set of IETF Transport Services This draft recommends a minimal set of IETF Transport Services
offered by end systems supporting TAPS, and gives guidance on offered by end systems supporting TAPS, and gives guidance on
choosing among the available mechanisms and protocols. It is based choosing among the available mechanisms and protocols. It is based
on the set of transport features in RFC 8303. on the set of transport features in RFC 8303.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 1, 2018. This Internet-Draft will expire on September 22, 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 5, line 37 skipping to change at page 5, line 37
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.
For example, grouping information can influence the transport system For example, grouping information can influence the transport system
to implement a connection as a stream of a multi-streaming protocol's to implement a connection as a stream of a multi-streaming protocol's
existing association or not. existing association or not.
For ungrouped connections, early configuration is necessary because For ungrouped connections, early configuration is necessary because
it allows the transport system to know which protocols it should try it allows the transport system to know which protocols it should try
to use (to steer a mechanism such as "Happy Eyeballs" to use. In particular, a transport system that only makes a one-time
[I-D.grinnemo-taps-he]). In particular, a transport system that only choice for a particular protocol must know early about strict
makes a one-time choice for a particular protocol must know early requirements that must be kept, or it can end up in a deadlock
about strict requirements that must be kept, or it can end up in a situation (e.g., having chosen UDP and later be asked to support
deadlock situation (e.g., having chosen UDP and later be asked to reliable transfer). As an example description of how to correctly
support reliable transfer). As a possibility to correctly handle handle these cases, we provide the following decision tree (this is
these cases, we provide the following decision tree (this is derived derived from Appendix A.2.1 excluding authentication, as explained in
from Appendix A.2.1 excluding authentication, as explained in
Section 7): Section 7):
- Will it ever be necessary to offer any of the following? - Will it ever be necessary to offer any of the following?
* Reliably transfer data * Reliably transfer data
* Notify the peer of closing/aborting * Notify the peer of closing/aborting
* Preserve data ordering * Preserve data ordering
Yes: SCTP or TCP can be used. Yes: SCTP or TCP can be used.
- Is any of the following useful to the application? - Is any of the following useful to the application?
* Choosing a scheduler to operate between connections * Choosing a scheduler to operate between connections
skipping to change at page 12, line 51 skipping to change at page 12, line 51
7. Security Considerations 7. Security Considerations
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. Security is considerations in [RFC5925] and [RFC4895] apply. The minimum
discussed further in a separate TAPS document security requirements for a taps system are discussed in a separate
[I-D.pauly-taps-transport-security]. security document [I-D.pauly-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.grinnemo-taps-he]
Grinnemo, K., Brunstrom, A., Hurtig, P., Khademi, N., and
Z. Bozakov, "Happy Eyeballs for Transport Selection",
draft-grinnemo-taps-he-03 (work in progress), July 2017.
[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] [I-D.pauly-taps-transport-security]
Pauly, T., Rose, K., and C. Wood, "A Survey of Transport Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey
Security Protocols", draft-pauly-taps-transport- of Transport Security Protocols", draft-pauly-taps-
security-01 (work in progress), January 2018. 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.
skipping to change at page 46, line 13 skipping to change at page 46, line 13
and 4 in line with the categorization that is already used in the and 4 in line with the categorization that is already used in the
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
[I-D.pauly-taps-transport-security] to say that "the minimum security
requirements for a taps system are discussed in a separate security
document", wrote "example" in the paragraph introducing the decision
tree. Removed reference draft-grinnemo-taps-he-03 and the sentence
that referred to it.
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. 8 change blocks. 
22 lines changed or deleted 23 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/