TAPS S. Gjessing
Internet-Draft M. Welzl
Intended status: Informational University of Oslo
Expires: January 8, 2017 July 7, 2016

A Minimal Set of Transport Services for TAPS Systems
draft-gjessing-taps-minset-02

Abstract

This draft recommends a minimal set of IETF Transport Services offered by end systems supporting TAPS, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport services given in the TAPS document draft-ietf-taps-transports-usage-00.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 8, 2017.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

An application has an intended usage and demands for transport services, and the task of any system that implements TAPS is to offer these services to its applications, i.e. the applications running on top of TAPS, without binding an application to a particular transport protocol.

The present draft is based on [TAPS1] and [TAPS2] and follows the same terminology (also listed below). The purpose of these two drafts is, according to the TAPS charter, to "Define a set of Transport Services, identifying the services provided by existing IETF protocols and congestion control mechanisms." This is item 1 in the list of working group tasks. Also according to the TAPS charter, the working group will then "Specify the subset of those Transport Services, as identified in item 1, that end systems supporting TAPS will provide, and give guidance on choosing among available mechanisms and protocols. Note that not all the capabilities of IETF Transport protocols need to be exposed as Transport Services." Hence it is necessary to minimize the number of services that are offered. We begin this by grouping the transport service features.

Following [TAPS2], we divide the transport service features into two main groups as follows:

  1. CONNECTION related transport service features
    - ESTABLISHMENT
    - AVAILABILITY
    - MAINTENANCE
    - TERMINATION
  2. DATA Transfer Related transport service features
    - Sending Data
    - Receiving Data
    - Errors

Because QoS is out of scope of TAPS, this document assumes a "best effort" service model [RFC5290], [RFC7305]. Applications using a TAPS system can therefore not make any assumptions about e.g. the time it will take to send a message. There are however certain requirements that are strictly kept by transport protocols today, and these must also be kept by a TAPS system. Some of these requirements relate to transport service features that we call "Functional".

Functional transport service features provide functionality that cannot be used without the application knowing about them, or else they violate assumptions that might cause the application to fail. For example, unordered message delivery is a functional transport service feature: it cannot be used without the application knowing about it because the application's assumption could be that messages arrive in order.

"Change DSCP" and "Disable Nagle algorithm" are what we call "Optimizing" transport service features: if a TAPS system autonomously decides to enable or disable them, an application will not fail, but a TAPS system may be able to communicate more efficiently if the application is in control of this optimizing transport service feature. "Change DSCP" and "Disable Nagle algorithm" are examples of transport service features that require application-specific knowledge (about delay/bandwidth requirements and the length of future data blocks that are to be transmitted, respectively).

To summarize, transport service features that this memo recommends to offer to applications are divided into two groups as follows:

The transport service features of IETF transport protocols that are not exposed to the TAPS user because they include functionality that could be transparently utilized by a TAPS system are called "Automatable".

Finally, some transport service features are aggregated or slightly changed in the TAPS API. These transport service features are marked as "ADDED". The corresponding transport service feature(s) is/are automatable, and they are listed immediately below the "ADDED" transport service feature.

This document also sketches how some of the TAPS transport services can be implemented. Wherever it is not obvious how to implement a service via TCP or UDP [**UDP: NOT YET**], a brief discussion is included. IETF transport services are presented following the nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL".

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 Service Feature:
a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc.
Transport Service:
a set of Transport Features, without an association to any given framing protocol, which provides a complete service to an application.
Transport Protocol:
an implementation that provides one or more different transport services using a specific framing and header format on the wire.
Transport Service Instance:
an arrangement of transport protocols with a selected set of features and configuration parameters that implements a single transport service, e.g., a protocol stack (RTP over UDP).
Application:
an entity that uses the transport layer for end-to-end delivery data across the network (this may also be an upper layer protocol or tunnel encapsulation).
Application-specific knowledge:
knowledge that only applications have.
Endpoint:
an entity that communicates with one or more other endpoints using a transport protocol.
Connection:
shared state of two or more endpoints that persists across messages that are transmitted between these endpoints.
Socket:
the combination of a destination IP address and a destination port number.

3. The Superset of Transport Service Features

This section is based on the classification of the transport service features in pass 3 of [TAPS2]. For every transport service feature, a brief explanation of the classification is provided. Some more general decisions affect multiple transport service features (e.g. the decision that multi-streaming is automatable); the rationale for such decisions is provided in Section 4.

3.1. CONNECTION Related Transport Service Features

ESTABLISHMENT:

AVAILABILITY:

MAINTENANCE:

TERMINATION:

3.2. DATA Transfer Related Transport Service Features

3.2.1. Sending Data

3.2.2. Receiving Data

3.2.3. Errors

4. Discussion

Some of transport service features in Section 3 were designated as "automatable" on the basis of a broader decision that affects multiple transport service features. These decisions are explained here:

5. Conclusion

By decoupling applications from transport protocols, a TAPS system provides a different abstraction level than the Berkeley sockets interface. As with high- vs. low-level programming languages, a higher abstraction level allows more freedom for automatization below the interface, yet it takes some control away from the application programmer. This is the design trade-off that a TAPS system developer is facing, and this document provides guidance on the design of this abstraction level. Some transport service features are currently rarely offered by APIs, yet they must be offered or they can never be used ("functional" transport service features). Other transport service features are offered by the APIs of the protocols covered here, but not exposing them in a TAPS API would allow for more freedom to automate protocol usage in a TAPS system.

The eventual recommendations are:

6. Acknowledgements

This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s).

7. IANA Considerations

XX RFC ED - PLEASE REMOVE THIS SECTION XXX

This memo includes no request to IANA.

8. Security Considerations

Security will be considered in future versions of this document.

9. Informative References

[RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of Simple Best-Effort Traffic", RFC 5290, DOI 10.17487/RFC5290, July 2008.
[RFC7305] Lear, E., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014.
[TAPS1] Fairhurst, G., Trammell, B. and M. Kuehlewind, "Services provided by IETF transport protocols and congestion control mechanisms", Internet-draft draft-ietf-taps-transports-11, July 2016.
[TAPS2] Welzl, M., Tuexen, M. and N. Khademi, "An Approach to Identify Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", Internet-draft draft-ietf-taps-transports-usage-00, June 2015.

Appendix A. Revision information

XXX RFC-Ed please remove this section prior to publication.

-02: implementation suggestions added, discussion section added, terminology extended, DELETED category removed, various other fixes; list of Transport Service Features adjusted to -01 version of [TAPS2] except that MPTCP is not included.

Authors' Addresses

Stein Gjessing University of Oslo PO Box 1080 Blindern Oslo, N-0316 Norway Phone: +47 22 85 24 44 EMail: steing@ifi.uio.no
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo, N-0316 Norway Phone: +47 22 85 24 20 EMail: michawe@ifi.uio.no