Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06

[Joe Touch <[e-mail]>]

Hi, Fred,


On 4/26/2017 1:08 PM, Fred Baker wrote:
>> Individual packets and fragments can be smaller than the MTU, of course.
>> Nothing forces fragments to push up against any MTU limit at all. But I
>> would not describe that has a host changing its path MTU; it's just
>> sending packets.
> I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). 
While it might apply differently based on port-based routing, path MTU
is an IP concept. It sets IP limits (MTU is an IP-ism, including all its
variants, such as EMTU_S, EMTUR, etc. - from RFC1122), which then
cascades into TCP limits (MSS and MMS_*, again per RFC1122).

And it's not the largest packet - it's strictly the largest IP fragment.
Transport uses that as the limit on IP messages to avoid fragmentation.
Technically, though, PMTU could also be used by the IP layer to guide
source fragmentation if the transport layer presents messages that are
too large to fit in a single datagram.

> I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.
TCP probably wouldn't, but UDP can, would, and does.

Joe