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

On 26/04/2017 21:30, Brian E Carpenter wrote:
> On 27/04/2017 08:08, Fred Baker wrote:
>>> On Apr 26, 2017, at 11:35 AM, Joe Touch <touch@isi.edu> wrote:
>>>
>>> Hi, Stewart,
>>>
>>>
>>> On 4/26/2017 1:48 AM, Stewart Bryant wrote:
>>>>
>>>> On 25/04/2017 19:26, Joe Touch wrote:
>>>>> Hi, Stewart,
>>>>>
>>>>> ...
>>>>>
>>>>>> SB>
>>>>>> SB> Otherwise I would have thought that this was entirely a matter
>>>>>> SB> for the host whether it wanted to use a Path MTU below the IPv6
>>>>>> SB> link minimum. Nothing breaks if the host takes a more conservative
>>>>>> SB> decision.
>>>>> I don't agree; the host at that point is violating RFC2460. It should
>>>>> never think that an IPv6 link or path with an MTU below what RFC2460
>>>>> requires is valid.
>>>>>
>>>>> Joe
>>>>>
>>>> That is as maybe, but a host can do more or less what it wants, so
>>>> this is surely an
>>>> unenforceable constraint, or are you telling me that the receiving
>>>> host MUST drop a
>>>> fragment that is shorter than this? In which case the question whether
>>>> in practice
>>>> they do, and whether such a constraint is reasonable.
>>> A "path MTU" is a value calculated from information from various sources
>>> (attached links, ICMP messages, and perhaps other information), but IMO
>>> it's never appropriate to set a "path MTU" smaller than the limit
>>> established by IPv6 for a single link.
>> You are, of course, quoting RFC 1981:
>>     A node MUST NOT reduce its estimate of the Path MTU below the IPv6
>>     minimum link MTU.
>>
>>> 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). 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.
> istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job) if the objective fact is that the path only transmits 1279 byte packets, what's best for the user?
>
>      Brian
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

So this seems to me to be an argument of principle vs pragmatism, and in 
general pragmatism has served the Internet well so far.

I think pragmatism is what Fred and Brian arguing for. It is certainly 
the general approach that I support.

I think we have agreed that nothing actually breaks if the host takes a 
more conservative approach, and that the communications path is less 
likely to be disrupted if that is what the host does. I would have 
thought that we should write the text in such a way to "allow" a 
pragmatic mode of operation.

- Stewart