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

[David Lamparter <[e-mail]>]

On Thu, Apr 14, 2016 at 03:05:11PM +0200, [e-mail] wrote:
> >> what would be gain be to have a specific protocol to probe directly
> >> connected neighbors?
> > 
> > It can:
> > - work (pro-)actively and independent of higher-layer protocols,
> >  establishing MTU once
> 
> to a large extent we have failed at doing MTU discovery at the network layer.
> too hard, couldn't do it, let's make it someone else's problem. ;-)
> transport or application that is.

Might be either hope or naïvety, but I don't think we've failed (or even
tried) yet at the 1-hop 0-router case :).  There are way less pesky
ICMPv6-breaking devices in the middle...

> > - contain the different logic to understand that the router's MTU is the
> >  upper cap for all destinations behind that router
> > - contain the different probing parameters (being more aggressive) that
> >  are appropriate for a local network
> > - optionally carry extra information to reuse probing results across
> >  different addresses that a host has on a segment
> > 
> > I suppose this can be achieved by using a specialized version of 4821 on
> > the link... something like this:
> > 
> > - host does NS as usual, or catches unsolicited NA
> > - NA contains new "MTU discovery" option with contents:
> >  - indication of capability of first-hop MTU discovery
> >  - known maximum MRU of NA's sender (i.e. upper limit)
> >  - link-local address(?) + TCP port number(?) for PLMTUD probing
> > - host establishes one or more TCP sessions to that port with the
> >  express and only purpose of probing MTU
> >  (may as well do it on an existing TCP session if one exists)
> > - PLMTUD switches into some "first-hop" special mode (lower timers,
> >  parallel operation, different values) to establish and store the value
> >  with proper semantics (router case)
> > 
> > Is that what you have in mind?
> 
> I was thinking of something much simpler.
> the NS/NA MTU option triggers the stack (transport / application) to
> use packets up to that MTU.  the transport or application has to do
> normal PLMTUD.
> 
> think of it as if you had a p2p link to the neighbor and that the
> interface MTU was set to whatever you received in the MTU option from
> that neighbour.

I think the failure modes of that are way worse than with a dedicated
first-hop approach, especially for routers (interference from congestion
further down) but also for hosts (no parallel probing, and still need
special-casing to get more aggressive behaviour).

(cont'd below)

> an on-link router already advertises an MTU in an RA. I'm not sure if
> it would make sense if it advertised per neighbor MTU options, and how
> those should be interpreted.

The MTU advertised in the RA is for the link, not for the router.  In
particular, even when doing higher first-hop MTUs, this is the value for
all multicast packets.

If the router advertises a higher value through a separate new option,
the failure modes of that are very non-graceful:  a "non-jumbo" ethernet
switch in the middle causes every individual destination's PLMTUD to
fail independently, without the system having any chance to detect it as
an issue towards the router.


-David