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

[Michael Richardson <[e-mail]>]

[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.
    >>
    >>> 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.
    >>
    >> Yes, but plmtud can only be provided as a service to applications when they
    >> use TCP or SCTP.  It can't find bigger UDP paths at present: that would have
    >> to be built in to the application.  But, the kernel can provide the service
    >> for UDP users by doing the discovery in NUD....
    >> Basically we can run the plpmtud mechanism with NUD in the kernel.

    > UDP applications already need to do that today.

Yes, that's a good point.
In v4-land, we can just send and experience fragmentation.
In v6, we can't, so most WAN applications that care about >1280 always
include fragmentation at that level regardless.  So you are right: the
applications already do it.

There is a class of application that is today running over LANs using UDP.
I recall the days of "HIPPI" which had 64K packet sizes doing stuff.
I have an ATSC TV tuner that does this, and I've seen IP audio applications
that also do the same.  Right now, I think they don't even have default
route support...  I think that those devices could benefit from the ND solution.

    > Isn't it a great step backwards if an application first has to detect
    > if the peer is directly connected or not, and behave differently
    > depending on the answer?

Yes, that's a good point. So I withdraw my suggestion... the question is
perhaps, can we come up with a slightly application-neutral way to do
plpmtud.  I suspect that SPUD already provides this.

    > Path MTU is a path property. I'm reluctant to make too much out of a
    > special case where path length is 1.

    > I do agree that we need to do something in ND to allow nodes capable of
    > a higher MTU than the RA advertised default MTU to signal that between
    > each other.

Good.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-