Subject: [Taps] AD review of draft-ietf-taps-transports-usage-udp-04

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Aug 2017 15:09:49 -0500

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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 30 Aug 2017 08:35:59 +0100

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:
> probably better if you say that this document provided details for the 
> Pass 1 analysis of UDP and UDP-Lite that is used in 
> doing there? Perhaps “assist in application-level packetization that 
> would avoid IP fragmentation?”
>
> 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
>
> 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 - 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps