* add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags @ 2021-05-18 16:43 Xin Long 2021-05-18 17:38 ` Michael Tuexen 0 siblings, 1 reply; 17+ messages in thread From: Xin Long @ 2021-05-18 16:43 UTC (permalink / raw) To: Michael Tuexen, linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner 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? Thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-18 16:43 add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags Xin Long @ 2021-05-18 17:38 ` Michael Tuexen 2021-05-18 18:33 ` Xin Long 0 siblings, 1 reply; 17+ messages in thread From: Michael Tuexen @ 2021-05-18 17:38 UTC (permalink / raw) To: Xin Long; +Cc: linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner > On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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? Best regards Michael > > Thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-18 17:38 ` Michael Tuexen @ 2021-05-18 18:33 ` Xin Long 2021-05-18 19:19 ` Michael Tuexen 2021-05-19 16:18 ` Xin Long 0 siblings, 2 replies; 17+ messages in thread From: Xin Long @ 2021-05-18 18:33 UTC (permalink / raw) To: Michael Tuexen; +Cc: linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > > > On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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? 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. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-18 18:33 ` Xin Long @ 2021-05-18 19:19 ` Michael Tuexen 2021-05-19 22:24 ` mleitner 2021-05-19 16:18 ` Xin Long 1 sibling, 1 reply; 17+ messages in thread From: Michael Tuexen @ 2021-05-18 19:19 UTC (permalink / raw) To: Xin Long; +Cc: linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner > On 18. May 2021, at 20:33, Xin Long <lucien.xin@gmail.com> wrote: > > On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: >> >>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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? > 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? Yes. I think testing for connectivity is conceptually different from testing a particular PMTU. When testing for PMTU, I think about sending probe packets. Not that they consist of a HB chunk bundled with a PAD chunk. > As the HB for PLPMTUD probe might get lost, which we don't want to > affect the link's > connectivity. Yes, I agree completely. Best regards Michael > >> >> Best regards >> Michael >>> >>> Thanks. >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-18 19:19 ` Michael Tuexen @ 2021-05-19 22:24 ` mleitner 2021-05-20 2:05 ` Xin Long 0 siblings, 1 reply; 17+ messages in thread From: mleitner @ 2021-05-19 22:24 UTC (permalink / raw) To: Michael Tuexen; +Cc: Xin Long, linux-sctp @ vger . kernel . org On Tue, May 18, 2021 at 09:19:21PM +0200, Michael Tuexen wrote: > > > > On 18. May 2021, at 20:33, Xin Long <lucien.xin@gmail.com> wrote: > > > > On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > >> > >>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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? > > 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? > Yes. I think testing for connectivity is conceptually different > from testing a particular PMTU. When testing for PMTU, I think > about sending probe packets. Not that they consist of a HB chunk > bundled with a PAD chunk. > > As the HB for PLPMTUD probe might get lost, which we don't want to > > affect the link's > > connectivity. > Yes, I agree completely. With this, Xin, seems we should have a separate timer for the PROBE_TIMER, other than the heartbeat one. Otherwise, converging the two logics into one single timer is not worth the hassle for saving a timer. For example, we would have to have it fire on the active transport but to send only the probe. Also, considering they can and (AFAIU the RFC) should have different expire timeouts from time to time. With a separate timer, we won't have issues converging the user-selectable heartbeat interval to the recommended 600s PMTU_RAISE_TIMER, for example. Maybe I am missing something. But it seems the hassle for reusing the timer here is just not worth it. Thoughts? Best, Marcelo > > Best regards > Michael > > > >> > >> Best regards > >> Michael > >>> > >>> Thanks. > >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-19 22:24 ` mleitner @ 2021-05-20 2:05 ` Xin Long 2021-05-20 7:06 ` tuexen 0 siblings, 1 reply; 17+ messages in thread From: Xin Long @ 2021-05-20 2:05 UTC (permalink / raw) To: Marcelo Ricardo Leitner; +Cc: Michael Tuexen, linux-sctp @ vger . kernel . org On Wed, May 19, 2021 at 6:24 PM <mleitner@redhat.com> wrote: > > On Tue, May 18, 2021 at 09:19:21PM +0200, Michael Tuexen wrote: > > > > > > > On 18. May 2021, at 20:33, Xin Long <lucien.xin@gmail.com> wrote: > > > > > > On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > > >> > > >>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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? > > > 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? > > Yes. I think testing for connectivity is conceptually different > > from testing a particular PMTU. When testing for PMTU, I think > > about sending probe packets. Not that they consist of a HB chunk > > bundled with a PAD chunk. > > > As the HB for PLPMTUD probe might get lost, which we don't want to > > > affect the link's > > > connectivity. > > Yes, I agree completely. > > With this, Xin, seems we should have a separate timer for the > PROBE_TIMER, other than the heartbeat one. > > Otherwise, converging the two logics into one single timer is not > worth the hassle for saving a timer. For example, we would have to > have it fire on the active transport but to send only the probe. > Also, considering they can and (AFAIU the RFC) should have different > expire timeouts from time to time. > > With a separate timer, we won't have issues converging the > user-selectable heartbeat interval to the recommended 600s > PMTU_RAISE_TIMER, for example. > > Maybe I am missing something. But it seems the hassle for reusing the > timer here is just not worth it. Thoughts? You're right, when I was doing testing, I had to set the hb_interval to 5s. the common value of hb_interval really doesn't fit in the probe_interval. I will try adding a new timer, but at the same time a probe_interval by sysctl/sockopt may be needed, or we can use a value equal to (hb_interval / n) for it? > > Best, > Marcelo > > > > > Best regards > > Michael > > > > > >> > > >> Best regards > > >> Michael > > >>> > > >>> Thanks. > > >> > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-20 2:05 ` Xin Long @ 2021-05-20 7:06 ` tuexen 2021-05-20 15:13 ` Xin Long 0 siblings, 1 reply; 17+ messages in thread From: tuexen @ 2021-05-20 7:06 UTC (permalink / raw) To: Xin Long Cc: Marcelo Ricardo Leitner, linux-sctp @ vger . kernel . org, Timo Völker > On 20. May 2021, at 04:05, Xin Long <lucien.xin@gmail.com> wrote: > > On Wed, May 19, 2021 at 6:24 PM <mleitner@redhat.com> wrote: >> >> On Tue, May 18, 2021 at 09:19:21PM +0200, Michael Tuexen wrote: >>> >>> >>>> On 18. May 2021, at 20:33, Xin Long <lucien.xin@gmail.com> wrote: >>>> >>>> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: >>>>> >>>>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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? >>>> 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? >>> Yes. I think testing for connectivity is conceptually different >>> from testing a particular PMTU. When testing for PMTU, I think >>> about sending probe packets. Not that they consist of a HB chunk >>> bundled with a PAD chunk. >>>> As the HB for PLPMTUD probe might get lost, which we don't want to >>>> affect the link's >>>> connectivity. >>> Yes, I agree completely. >> >> With this, Xin, seems we should have a separate timer for the >> PROBE_TIMER, other than the heartbeat one. >> >> Otherwise, converging the two logics into one single timer is not >> worth the hassle for saving a timer. For example, we would have to >> have it fire on the active transport but to send only the probe. >> Also, considering they can and (AFAIU the RFC) should have different >> expire timeouts from time to time. >> >> With a separate timer, we won't have issues converging the >> user-selectable heartbeat interval to the recommended 600s >> PMTU_RAISE_TIMER, for example. >> >> Maybe I am missing something. But it seems the hassle for reusing the >> timer here is just not worth it. Thoughts? > You're right, when I was doing testing, I had to set the hb_interval to 5s. > the common value of hb_interval really doesn't fit in the probe_interval. > I will try adding a new timer, but at the same time a probe_interval > by sysctl/sockopt may be needed, or we can use a value equal to > (hb_interval / n) for it? Yeah, this is why I did not write a socket API section for RFC 8899. I think when implementing it, one will find some parameters which can or should be controlled by the application. So I guess there will be more than this one. Timo (CCed) is working on some algorithmic explorations, since RFC 8899, gives you some freedom. Right now, his work is done in a simulation environment, but once that is finished and he came to some conclusions, we will implement this. So what about: * Try to implement PLPMTUD and figure out what you need as user controllable parameters. * Bring this up for discussion and we can agree on them and also on how to control them via socket options. * Then you get the code into the Linux tree. That way we would know what parameters are really needed in an implementation and we would have a common interface. Does that make sense to you and sounds like an acceptable plan? Best regards Michael > >> >> Best, >> Marcelo >> >>> >>> Best regards >>> Michael >>>> >>>>> >>>>> Best regards >>>>> Michael >>>>>> >>>>>> Thanks. >>>>> >>> >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-20 7:06 ` tuexen @ 2021-05-20 15:13 ` Xin Long 0 siblings, 0 replies; 17+ messages in thread From: Xin Long @ 2021-05-20 15:13 UTC (permalink / raw) To: Michael Tuexen Cc: Marcelo Ricardo Leitner, linux-sctp @ vger . kernel . org, Timo Völker On Thu, May 20, 2021 at 3:06 AM <tuexen@freebsd.org> wrote: > > > On 20. May 2021, at 04:05, Xin Long <lucien.xin@gmail.com> wrote: > > > > On Wed, May 19, 2021 at 6:24 PM <mleitner@redhat.com> wrote: > >> > >> On Tue, May 18, 2021 at 09:19:21PM +0200, Michael Tuexen wrote: > >>> > >>> > >>>> On 18. May 2021, at 20:33, Xin Long <lucien.xin@gmail.com> wrote: > >>>> > >>>> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > >>>>> > >>>>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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? > >>>> 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? > >>> Yes. I think testing for connectivity is conceptually different > >>> from testing a particular PMTU. When testing for PMTU, I think > >>> about sending probe packets. Not that they consist of a HB chunk > >>> bundled with a PAD chunk. > >>>> As the HB for PLPMTUD probe might get lost, which we don't want to > >>>> affect the link's > >>>> connectivity. > >>> Yes, I agree completely. > >> > >> With this, Xin, seems we should have a separate timer for the > >> PROBE_TIMER, other than the heartbeat one. > >> > >> Otherwise, converging the two logics into one single timer is not > >> worth the hassle for saving a timer. For example, we would have to > >> have it fire on the active transport but to send only the probe. > >> Also, considering they can and (AFAIU the RFC) should have different > >> expire timeouts from time to time. > >> > >> With a separate timer, we won't have issues converging the > >> user-selectable heartbeat interval to the recommended 600s > >> PMTU_RAISE_TIMER, for example. > >> > >> Maybe I am missing something. But it seems the hassle for reusing the > >> timer here is just not worth it. Thoughts? > > You're right, when I was doing testing, I had to set the hb_interval to 5s. > > the common value of hb_interval really doesn't fit in the probe_interval. > > I will try adding a new timer, but at the same time a probe_interval > > by sysctl/sockopt may be needed, or we can use a value equal to > > (hb_interval / n) for it? > Yeah, this is why I did not write a socket API section for RFC 8899. I think > when implementing it, one will find some parameters which can or should > be controlled by the application. So I guess there will be more than this > one. > > Timo (CCed) is working on some algorithmic explorations, since RFC 8899, gives > you some freedom. Right now, his work is done in a simulation environment, but > once that is finished and he came to some conclusions, we will implement this. > > So what about: > > * Try to implement PLPMTUD and figure out what you need as user controllable > parameters. > * Bring this up for discussion and we can agree on them and also on how > to control them via socket options. > * Then you get the code into the Linux tree. > > That way we would know what parameters are really needed in an implementation > and we would have a common interface. Makes sense. > > Does that make sense to you and sounds like an acceptable plan? That sounds a good plan, :-) Thanks. > > Best regards > Michael > > > >> > >> Best, > >> Marcelo > >> > >>> > >>> Best regards > >>> Michael > >>>> > >>>>> > >>>>> Best regards > >>>>> Michael > >>>>>> > >>>>>> Thanks. > >>>>> > >>> > >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-18 18:33 ` Xin Long 2021-05-18 19:19 ` Michael Tuexen @ 2021-05-19 16:18 ` Xin Long 2021-05-19 18:15 ` Michael Tuexen 1 sibling, 1 reply; 17+ messages in thread From: Xin Long @ 2021-05-19 16:18 UTC (permalink / raw) To: Michael Tuexen; +Cc: linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: > > On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > > > > > On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. > 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. > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-19 16:18 ` Xin Long @ 2021-05-19 18:15 ` Michael Tuexen 2021-05-19 18:44 ` Xin Long 0 siblings, 1 reply; 17+ messages in thread From: Michael Tuexen @ 2021-05-19 18:15 UTC (permalink / raw) To: Xin Long; +Cc: linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner > On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: > > On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: >> >> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: >>> >>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. >>> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-19 18:15 ` Michael Tuexen @ 2021-05-19 18:44 ` Xin Long 2021-05-19 22:44 ` mleitner 2021-05-19 23:10 ` Michael Tuexen 0 siblings, 2 replies; 17+ messages in thread From: Xin Long @ 2021-05-19 18:44 UTC (permalink / raw) To: Michael Tuexen; +Cc: linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner On Wed, May 19, 2021 at 2:15 PM Michael Tuexen <tuexen@freebsd.org> wrote: > > > On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: > > > > On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: > >> > >> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > >>> > >>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. yes, that's also what I'm thinking. sysctl is always used for the default value for future sockets. and the socket option should be added for a socket/asoc's setting. SCTP_PTMUD_METHOD? 0: PTB one 1. PLPMTUD > > 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. > >>> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-19 18:44 ` Xin Long @ 2021-05-19 22:44 ` mleitner 2021-05-19 23:16 ` Michael Tuexen 2021-05-19 23:10 ` Michael Tuexen 1 sibling, 1 reply; 17+ messages in thread From: mleitner @ 2021-05-19 22:44 UTC (permalink / raw) To: Xin Long; +Cc: Michael Tuexen, linux-sctp @ vger . kernel . org On Wed, May 19, 2021 at 02:44:20PM -0400, Xin Long wrote: > On Wed, May 19, 2021 at 2:15 PM Michael Tuexen <tuexen@freebsd.org> wrote: > > > > > On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: > > > > > > On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: > > >> > > >> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > > >>> > > >>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. > yes, that's also what I'm thinking. +1 > sysctl is always used for the default value for future sockets. > and the socket option should be added for a socket/asoc's setting. Speaking of inheritance, it should also use the SCTP_FUTURE_ASSOC / SCTP_CURRENT_ASSOC / SCTP_ALL_ASSOC mechanism. Like SCTP_PEER_ADDR_PARAMS, for example. The system can provide defaults but if the application requires something, it should have a good way of requesting it. Speaking of SCTP_PEER_ADDR_PARAMS, maybe reuse spp_pathmtu field? As in, if SPP_PMTUD_ENABLE is enabled, spp_pathmtu of "1" or "2" bytes doesn't make sense, and it could mean the algorithm used. Thing is, the field is currently ignored, and it could lead to some unexpected behavior change. It's probably safer to just add another sockopt, but wanted to share the idea anyway. > > SCTP_PTMUD_METHOD? s/PTMUD/PMTUD/ :-) > 0: PTB one > 1. PLPMTUD > > > > > 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. > > >>> > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-19 22:44 ` mleitner @ 2021-05-19 23:16 ` Michael Tuexen 2021-05-20 0:45 ` Marcelo Ricardo Leitner 0 siblings, 1 reply; 17+ messages in thread From: Michael Tuexen @ 2021-05-19 23:16 UTC (permalink / raw) To: mleitner; +Cc: Xin Long, linux-sctp @ vger . kernel . org > On 20. May 2021, at 00:44, mleitner@redhat.com wrote: > > On Wed, May 19, 2021 at 02:44:20PM -0400, Xin Long wrote: >> On Wed, May 19, 2021 at 2:15 PM Michael Tuexen <tuexen@freebsd.org> wrote: >>> >>>> On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: >>>> >>>> On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: >>>>> >>>>> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: >>>>>> >>>>>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. >> yes, that's also what I'm thinking. > > +1 > >> sysctl is always used for the default value for future sockets. >> and the socket option should be added for a socket/asoc's setting. > > Speaking of inheritance, it should also use the SCTP_FUTURE_ASSOC / > SCTP_CURRENT_ASSOC / SCTP_ALL_ASSOC mechanism. Like > SCTP_PEER_ADDR_PARAMS, for example. Yepp. > > The system can provide defaults but if the application requires > something, it should have a good way of requesting it. > > Speaking of SCTP_PEER_ADDR_PARAMS, maybe reuse spp_pathmtu field? > As in, if SPP_PMTUD_ENABLE is enabled, spp_pathmtu of "1" or "2" bytes > doesn't make sense, and it could mean the algorithm used. Thing is, > the field is currently ignored, and it could lead to some unexpected > behavior change. It's probably safer to just add another sockopt, but > wanted to share the idea anyway. I leave it completely up to you what you implement in Linux. But I would prefer to use a separate socket option instead of overloading an existing one. Best regards Michael > >> >> SCTP_PTMUD_METHOD? > > s/PTMUD/PMTUD/ :-) > >> 0: PTB one >> 1. PLPMTUD >> >>> >>> 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. >>>>>> >>> >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-19 23:16 ` Michael Tuexen @ 2021-05-20 0:45 ` Marcelo Ricardo Leitner 2021-05-20 6:59 ` tuexen 0 siblings, 1 reply; 17+ messages in thread From: Marcelo Ricardo Leitner @ 2021-05-20 0:45 UTC (permalink / raw) To: Michael Tuexen; +Cc: Xin Long, linux-sctp @ vger . kernel . org On Thu, May 20, 2021 at 01:16:38AM +0200, Michael Tuexen wrote: > > On 20. May 2021, at 00:44, mleitner@redhat.com wrote: > > > > On Wed, May 19, 2021 at 02:44:20PM -0400, Xin Long wrote: > >> On Wed, May 19, 2021 at 2:15 PM Michael Tuexen <tuexen@freebsd.org> wrote: > >>> > >>>> On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: > >>>> > >>>> On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: > >>>>> > >>>>> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > >>>>>> > >>>>>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. > >> yes, that's also what I'm thinking. > > > > +1 > > > >> sysctl is always used for the default value for future sockets. > >> and the socket option should be added for a socket/asoc's setting. > > > > Speaking of inheritance, it should also use the SCTP_FUTURE_ASSOC / > > SCTP_CURRENT_ASSOC / SCTP_ALL_ASSOC mechanism. Like > > SCTP_PEER_ADDR_PARAMS, for example. > Yepp. > > > > The system can provide defaults but if the application requires > > something, it should have a good way of requesting it. > > > > Speaking of SCTP_PEER_ADDR_PARAMS, maybe reuse spp_pathmtu field? > > As in, if SPP_PMTUD_ENABLE is enabled, spp_pathmtu of "1" or "2" bytes > > doesn't make sense, and it could mean the algorithm used. Thing is, > > the field is currently ignored, and it could lead to some unexpected > > behavior change. It's probably safer to just add another sockopt, but > > wanted to share the idea anyway. > I leave it completely up to you what you implement in Linux. But I > would prefer to use a separate socket option instead of overloading > an existing one. Wait. Somehow I thought we were talking about extending the RFC with these new definitions here, no? Or at least agreeing on a common interface. It would be beneficial for the application to be able to use the same API on FreeBSD or Linux. Thanks, Marcelo > > Best regards > Michael > > > >> > >> SCTP_PTMUD_METHOD? > > > > s/PTMUD/PMTUD/ :-) > > > >> 0: PTB one > >> 1. PLPMTUD > >> > >>> > >>> 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. > >>>>>> > >>> > >> > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-20 0:45 ` Marcelo Ricardo Leitner @ 2021-05-20 6:59 ` tuexen 2021-05-20 19:27 ` Marcelo Ricardo Leitner 0 siblings, 1 reply; 17+ messages in thread From: tuexen @ 2021-05-20 6:59 UTC (permalink / raw) To: Marcelo Ricardo Leitner; +Cc: Xin Long, linux-sctp @ vger . kernel . org > On 20. May 2021, at 02:45, Marcelo Ricardo Leitner <mleitner@redhat.com> wrote: > > On Thu, May 20, 2021 at 01:16:38AM +0200, Michael Tuexen wrote: >>> On 20. May 2021, at 00:44, mleitner@redhat.com wrote: >>> >>> On Wed, May 19, 2021 at 02:44:20PM -0400, Xin Long wrote: >>>> On Wed, May 19, 2021 at 2:15 PM Michael Tuexen <tuexen@freebsd.org> wrote: >>>>> >>>>>> On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: >>>>>> >>>>>> On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: >>>>>>> >>>>>>> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: >>>>>>>> >>>>>>>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. >>>> yes, that's also what I'm thinking. >>> >>> +1 >>> >>>> sysctl is always used for the default value for future sockets. >>>> and the socket option should be added for a socket/asoc's setting. >>> >>> Speaking of inheritance, it should also use the SCTP_FUTURE_ASSOC / >>> SCTP_CURRENT_ASSOC / SCTP_ALL_ASSOC mechanism. Like >>> SCTP_PEER_ADDR_PARAMS, for example. >> Yepp. >>> >>> The system can provide defaults but if the application requires >>> something, it should have a good way of requesting it. >>> >>> Speaking of SCTP_PEER_ADDR_PARAMS, maybe reuse spp_pathmtu field? >>> As in, if SPP_PMTUD_ENABLE is enabled, spp_pathmtu of "1" or "2" bytes >>> doesn't make sense, and it could mean the algorithm used. Thing is, >>> the field is currently ignored, and it could lead to some unexpected >>> behavior change. It's probably safer to just add another sockopt, but >>> wanted to share the idea anyway. >> I leave it completely up to you what you implement in Linux. But I >> would prefer to use a separate socket option instead of overloading >> an existing one. > > Wait. Somehow I thought we were talking about extending the RFC with > these new definitions here, no? Or at least agreeing on a common > interface. It would be beneficial for the application to be able to > use the same API on FreeBSD or Linux. Hi Marcelo, sorry for not being clear. What I wanted to say: 1. I really appreciate the discussion and I agree that it would be great if we can agree on a common interface allowing to write portable applications. 2. I don't like the idea of overloading the spp_pathmtu. 3. I'm not in a position to put in a veto to what anyone is implementing in any implementation (except maybe the FreeBSD implementation). Regarding the extension of the RFC. An RFC can't be changed. One can file erratas, but I think we are discussing here an extension of the socket API to cope with RFC 8899. So I don't think it is an errata. It would have been appropriate to add a socket API section to RFC 8899, but it is too late for that, too. So I guess we can discuss it here and come to an agreement how to extend the socket API for RFC 8899. I'm more that happy to do this. I hope I expressed my view now clearer. Best regards Michael > > Thanks, > Marcelo > >> >> Best regards >> Michael >>> >>>> >>>> SCTP_PTMUD_METHOD? >>> >>> s/PTMUD/PMTUD/ :-) >>> >>>> 0: PTB one >>>> 1. PLPMTUD >>>> >>>>> >>>>> 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. >>>>>>>> >>>>> >>>> >>> >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-20 6:59 ` tuexen @ 2021-05-20 19:27 ` Marcelo Ricardo Leitner 0 siblings, 0 replies; 17+ messages in thread From: Marcelo Ricardo Leitner @ 2021-05-20 19:27 UTC (permalink / raw) To: tuexen; +Cc: Xin Long, linux-sctp @ vger . kernel . org On Thu, May 20, 2021 at 08:59:49AM +0200, tuexen@freebsd.org wrote: > > On 20. May 2021, at 02:45, Marcelo Ricardo Leitner <mleitner@redhat.com> wrote: > > > > On Thu, May 20, 2021 at 01:16:38AM +0200, Michael Tuexen wrote: > >>> On 20. May 2021, at 00:44, mleitner@redhat.com wrote: > >>> > >>> On Wed, May 19, 2021 at 02:44:20PM -0400, Xin Long wrote: > >>>> On Wed, May 19, 2021 at 2:15 PM Michael Tuexen <tuexen@freebsd.org> wrote: > >>>>> > >>>>>> On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: > >>>>>> > >>>>>> On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: > >>>>>>> > >>>>>>> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: > >>>>>>>> > >>>>>>>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. > >>>> yes, that's also what I'm thinking. > >>> > >>> +1 > >>> > >>>> sysctl is always used for the default value for future sockets. > >>>> and the socket option should be added for a socket/asoc's setting. > >>> > >>> Speaking of inheritance, it should also use the SCTP_FUTURE_ASSOC / > >>> SCTP_CURRENT_ASSOC / SCTP_ALL_ASSOC mechanism. Like > >>> SCTP_PEER_ADDR_PARAMS, for example. > >> Yepp. > >>> > >>> The system can provide defaults but if the application requires > >>> something, it should have a good way of requesting it. > >>> > >>> Speaking of SCTP_PEER_ADDR_PARAMS, maybe reuse spp_pathmtu field? > >>> As in, if SPP_PMTUD_ENABLE is enabled, spp_pathmtu of "1" or "2" bytes > >>> doesn't make sense, and it could mean the algorithm used. Thing is, > >>> the field is currently ignored, and it could lead to some unexpected > >>> behavior change. It's probably safer to just add another sockopt, but > >>> wanted to share the idea anyway. > >> I leave it completely up to you what you implement in Linux. But I > >> would prefer to use a separate socket option instead of overloading > >> an existing one. > > > > Wait. Somehow I thought we were talking about extending the RFC with > > these new definitions here, no? Or at least agreeing on a common > > interface. It would be beneficial for the application to be able to > > use the same API on FreeBSD or Linux. > Hi Marcelo, Hi! > > sorry for not being clear. > > What I wanted to say: > > 1. I really appreciate the discussion and I agree that it would be great +1 > if we can agree on a common interface allowing to write portable > applications. > > 2. I don't like the idea of overloading the spp_pathmtu. Me neither. :D > > 3. I'm not in a position to put in a veto to what anyone is implementing > in any implementation (except maybe the FreeBSD implementation). > > Regarding the extension of the RFC. An RFC can't be changed. One can file > erratas, but I think we are discussing here an extension of the socket API > to cope with RFC 8899. So I don't think it is an errata. It would have been > appropriate to add a socket API section to RFC 8899, but it is too late for > that, too. > > So I guess we can discuss it here and come to an agreement how to extend > the socket API for RFC 8899. I'm more that happy to do this. Nice. Okay. > > I hope I expressed my view now clearer. Yep. On the same page now, thanks. :-) Best regards, Marcelo > > Best regards > Michael > > > > > > Thanks, > > Marcelo > > > >> > >> Best regards > >> Michael > >>> > >>>> > >>>> SCTP_PTMUD_METHOD? > >>> > >>> s/PTMUD/PMTUD/ :-) > >>> > >>>> 0: PTB one > >>>> 1. PLPMTUD > >>>> > >>>>> > >>>>> 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. > >>>>>>>> > >>>>> > >>>> > >>> > >> > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags 2021-05-19 18:44 ` Xin Long 2021-05-19 22:44 ` mleitner @ 2021-05-19 23:10 ` Michael Tuexen 1 sibling, 0 replies; 17+ messages in thread From: Michael Tuexen @ 2021-05-19 23:10 UTC (permalink / raw) To: Xin Long; +Cc: linux-sctp @ vger . kernel . org, Marcelo Ricardo Leitner > On 19. May 2021, at 20:44, Xin Long <lucien.xin@gmail.com> wrote: > > On Wed, May 19, 2021 at 2:15 PM Michael Tuexen <tuexen@freebsd.org> wrote: >> >>> On 19. May 2021, at 18:18, Xin Long <lucien.xin@gmail.com> wrote: >>> >>> On Tue, May 18, 2021 at 2:33 PM Xin Long <lucien.xin@gmail.com> wrote: >>>> >>>> On Tue, May 18, 2021 at 1:38 PM Michael Tuexen <tuexen@freebsd.org> wrote: >>>>> >>>>>> On 18. May 2021, at 18:43, Xin Long <lucien.xin@gmail.com> 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. > yes, that's also what I'm thinking. > sysctl is always used for the default value for future sockets. > and the socket option should be added for a socket/asoc's setting. > > SCTP_PTMUD_METHOD? OK. > 0: PTB one I don't know what the above would mean. Not sure anything is really specified. > 1. PLPMTUD I guess you would need an struct sctp_assoc_value here. Maybe some constants such as: SCTP_PMTU_CLASSIC SCTP_PMTU_NEW or SCTP_PMTU_RFC_8899 Best regards Michael > >> >> 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. >>>>> >> ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-05-20 19:27 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-18 16:43 add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags Xin Long 2021-05-18 17:38 ` Michael Tuexen 2021-05-18 18:33 ` Xin Long 2021-05-18 19:19 ` Michael Tuexen 2021-05-19 22:24 ` mleitner 2021-05-20 2:05 ` Xin Long 2021-05-20 7:06 ` tuexen 2021-05-20 15:13 ` Xin Long 2021-05-19 16:18 ` Xin Long 2021-05-19 18:15 ` Michael Tuexen 2021-05-19 18:44 ` Xin Long 2021-05-19 22:44 ` mleitner 2021-05-19 23:16 ` Michael Tuexen 2021-05-20 0:45 ` Marcelo Ricardo Leitner 2021-05-20 6:59 ` tuexen 2021-05-20 19:27 ` Marcelo Ricardo Leitner 2021-05-19 23:10 ` Michael Tuexen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).