[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: draft-van-beijnum-multi-mtu-05.txt
From:       Erik Nordmark <nordmark () acm ! org>
Date:       2016-04-20 22:35:19
Message-ID: 57180427.2000504 () acm ! org
[Download RAW message or body]

On 4/14/16 5:30 AM, otroan@employees.org 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 <equinox@diac24.net> 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
> > > > ipv6@ietf.org
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]