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

[Michael Welzl <[e-mail]>]

Hi,

Thanks a lot for your comments!  Answers in line below, marked with [Michael]. When I say "done" I mean my local copy - still need to fix some more nits, but I thought sharing this answer already now is useful.

Cheers,
Michael




> 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].


[Michael] I addressed this, but differently because I think repeating the title of FJ16 doesn't make this sentence very readable. Here's my new version of the paragraph's last sentence:

***
   Together with an overview
   of the services provided by IETF transport protocols and and
   congestion control mechanisms [RFC8095] and an analysis of UDP and
   UDP-Lite [FJ16], it provides the basis for the minimal set of
   transport services that end systems should support [I-D.draft-
   gjessing-taps-minset].
***



>   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.

[Michael] Done, but removed the first sentence of the paragraph, and inserted "unicast" in the right place of the existing text.
Anyway, the intro's first paragraph now doesn't talk about the processs anymore.



- 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]

[Michael] Done. This also made me remove the (now redundant) sentence preceding the quoted sentence, as well as one more statement in pass 2 / SET_DSCP.TCP that talks about this field replacement but maybe wasn't correctly phrased.



> 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>

[Michael] Done.


- 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)

[Michael] Done. I checked and saw that you accordingly replaced DISABLE_CHECKSUM
with CHECKSUM_ENABLED in your own draft. However, please note that there is
a leftover occurrence, in a sentence that also has an extra space before the ".".
Just do a search for "DISABLE_CHECKSUM" in draft-ietf-taps-transports-usage-udp-02.


- 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,
		
[Michael] I agree and rephrased this as you suggest, but I think your replacement
of REQUIRE_CHECKSUM with SET_CHECKSUM_COVERAGE here is an error, so I didn't do it.


- 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.

[Michael] Done.


- 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'.

[Michael] Done.


- 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.

[Michael] Done.


- 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.

...and:

- 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


[Michael] I'd like to keep this, as it's part of my effort to unify the description
of services across protocols. As you can see here, both UDP and SCTP can give
per-message errors, but TCP doesn't. You say it's "just an error report" - indeed,
your SEND primitive description contains: "Messages passed to the send primitive that
cannot be sent atomically in a datagram will not be sent by the network layer,
generating an error." My pass 2 description above only points back to the pass 1
primitive called "SEND". So it's just a different way of saying that SEND failed.



- 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


[Michael] Done. Great catch, btw, this wasn't even a part of the pass 2 primitives.



- 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)


[Michael] Done.



- 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?)

[Michael] See the other thread: I think we settled this.


-------------------
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

[Michael] I see that you have now replaced this with GET_MMS_S and GET_MMS_R
and will update my text accordingly.



- 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)

[Michael] Sorry, but I don't get that - there's only one other, and that's:
"Specify which IP Options must always be used". But this is in the
ESTABLISHMENT and AVAILABILITY categories, not in MAINTENANCE - indeed
TCP can only do this at the beginning, not later. Anyway, this now also
includes UDP(-Lite) as you suggested above. So where would you want
me to move this?


------------------

> 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>

[Michael] Done.