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