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

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.

Gjessing & Welzl         Expires January 8, 2017                [Page 1]
Internet-Draft       Minimal TAPS Transport Services           July 2016

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Superset of Transport Service Features . . . . . . . . . .  5
     3.1.  CONNECTION Related Transport Service Features  . . . . . .  5
     3.2.  DATA Transfer Related Transport Service Features . . . . .  9
       3.2.1.  Sending Data . . . . . . . . . . . . . . . . . . . . .  9
       3.2.2.  Receiving Data . . . . . . . . . . . . . . . . . . . . 10
       3.2.3.  Errors . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Revision information  . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Gjessing & Welzl         Expires January 8, 2017                [Page 2]
Internet-Draft       Minimal TAPS Transport Services           July 2016

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

Gjessing & Welzl         Expires January 8, 2017                [Page 3]
Internet-Draft       Minimal TAPS Transport Services           July 2016

   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:
   o  Functional
      This transport service feature has to be specified by the
      application, since if not, it cannot be used or the application
      logic may break.
   o  Optimizing
      This transport service feature may be specified by the
      application, and when specified can optimize the performance of
      the application.

   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.

Gjessing & Welzl         Expires January 8, 2017                [Page 4]
Internet-Draft       Minimal TAPS Transport Services           July 2016

   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:
   o  Connect
      Protocols: TCP, SCTP
      Functional because the notion of a connection is often reflected
      in applications as an expectation to be able to communicate after
      a "Connect" succeeded, with a communication sequence relating to
      this transport service feature that is defined by the application
      protocol.
      Implementation: via CONNECT.TCP or CONNECT.SCTP.

Gjessing & Welzl         Expires January 8, 2017                [Page 5]
Internet-Draft       Minimal TAPS Transport Services           July 2016

   o  Specify IP Options
      Protocols: TCP
      Automatable because IP Options relate to knowledge about the
      network, not the application.

   o  Request multiple streams
      Protocols: SCTP
      Automatable because using multi-streaming does not require
      application-specific knowledge.
      Implementation: see Section 4.

   o  Obtain multiple sockets
      Protocols: SCTP
      Automatable because the usage of multiple paths to communicate to
      the same end host relates to knowledge about the network, not the
      application.
      Implementation: see Section 4.

   AVAILABILITY:
   o  Listen
      Protocols: All
      Functional because the notion of accepting connection requests is
      often reflected in applications as an expectation to be able to
      communicate after a "Listen" succeeded, with a communication
      sequence relating to this transport service feature that is
      defined by the application protocol.
      ADDED.  This differs from the 3 automatable transport service
      features below in that it leaves the choice of interfaces for
      listening open.
      Implementation: by listening on all interfaces via LISTEN.TCP (not
      providing a local IP address) or LISTEN.SCTP (providing SCTP port
      number / address pairs for all local IP addresses).

   o  Listen, 1 specified local interface
      Protocols: TCP, SCTP
      Automatable because decisions about local interfaces relate to
      knowledge about the network and the Operating System, not the
      application.
   o  Listen, N specified local interfaces
      Protocols: SCTP
      Automatable because decisions about local interfaces relate to
      knowledge about the network and the Operating System, not the
      application.
   o  Listen, all local interfaces
      Protocols: TCP, SCTP
      Automatable because decisions about local interfaces relate to
      knowledge about the network and the Operating System, not the

Gjessing & Welzl         Expires January 8, 2017                [Page 6]
Internet-Draft       Minimal TAPS Transport Services           July 2016

      application.
   o  Obtain requested number of streams
      Protocols: SCTP
      Automatable because using multi-streaming does not require
      application-specific knowledge.
      Implementation: see Section 4.

   MAINTENANCE:
   o  Change timeout for aborting connection (using retransmit limit or
      time value)
      Protocols: TCP, SCTP
      Functional because this is closely related to potentially assumed
      reliable data delivery.
      Implementation: via CHANGE-TIMEOUT.TCP or CHANGE-TIMEOUT.SCTP.

   o  Control advertising timeout for aborting connection to remote
      endpoint
      Protocols: TCP
      Functional because this is closely related to potentially assumed
      reliable data delivery.
      Implementation: via CHANGE-TIMEOUT.TCP.

   o  Disable Nagle algorithm
      Protocols: TCP, SCTP
      Optimizing because this decision depends on knowledge about the
      size of future data blocks and the delay between them.
      Implementation: via DISABLE-NAGLE.TCP and [**Not yet included in
      [TAPS2] FOR SCTP**].

   o  Request an immediate heartbeat, returning success/failure
      Protocols: SCTP
      Automatable because this informs about network-specific knowledge.

   o  Set protocol parameters
      Protocols: SCTP
      SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst;
      RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans;
      Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst
      Automatable because these parameters relate to knowledge about the
      network, not the application.

   o  Notification of Excessive Retransmissions (early warning below
      abortion threshold)
      Protocols: TCP
      Optimizing because it is an early warning to the application,
      informing it of an impending functional event.
      Implementation: via ERROR.TCP.

Gjessing & Welzl         Expires January 8, 2017                [Page 7]
Internet-Draft       Minimal TAPS Transport Services           July 2016

   o  Notification of ICMP error message arrival
      Protocols: TCP
      Optimizing because these messages can inform about success or
      failure of functional transport service features (e.g., host
      unreachable relates to "Connect")
      Implementation: via ERROR.TCP.

   o  Status (query or notification)
      Protocols: SCTP
      SCTP parameters: association connection state; socket list; socket
      reachability states; current receiver window size; current
      congestion window sizes; number of unacknowledged DATA chunks;
      number of DATA chunks pending receipt; primary path; most recent
      SRTT on primary path; RTO on primary path; SRTT and RTO on other
      destination addresses; socket becoming active / inactive
      Automatable because these parameters relate to knowledge about the
      network, not the application.

   o  Set primary path
      Protocols: SCTP
      Automatable because it requires using multiple sockets, but
      obtaining multiple sockets in the CONNECTION.ESTABLISHMENT
      category is automatable.
      Implementation: see Section 4.

   o  Change DSCP
      Protocols: TCP
      Optimizing because choosing a suitable DSCP value requires
      application-specific knowledge.
      Implementation: via CHANGE-DSCP.TCP and [**Not yet included in
      [TAPS2] FOR SCTP**]

   TERMINATION:
   o  Close after reliably delivering all remaining data, causing an
      event informing the application on the other side
      Protocols: TCP, SCTP
      Functional because the notion of a connection is often reflected
      in applications as an expectation to have all outstanding data
      delivered and no longer be able to communicate after a "Close"
      succeeded, with a communication sequence relating to this
      transport service feature that is defined by the application
      protocol.
      Implementation: via CLOSE.TCP and CLOSE.SCTP.

   o  Abort without delivering remaining data, causing an event
      informing the application on the other side
      Protocols: TCP, SCTP

Gjessing & Welzl         Expires January 8, 2017                [Page 8]
Internet-Draft       Minimal TAPS Transport Services           July 2016

      Functional because the notion of a connection is often reflected
      in applications as an expectation to potentially not have all
      outstanding data delivered and no longer be able to communicate
      after an "Abort" succeeded, with a communication sequence relating
      to this transport service feature that is defined by the
      application protocol.
      Implementation: via ABORT.TCP and ABORT.SCTP.

   o  Timeout event when data could not be delivered for too long
      Protocols: TCP, SCTP
      Functional because this notifies that potentially assumed reliable
      data delivery is no longer provided.  Implementation: via
      TIMEOUT.TCP and TIMEOUT.SCTP.

3.2.  DATA Transfer Related Transport Service Features

3.2.1.  Sending Data

   o  Reliably transfer data
      Protocols: TCP, SCTP
      Functional because this is closely tied to properties of the data
      that an application sends or expects to receive.
      Implementation: via SEND.TCP and SEND.SCTP.

   o  Message identification
      Protocols: SCTP
      Functional because this is closely tied to properties of the data
      that an application sends or expects to receive.
      Implementation: via SEND.SCTP.
      Fall-back to TCP: By using SEND.TCP and providing a means to let
      the application query whether messages can be identified or not.

   o  Choice of stream
      Protocols: SCTP
      Automatable because it requires using multiple streams, but
      requesting multiple streams in the CONNECTION.ESTABLISHMENT
      category is automatable.  Implementation: see Section 4.

   o  Choice of path (destination address)
      Protocols: SCTP
      Automatable because it requires using multiple sockets, but
      obtaining multiple sockets in the CONNECTION.ESTABLISHMENT
      category is automatable.  Implementation: see Section 4.

   o  Message lifetime
      Protocols: SCTP
      Optimizing because only applications know about the time

Gjessing & Welzl         Expires January 8, 2017                [Page 9]
Internet-Draft       Minimal TAPS Transport Services           July 2016

      criticality of their communication.
      Implementation: via SEND.SCTP.
      Fall-back to TCP: By using SEND.TCP and ignoring the lifetime
      request: based on the assumption of the best-effort service model,
      unnecessarily delivering data does not violate application
      expectations.  Moreover, it is not possible to associate the
      requested lifetime to a "message" in TCP anyway.

   o  Choice between unordered (potentially faster) or ordered delivery
      of messages
      Protocols: SCTP
      Functional because this is closely tied to properties of the data
      that an application sends or expects to receive.
      Implementation: via SEND.SCTP.
      Fall-back to TCP: By using SEND.TCP and always sending data
      ordered: based on the assumption of the best-effort service model,
      ordered delivery may just be slower and does not violate
      application expectations.  Moreover, it is not possible to
      associate the requested delivery order to a "message" in TCP
      anyway.

   o  Request not to bundle messages
      Protocols: SCTP
      Optimizing because this decision depends on knowledge about the
      size of future data blocks and the delay between them.
      Implementation: via SEND.SCTP.
      Fall-back to TCP: By using SEND.TCP and DISABLE-NAGLE.TCP to
      disable the Nagle algorithm when the request is made and enable it
      again when the request is no longer made.

   o  Specifying a "payload protocol-id" (handed over as such by the
      receiver)
      Protocols: SCTP
      Functional because it allows to send extra application data with
      every message, for the sake of identification of data, which by
      itself is application-specific.
      Implementation: SEND.SCTP.
      Fall-back to TCP: Not possible.

3.2.2.  Receiving Data

   o  Receive data
      Protocols: TCP, SCTP
      Functional because a TAPS system must be able to send and receive
      data.
      Implementation: via RECEIVE.SCTP and RECEIVE.TCP

Gjessing & Welzl         Expires January 8, 2017               [Page 10]
Internet-Draft       Minimal TAPS Transport Services           July 2016

   o  Choice of stream to receive from
      Protocols: SCTP
      Automatable because it requires using multiple streams, but
      requesting multiple streams in the CONNECTION.ESTABLISHMENT
      category is automatable.
      Implementation: see Section 4.

   o  Message identification
      Protocols: SCTP
      Functional because this is closely tied to properties of the data
      that an application sends or expects to receive.
      Implementation: via RECEIVE.SCTP.
      Fall-back to TCP: By using RECEIVE.TCP and providing a means to
      let the application query whether messages can be identified or
      not.

   o  Information about partial message arrival
      Protocols: SCTP
      Functional because this is closely tied to properties of the data
      that an application sends or expects to receive.
      Implementation: via RECEIVE.SCTP.
      Fall-back to TCP: Not possible (do not provide this event).

3.2.3.  Errors

   o  Notification of send failures
      Protocols: TCP, SCTP
      Functional because this notifies that potentially assumed reliable
      data delivery is no longer provided.
      ADDED.  This differs from the 2 automatable transport service
      features below in that it does not distinugish between unsent and
      unacknowledged messages.
      Implementation: via SENDFAILURE-EVENT.SCTP.
      Fall-back to TCP: Not possible (do not provide this event).

   o  Notification of unsent messages
      Protocols: SCTP
      Automatable because the distinction between unsent and
      unacknowledged is network-specific.
   o  Notification of unacknowledged messages
      Protocols: SCTP
      Automatable because the distinction between unsent and
      unacknowledged is network-specific.

Gjessing & Welzl         Expires January 8, 2017               [Page 11]
Internet-Draft       Minimal TAPS Transport Services           July 2016

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:
   o  All transport service features that are related to multi-streaming
      were removed.  The decision on whether to use multi-streaming or
      not does not depend on application-specific knowledge.  This means
      that a connection that is exhibited to an application could be
      implemented by using a single stream of an SCTP association
      instead of mapping it to a complete SCTP association.  This could
      be achieved by using more than one stream when an SCTP association
      is first established (CONNECT.SCTP parameter "outbound stream
      count"), an internal stream number could be maintained by the TAPS
      system, and this stream number would then be used when sending
      data (SEND.SCTP parameter "stream number").  Closing or aborting a
      connection could then simply free the stream number for future
      use.
   o  All transport service features that are related to usage of
      multiple paths or the choice of the network interface were
      removed.  Choosing a path or an interface does not depend on
      application-specific knowledge.  For example, "Listen" could
      always listen on all available interfaces and "Connect" could use
      the default interface for the destination IP address.

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:
   o  A TAPS system should expose all functional transport service
      features that are offered by the transport protocols that it uses
      because these transport service features could otherwise not be
      utilized by the TAPS system.  It can still be possible to

Gjessing & Welzl         Expires January 8, 2017               [Page 12]
Internet-Draft       Minimal TAPS Transport Services           July 2016

      implement a TAPS system that does not offer all functional
      transport service features, e.g. for the sake of uniform
      application operation across a broader set of protocols, but then
      the corresponding functionality of transport protocols is not
      exploited.  If a protocol that provides a functional transport
      service feature is not available, a TAPS system should
      automatically fall back to a different protocol (e.g.  TCP or UDP)
      whenever possible to reduce the potential for protocol dependence
      in applications.
   o  A TAPS system should exhibit all application-specific optimizing
      transport service features.  If an application-specific optimizing
      transport service feature is only available in a subset of the
      transport protocols used by the TAPS system, it should be
      acceptable for the TAPS system to ignore its usage when the
      transport protocol that is currently used does not provide it
      because of the performance-optimizing nature of the transport
      service feature and the initially mentioned assumption of "best
      effort" operation.
   o  By hiding automatable transport service features from the
      application, a TAPS system can gain opportunities to automatize
      network-related functionality.  This can facilitate using the TAPS
      system for the application programmer and it allows for
      optimizations that may not be possible for an application.  For
      instance, a kernel-level TAPS system that hides SCTP multi-
      streaming from applications could theoretically map application-
      level connections from multiple applications onto the same SCTP
      association.  Similarly, system-wide configurations regarding the
      usage of multiple interfaces could be exploited if the choice of
      the interface is not given to the application.  However, if an
      application wants to directly expose such choices to its user, not
      offering this functionality can become a disadvantage of a TAPS
      system.  This is a trade-off that must be considered in TAPS
      system design.

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.

Gjessing & Welzl         Expires January 8, 2017               [Page 13]
Internet-Draft       Minimal TAPS Transport Services           July 2016

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,
              <http://www.rfc-editor.org/info/rfc5290>.

   [RFC7305]  Lear, E., Ed., "Report from the IAB Workshop on Internet
              Technology Adoption and Transition (ITAT)", RFC 7305,
              DOI 10.17487/RFC7305, July 2014,
              <http://www.rfc-editor.org/info/rfc7305>.

   [TAPS1]    Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
              provided by IETF transport protocols and congestion
              control mechanisms", draft-ietf-taps-transports-11 (work
              in progress), July 2016.

   [TAPS2]    Welzl, M., Tuexen, M., and N. Khademi, "An Approach to
              Identify Services Provided by IETF Transport Protocols and
              Congestion Control Mechanisms",
              draft-ietf-taps-transports-usage-00 (work in progress),
              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.

Gjessing & Welzl         Expires January 8, 2017               [Page 14]
Internet-Draft       Minimal TAPS Transport Services           July 2016

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

Gjessing & Welzl         Expires January 8, 2017               [Page 15]