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
“provides a procedure for application programs to send
messages
to other programs with a minimum of protocol mechanism
(..)”.</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.
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
