[sr-dev] [kamailio/kamailio] Path MTU discovery for IPv6 (PR #3141)

[vanrein]

Great summary!

I only respond to what I think is incorrect.

> 1. core option pmtu_discovery for IPv4
>   - if MTU is found, UDP will be delivered and kernel will store the discovered MTU internally
>   - further packets will use this value

no, ip(7) says for IP_PMTUDISC_DO

	It is the user's responsibility to packetize the data in
	MTU-sized chunks and to do the retransmits if necessary.
	The kernel will reject (with EMSGSIZE) datagrams that  are
	bigger than the known path MTU.

unlike what it says for IP_PMTUDISC_WANT

	IP_PMTUDISC_WANT will fragment a datagram if needed
	according to the path MTU, or will set the don't-fragment
	flag otherwise.

You can use _DO *if* you respond to EMSGSIZE, which Kamailio does
not seem to be doing.  Otherwise, go for _WANT.

> 3. suggestion in this PR for IPv6
>   - use IPV6_PMTUDISC_WANT as socket option
>   - will fragment a datagram if needed according to the path MTU for IPv6
>   - probably could be set by adding a new core option

Yes.  But I wonder if there could ever be a reason to use _DO.

> 4. suggestion in this PR for IPv4
>   - probably could be set by adding a new core option 

Yes.  And I do understand that deviation from the past needs an option for IPv4.

> My suggestion would be add a new value **2** to the pmtu_discovery core parameter, which sets then the _WANT socket option for IPv4 and IPv6.

That sounds like a good idea.

Thanks for helping to chew through this tough matter :)


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3141#issuecomment-1221504222
You are receiving this because you are subscribed to this thread.

Message ID: <kamailio/kamailio/pull/3141/c1221504222 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20220821/6d4e78f0/attachment.htm>