> On 19. May 2021, at 18:18, Xin Long <lucien.xin@xxxxxxxxx> wrote: > > On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@xxxxxxxxx> wrote: >> >> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@xxxxxxxxxxx> wrote: >>> >>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@xxxxxxxxx> wrote: >>>> >>>> Hi, Michael, >>>> >>>> We're implementing RFC8899 (PLPMTUD) on Linux SCTP recently, >>>> and to make this be controlled by setsockopt with >>>> SCTP_PEER_ADDR_PARAMS, as in >>>> >>>> https://datatracker.ietf.org/doc/html/rfc6458#section-8.1.12: >>>> >>>> we need another two flags to add for spp_flags: >>>> >>>> SPP_PLPMTUD_ENABLE >>>> SPP_PLPMTUD_DISABLE >>>> >>>> Do you think it makes sense? if yes, does the RFC6458 need to update? >>>> if not, do you have a better suggestion for it? >>> It is great new that you want to implement RFC 8899. I plan to do the >>> same for the FreeBSD stack. >>> >>> In my view, RFC 8899 is the right way to implement PMTU discovery. >>> So I will just use the SPP_PMTUD_ENABLE and SPP_PMTUD_DISABLE. I don't >>> think that the user needs to control which method is used. >>> I you want to support multiple versions, I would make that >>> controllable via a sysctl variable. But I think for FreeBSD, support >>> for RFC 8899 will be the only way of doing PMTU discovery. There >>> might be multiple choices for details like how to do the searching, >>> how long to wait for some events. These will be controllable via >>> sysctl. >>> >>> So in my view, there is no need to extend the socket API. What do you think? > I just noticed that with multiple versions supported, and without extending > this API, all applications will have to use the same version as it's > controlled by > sysctl. And when switching to another version by sysctl, all > applications will be > affected and have to do the switch. that seems not nice. That is true, but an application can not expect any specific behaviour right now when they are not disabling PMTUD. What about adding a sysctl variable, which defines the default algorithm and a socket option, which allows to get and set the algorithm being used. Best regards Michael > >> OK, that makes sense to me. >> >> Another thing I want to know your opinion on is: do you think the HB >> should be created >> separately for PLPMTUD probe, instead of reusing the old HB that >> checks the link connectivity? >> As the HB for PLPMTUD probe might get lost, which we don't want to >> affect the link's >> connectivity. >> >>> >>> Best regards >>> Michael >>>> >>>> Thanks. >>>
