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

[[e-mail]]

Michaell,

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

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.


> There is another use for this MTU option:  it appears that it is sometimes
> possible to run both 802.15.4-2012 (the 127 byte version) and 802.15.4g (the
> 2K or something byte version) on the same radios.
> ("802.15.4-2015" includes 802.15.4g, btw, thus the need for a year to be precise)
> 
> A 15.4g MAC ought to be able to speak to a -2012 MAC by using all of our 6lowpan
> mechanisms, but two 15.4g would like to discover that they don't need to
> fragment.  I had *assumed* that the RA MTU option could be used for this, and
> was surprised when I read that it wasn't specified for this....
> 
> So I'm in favour of having this ND option defined; and I care not if it's a
> new number or reuses the RA number.

Best regards,
Ole