[Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

[Gorry Fairhurst <[e-mail]>]

We have just revised the UDP usage draft for TAPs in preparation for WG 
review. This improves readability and fixed all known issues:
https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-01.txt

In doing so, we have carefully reviewed the TAPS transport usage draft 
and have some comments that may be useful to consider for updating that 
draft. Some of these relate to the way UDP is specified, and some are 
more general,

best wishes,

Tom & Gorry

---


 > 2.  Introduction
 >
 >   This document presents defined interactions between applications and
 >   the transport protocols TCP, MPTCP, SCTP, UDP and UDP-Lite as well as
 >   the LEDBAT congestion control mechanism in the form of primitives and
 >   Transport Features.  Primitives can be invoked by an application or a
 >   transport protocol; the latter type is called an "event".  The list
 >   of primitives and Transport Features in this document is strictly
 >   based on the parts of protocol specifications that describe what the
 >   protocol provides to an application using it and how the application
 >   interacts with it.  Together with [RFC8095], it provides the basis
 >   for the minimal set of transport services that end systems should
 >
 >
 >
 > Welzl, et al.            Expires October 7, 2017                [Page 3]
 >
 > Internet-Draft             Transport Services                 April 2017
 >
 >
 >   support; this minimal set is derived in
 >   [I-D.draft-gjessing-taps-minset].

What is the relationship to usage-udp?

ADD:
	UDP and UDP-Lite protocols are analysed in Features of the User
	Datagram (UDP) and Lightweight UDP (UDP-Lite) Transport
         protocols [FJ16].

 >   Parts of a protocol that are explicitly stated as optional to
 >   implement are not covered.  Interactions between the application and
 >   a transport protocol that are not directly related to the operation
 >   of the protocol are also not covered.  For example, [RFC6458]
 >   explains how an application can use socket options to indicate its
 >   interest in receiving certain notifications.  However, for the
 >   purpose of identifying primitives and Transport Services, the ability
 >   to enable or disable the reception of notifications is irrelevant.
 >   Similarly, one-to-many style sockets described in [RFC6458] just
 >   affect the application programming style, not how the underlying
 >   protocol operates, and they are therefore not discussed here.  The
 >   same is true for the ability to obtain the unchanged value of a
 >   parameter that an application has previously set (this is the case
 >  for the "get" in many get/set operations in [RFC6458]).
 >
 >   The document presents a three-pass process to arrive at a list of
 >   Transport Features.  In the first pass, the relevant RFC text is
 >   discussed per protocol.  In the second pass, this discussion is used
 >   to derive a list of primitives that are uniformly categorized across
 >   protocols.  Here, an attempt is made to present or -- where text
 >   describing primitives does not yet exist -- construct primitives in a
 >   slightly generalized form to highlight similarities.  This is, for
 >   example, achieved by renaming primitives of protocols or by avoiding
 >   a strict 1:1-mapping between the primitives in the protocol
 >   specification and primitives in the list.  Finally, the third pass
 >   presents Transport Features based on pass 2, identifying which
 >   protocols implement them.
 >
 >   In the list resulting from the second pass, some Transport Features
 >   are missing because they are implicit in some protocols, and they
 >   only become explicit when we consider the superset of all features
 >   offered by all protocols.  For example, TCP always carries out
 >   congestion control; we have to consider it together with a protocol
 >   like UDP (which does not have congestion control) before we can
 >   consider congestion control as a Transport Feature.  The complete
 >   list of features across all protocols is therefore only available
 >   after pass 3.

This needs an intro to the document separate to the overview of the
process

The document needs to start with an introduction to the document
separate of the overview of the process, so that anyone reading thsi
knows whether t read more. Perhaps this should be the first section?

 >   This document discusses unicast transport protocols and a unicast
 >   congestion control mechanism.  Transport protocols provide
 >   communication between processes that operate on network endpoints,
 >   which means that they allow for multiplexing of communication between
 >   the same IP addresses, and normally this multiplexing is achieved
 >   using port numbers.  Port multiplexing is therefore assumed to be
 >   always provided and not discussed in this document.
 >

The above paragraph could be moved earlier perhaps as part of the 
introduction.

- This is more diffserv-based, rather than historical:
OLD:
 >      Staying with the intention behind the application's
 >      ability to specify the "Type of Service", this should probably be
 >      interpreted to mean the value in the DSField, which is the
 >      Differentiated Services Codepoint (DSCP).
NEW:
	 The Differentiated Services (diffuser) model [RFC2475][RFC3260]
	 replaces this field in the IP Header assigning the six most
	 significant bits to carry the Differentiated Services
          Code Point (DSCP) field [RFC2474]

 > 3.4.  Primitives Provided by UDP and UDP-Lite
 >
 >   The primitives provided by UDP and UDP-Lite are described in [FJ16].

- We should include some text on the UDP primitives here, try:

ADD:
         <t><xref target="RFC0768">The User Datagram Protocol (UDP)</xref>
         States: "This User Datagram Protocol (UDP) is defined to make
         available a datagram mode of packet-switched computer 
communication in
         the environment of an interconnected set of computer networks." It
         &ldquo;provides a procedure for application programs to send 
messages
         to other programs with a minimum of protocol mechanism
         (..)&rdquo;.</t>

         <t>The User Interface section of RFC768 states that the user 
interface
         to an application should be able to create receive, source and
         destination ports and addresses, and provide operations to receive
         data based on ports with an indication of source port and address.
         Operations should be provided that allows datagrams be sent 
specifying
         the source and destination ports and addresses to be sent.</t>

		<t>UDP offers only a basic transport interface. UDP datagrams
		may be directly sent and received, without exchanging messages
		between the endpoints to setup a connection (i.e., no handshake
		is performed by the transport protocol prior to communication).
		Neither UDP nor UDP-Lite provide congestion control,
		retransmission, nor do they have support to optimise
		fragmentation and other transport functions. This means that
		applications using UDP need to provide additional functions on
		top of the UDP transport API <xref target="RFC8085"></xref>.
		Guidance on the use of the services provided by UDP is provided
		in the UDP Guidelines <xref target="RFC8085"></xref>. </t>

		<t>
		The set of pass 1 primitives for UDP and UDP-Lite is documented
		in <xref target="draft-usage-udp]"></xref>
		</t>

- It is much clearer to rewrite this:
OLD:
 >   o  CHECKSUM.UDP:
 >      Pass 1 primitive / event: 'DISABLE_CHECKSUM'.
 >      Parameters: 0 when no checksum is used at sender, 1 for checksum
 >      at sender (default)
NEW:
     o  SET_CHECKSUM_ENABLED.UDP:
        Pass 1 primitive / event: 'CHECKSUM_ENABLED'.
        Parameters: 0 when zero checksum is used at sender, 1 for
        checksum at sender (default)

- We could not parse the old text. It is much clearer to rewrite this:
OLD:
 >   o  CHECKSUM_REQUIRED.UDP:
 >      Pass 1 primitive / event: 'REQUIRE_CHECKSUM'.
 >      Parameter: 0 when checksum is required at receiver, 1 to allow
 >      zero checksum at receiver (default)
New:
	SET_CHECKSUM_REQUIRED.UDP
		Pass 1 primitive / event: 'SET_CHECKSUM_COVERAGE'
		Parameter: 0 to allow zero checksum, 1 when a non-zero
		checksum is required (default) at receiver,

- This primitive is not permitted for IPv6 RFC1981bis. Add "IPv4" 
header, suggest this:
OLD:
 >   o  SET_DF.UDP(-Lite):
 >      Pass 1 primitive event: 'SET_DF'.
 >      Parameter: 0 when DF is not set (default), 1 when DF is set
NEW:
	o  SET_DF.UDP(-Lite):
	   Pass 1 primitive event: 'SET_DF'.
	   Parameter: 0 when DF is not set (default) in the IPv4
	   header, 1 when DF is set.

- Suggest add defaults to sending 00:
OLD:
 >   o  SET_ECN.UDP(-Lite):
 >      Pass 1 primitive / event: 'SET_ECN'
 >      Parameters: ECN value
 >      Comments: This allows a UDP(-Lite) application to set the ECN
 >      codepoint field for outgoing UDP(-Lite) datagrams.
NEW:
	o  SET_ECN.UDP(-Lite):
	   Pass 1 primitive / event: 'SET_ECN'
	   Parameters: ECN value
	   Comments: This allows a UDP(-Lite) application to set the ECN
	   codepoint field for outgoing UDP(-Lite) datagrams. Defaults
	   to sending '00'.

- Connections for UDP are an unusual concept, can we try:
OLD:
 >   o  ABORT.UDP(-Lite):
 >      Pass 1 primitive event: 'CLOSE'
 >      Comments: this terminates a connection without delivering
 >      remaining data.  No further UDP(-Lite) datagrams are sent/received
 >      on this connection.
NEW:
     o  ABORT.UDP(-Lite):
        Pass 1 primitive event: 'CLOSE'
        Comments: this terminates a connection without delivering
        remaining data.  No further UDP(-Lite) datagrams are
        sent/received for this transport service instance.

- For UDP, this is just an error report, remove.
DELETE:
 >   o  SEND_FAILURE.UDP(-Lite):
 >      Pass 1 primitive / event: 'SEND'
 >      Comments: This may be used to probe for the effective PMTU when
 >      using in combination with the 'MAINTENANCE.SET_DF' primitive.

- UDP can't do this,  remove UDP(-Lite)
OLD:
 >   o  Listen, N specified local interfaces
 >      Protocols: SCTP, UDP(-Lite)
NEW:
	    o  Listen, N specified local interfaces
	       Protocols: SCTP
- UDP can potentially also do this (for some options on all packets)
OLD:
 >   o  Specify which IP Options must always be used
 >      Protocols: TCP
NEW:
    o  Specify which IP Options must always be used
       Protocols: TCP, UDP(-Lite)

- Why do this??? - Isn't it better to set flow labels per interface or 
for the whole stack, how can any specific transport or application pick 
unique labels?
TEXT:
 >   o  Specify IPv6 flow label field
 >      Protocols: SCTP

(i.e., Is this automatable by the host and a host wide
configuration?)

-------------------
Get Interface MTU is missing from pass 2 and 3:

ADD to pass 2:

	GET_INTERFACE_MTU.UDP:
		Pass 1 primitive: GET_INTERFACE_MTU
		Returns: Maximum datagram size (bytes)

ADD to Pass 3,
MAINTENANCE:

	Get interface MTU
	Protocols: UDP

- Move the per-datagram IP options to be placed next to the other IP 
options primitives:

MOVE:
 >   o  Specify IP Options
 >      Protocols: UDP(-Lite)
 >
MOVE:
 >   o  Obtain IP Options
 >      Protocols: UDP(-Lite)


- Please remove UDP(-Lite), it does not make sense to do thisfrom 5.2.3. 
  Errors:

OLD:
 >   o  Notification of an unsent (part of a) message
 >      Protocols: SCTP, UDP(-Lite)

NEW:
     o  Notification of an unsent (part of a) message
        Protocols: SCTP
------------------

 > 8.  Security Considerations
 >
 >   Authentication, confidentiality protection, and integrity protection
 >   are identified as Transport Features by [RFC8095].  As currently
 >   deployed in the Internet, these features are generally provided by a
 >   protocol or layer on top of the transport protocol; no current full-
 >   featured standards-track transport protocol provides these features
 >   on its own.  Therefore, these features are not considered in this
 >   document, with the exception of native authentication capabilities of
 >   TCP and SCTP for which the security considerations in [RFC5925] and
 >   [RFC4895] apply.
 >

- We think it is also important discussion from usage-udp:
ADD:
	  <t>Security considerations for the use of UDP and UDP-Lite are
	  provided in the referenced RFCs. Security guidance for
           application usage is provided in the UDP-Guidelines <xref
	  target="RFC8085"></xref>.</t>
-- 
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.