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

[[e-mail]]

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?

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
>>> --------------------------------------------------------------------
>> 
>