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

[David Lamparter <[e-mail]>]

On Thu, Apr 07, 2016 at 10:27:07AM -0300, [e-mail] wrote:
> 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.

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