Subject: IPV6_USE_MIN_MTU and TCP

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jul 2016 15:35:22 +1000

What does this list believe the advertised MSS should be on a TCP
connection if IPV6_USE_MIN_MTU=1 has been set on a socket?

What does this list believe the transmitted TCP segment size should
be on a TCP connection if IPV6_USE_MIN_MTU=1 has been set on a
socket?

This covers the inbound and outbound paths.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Jul 2016 14:32:52 +0200

>  connection if IPV6_USE_MIN_MTU=1 has been set on a socket?

=> IPV6_USE_MIN_MTU=1 means the PMTU doesn't work (broken, e.g.,
because of PTB ICMP filtering, or too slow, or ...). So the MTU
to use is 1280.

>  be on a TCP connection if IPV6_USE_MIN_MTU=1 has been set on a

=> either ignore the IPV6_USE_MIN_MTU=1 (perhaps not the best idea)
or use 1280-<sizes-of-headers>. Note in the first option it must
be consistent, i.e., not ignoring at the TCP layer and enforcing
it at the IP layer (one of the reasons IMHO it is not a good idea).

I don't remember if my IPv6 code implements it but for me the clear
way is to have a flag in the IP part of the PCB and to apply it
when the MSS in computed.

Regards

[email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Tue, 26 Jul 2016 14:32:03 -0700

At Fri, 22 Jul 2016 15:35:22 +1000,

> be on a TCP connection if IPV6_USE_MIN_MTU=1 has been set on a

I don't have a strong opinion, but for the latter it would be natural
to set it to 1280-<some margin> so the outgoing TCP packets sent from
the socket won't be fragmented.  For the former, I'm not sure -
essentially IPV6_USE_MIN_MTU is to avoid path MTU discovery, and PMTUD
is a one-way protocol.  In that sense it might be awkward if a node
that doesn't perform PMTUD tries to specify something about it.

In any case, I guess we implicitly ignored the use of the option for
TCP when we discussed the API spec that resulted in RFC3542.  The RFC
states:

   Unicast applications should usually let the kernel perform path MTU
   discovery [RFC-1981], as long as the kernel supports it, and should
   not care about the path MTU.  Some applications, however, might not
   want to incur the overhead of path MTU discovery, especially if the
   applications only send a single datagram to a destination.  A
   potential example is a DNS server.

I don't remember all details of the discussion at that time, but I
guess an unstated assumption here is that for TCP application this
"overhead" would usually be acceptable.  This is not to say we
shouldn't clarify the use of it for TCP today, though.  More recent
operational observations, most notably a view that "PMTUD is dead",
may require a revisit of this point.

--
JINMEI, Tatuya