Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

HI Ben, Neil,

On Thu, Sep 22, 2011 at 2:44 PM, Benjamin Poirier
[off-list ref] wrote:

On 11-09-22 06:15, Michael Kerrisk wrote:

quoted

Ben, Neil,

[snip]

quoted

Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
applied that change for man-pages-3.34.

Ben, I added one small piece ti the description of
/proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
the entire text below. Perhaps you could take a quick scan, to make
sure that the changed text is consistent with the whole piece.

Thanks,

Michael

       IP_MTU_DISCOVER (since Linux 2.2)
              Set or receive the Path  MTU  Discovery  setting  for  a
              socket.   When enabled, Linux will perform Path MTU Dis-
              covery as defined in RFC 1191  on  SOCK_STREAM  sockets.

Oops, seems like there's a repetition that crept in here. I'd keep only
the first of those two sentences:

quoted

              For  non-SOCK_STREAM  sockets, IP_PMTUDISC_DO forces the
              don't-fragment flag to be set on all  outgoing  packets.
              The  don't-fragment  flag  is  set on all outgoing data-
              grams.

Thanks for catching that! The second of the above sentences is now gone.

quoted

               It is the user's responsibility to packetize the
              data  in  MTU-sized  chunks and to do the retransmits if
              necessary.  The kernel will reject (with EMSGSIZE) data-
              grams   that   are  bigger  than  the  known  path  MTU.
              IP_PMTUDISC_WANT will  fragment  a  datagram  if  needed
              according  to  the path MTU, or will set the don't-frag-
              ment flag otherwise.

              The system-wide default can be toggled between IP_PMTUD-
              ISC_WANT  and IP_PMTUDISC_DONT by writing (respectively,
              zero      and      nonzero      values)      to      the
              /proc/sys/net/ipv4/ip_no_pmtu_disc file.

I think it's a welcome clarification. Is is normal that IP_PMTUDISC_WANT
gets hyphenated?

That's just an artifact of groff formatting. One can prevent it, but
then the text justification of some lines starts to look very weird.

quoted

              Path MTU discovery flags   Meaning

I agree with what Neil said about "flags" here. setsockopt(2) calls
these "option values".

Changed this to just "value".

Other than that, LGTM
Acked-by: Benjamin Poirier <redacted>

Thanks Michael,
-Ben

You're welcome. Thanks for taking the time to write the text and check my work.

Cheers,

Michael

quoted

              IP_PMTUDISC_WANT           Use per-route settings.
              IP_PMTUDISC_DONT           Never do Path MTU Discovery.
              IP_PMTUDISC_DO             Always do Path MTU Discovery.
              IP_PMTUDISC_PROBE          Set DF but ignore Path MTU.

              When PMTU discovery is enabled, the kernel automatically
              keeps track of the path MTU per destination host.   When
              it  is connected to a specific peer with connect(2), the
              currently known path MTU can be  retrieved  conveniently
              using  the IP_MTU socket option (e.g., after an EMSGSIZE
              error occurred).  The path MTU  may  change  over  time.
              For  connectionless  sockets with many destinations, the
              new MTU for a given destination  can  also  be  accessed
              using  the  error  queue  (see IP_RECVERR).  A new error
              will be queued for every incoming MTU update.

              While MTU discovery is in progress, initial packets from
              datagram sockets may be dropped.  Applications using UDP
              should be aware of this and not take it into account for
              their packet retransmit strategy.

              To  bootstrap  the  path MTU discovery process on uncon-
              nected sockets, it is possible to start with a big data-
              gram  size  (up  to  64K-headers  bytes long) and let it
              shrink by updates of the path MTU.

              To get an initial estimate of the path  MTU,  connect  a
              datagram  socket  to  the destination address using con-
              nect(2) and retrieve the MTU  by  calling  getsockopt(2)
              with the IP_MTU option.

              It  is  possible  to implement RFC 4821 MTU probing with
              SOCK_DGRAM or SOCK_RAW sockets by  setting  a  value  of
              IP_PMTUDISC_PROBE  (available since Linux 2.6.22).  This
              is also particularly useful for diagnostic tools such as
              tracepath(8)  that wish to deliberately send probe pack-
              ets larger than the observed Path MTU.


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/