Re: draft-van-beijnum-multi-mtu-05.txt

[Erik Nordmark <[e-mail]>]

On 4/14/16 5:30 AM, [e-mail] wrote:
> David,
>
>>> In general I'd prefer that we reuse existing mechanisms for path mtu
>>> discovery, and not invent new ones purely for the case of two directly
>>> connected neighbors.
>> That's actually the crux of it: this isn't Path MTU discovery.  The MTU
>> discovered by this mechanism is the first-hop MTU for a lot of paths in
>> case of a router and it's going to be distinct from the final PMTU
>> towards a particular destination.  Plus, state on this only ever exists
>> for direct neighbors, not for any random internet host.
> why couldn't it be done as end-to-end MTU?
>
> the directly connected mechanism would be just to give a hint that there might be nodes here capable of a higher MTU. then do normal MTU probing / detection.
>
> what would be gain be to have a specific protocol to probe directly connected neighbors?

Ole,

AFAIR PLMTUD has an upper limit which is the interface MTU.
Thus at least an implementation would need to handle per neighbor MTU 
instead of per-interface. But that doesn't require any new protocol 
behavior.

If we suppose a mixture of nodes on a link - some with per-neighbor and 
some per-interface, then I think things will work slightly more 
efficiently if a per-neighbor node can easily tell whether to bother 
with something larger than the default interface MTU (often 1500); 
receiving some new flag or MTU value in a NS/NA would be sufficient as a 
hint to try larger.
That might also help with corner cases where some old NICs fail/reset in 
interesting ways if they receive a 9k frame.

FWIW I think it is a good idea to couple this with implementing PLMTUD. 
That way at most we need a hint to try larger with the actual probing 
being done as part of PLMTUD.

    Erik

>
> Best,
> Ole
>
>>> Could we make this work by adding the RFC4861 MTU option to NS/NA
>>> messages, and require that PLMTUD probing is used to verify the end to
>>> end MTU.
>> It's not end-to-end MTU...
>>
>>> Then the mechanism used is the same for directly connected neighbors
>>> and off-link neighbors (apart from the initial discovery).
>> Well, it'd be possible to distinguish first-hop failures from failures
>> later in the path, but with a router there's rarely a direct TCP
>> connection to it to do PLMTUD on.
>>
>> Either way this really needs at least different handling from end-to-end
>> MTU in order to not keep probing towards a router whenever a host
>> decides to talk to another destination in the internet.  Some first-hop
>> neighbor concept...
>>
>> If probing hosts for each of their addresses can be avoided, that might
>> be useful too, but that's far less of an issue (and harder to do) than
>> not probing routers for every single internet destination.
>>
>>> If we were to invent new probing mechanisms, I would hope we did so
>>> under the PLMTUD (4821) umbrella.
>> Hm.  Maybe the draft can be rewritten as extension to 4821, but quite a
>> few things are different with reason -- not sure this is that good of a
>> fit...
>>
>> Cheers,
>>
>> -David
>>
>>> Best regards,
>>> Ole
>>>
>>>> On 06 Apr 2016, at 19:04, David Lamparter <[e-mail]> wrote:
>>>>
>>>> On Wed, Apr 06, 2016 at 11:20:48PM +0200, David Lamparter wrote:
>>>>> On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote:
>>>>>> On 4/6/16 12:18 PM, David Lamparter wrote:
>>>>>>> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote:
>>>>>>> Ok... easy comments/opinions first:
>>>>>>> - should definitely be ICMP, not UDP.  Erik Nordmark's suggestion to
>>>>>>>   piggyback on NUD sounds great, though admittedly I haven't thought it
>>>>>>>   through looking for pitfalls.
>>>>>> One issue compared to a dedicate probe is that a NUD (a unicast NS) of
>>>>>> size X wouldn't necessarily result in a unicast NA that is also padded;
>>>>>> perhaps one can add such behavior so that we can get the bidirectional
>>>>>> probe in both directions.
>>>>> That might be (half of) a feature: if the MTU probe is a NS option, and
>>>>> the target host does not support it, we still get a NA reply.  That's
>>>>> better than timing out waiting.  The downside is that a NA without the
>>>>> "MTU response" option doesn't mean that the host doesn't implement the
>>>>> protocol -- the NA could be in response to something else.
>>>> Obvious easy way: have the "ND NODEMTU" option described in draft sec. 5
>>>> mandatory on all NAs if the host implements the protocol; receipt of any
>>>> NA without the option can then flag the sender as mtu-probe-incapable.
>>>>
>>>> (Not sure if the last paragraph of sec. 9.1 already implies the option
>>>> MUST be put on all NAs and NSs?  Certainly needs better wording.)
>>>>
>>>> -David
>>>>
>>>>> That said, I'd expect the probability of a host ignoring a new NS option
>>>>> is much lower than it filtering out unknown new ICMP (sub)types or UDP
>>>>> ports.  If that reduces useless probing (or even waiting), I'm all for
>>>>> it.
>>>>>
>>>>> (As I understand it, the draft in no case suggests waiting for the
>>>>> probes to come back, so it's not much of an argument.  Might still
>>>>> reduce useless probe traffic?)
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------