Thanks Spencer,
I have added new text which I hope addresses these issues in the next
revision.
Gorry
On 24/08/2017, 21:09, Spencer Dawkins at IETF wrote:
I'm actually pretty positive on this draft - most of what follows is
editorial.
Thanks,
Spencer
This text
This document is intended as a contribution to the Transport Services
(TAPS) working group to assist in analysis of the UDP and UDP-Lite
transport interface.
Refers to the TAPS working group, which will conclude someday. It’s
probably better if you say that this document provided details for the
Pass 1 analysis of UDP and UDP-Lite that is used in
draft-ietf-taps-transports-usage-06, or something like that.
In this text
Neither UDP nor UDP-Lite provide congestion control, retransmission,
nor do they have support to optimise fragmentation and other
transport functions.
Is “optimizing fragmentation” the best way to describe what UDP is not
doing there? Perhaps “assist in application-level packetization that
would avoid IP fragmentation?”
I may be very confused about this next one, but in
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.
Is this “atomically in an IP datagram”? With IP-level fragmentation
available, I’m not sure what “atomically” is telling the reader.
If we’re going to “go there”, this text
The acceptable maximum packet size can be determined using
Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path
MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis].
Makes PMTUD sound like an equally good alternative. What ended up in
-08 of [I-D.ietf-6man-rfc1981bis], and in RFC 8201, and I saw that
your reference was to -06, is
If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big
messages, the source will not learn the actual path MTU.
Packetization Layer Path MTU Discovery [RFC4821] does not rely upon
network support for ICMPv6 messages and is therefore considered more
robust than standard PMTUD. It is not susceptible to "black holed"
connections caused by filtering of ICMPv6 message. See [RFC4890] for
recommendations regarding filtering ICMPv6 messages.
I know we don’t have a great story for discovering maximum packet
sizes, but I’d like to be at least as discouraging about PMTUD as RFC
8201, and concerns about earlier versions of the text almost prevented
RFC 8201 from being published as an Internet Standard, and I’m pretty
sure being more encouraging would gather Discusses -
https://datatracker.ietf.org/doc/rfc8201/history/ is instructive.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
