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
“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>
[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
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
