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

[Gorry Fairhurst <[e-mail]>]

Thanks for dealing with this, comments in-line.

On 16/05/2017 15:09, Michael Welzl wrote:
> 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.
>
Thanks.
>
> - 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.
>
Correct.

>
> - 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.
>
>
Your call if it makes sense to you.

>
> - 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.
>
Thanks - that would be correct.
>
>
> - 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?
>
I agree, I see the grouping now, and that's why you had the two apart. 
No action needed.
>
> ------------------
>
>> 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.
>
>
Gorry