linux-sctp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: mleitner@redhat.com
To: Michael Tuexen <tuexen@freebsd.org>
Cc: Xin Long <lucien.xin@gmail.com>,
	"linux-sctp @ vger . kernel . org" <linux-sctp@vger.kernel.org>
Subject: Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags
Date: Wed, 19 May 2021 22:24:53 +0000	[thread overview]
Message-ID: <CALnP8ZZd5B-S_jDtCeqbVqZNg5snnEs1v+uiGFc06FkMSk=BdA@mail.gmail.com> (raw)
In-Reply-To: <DE8A113C-DF80-412E-A5C1-C0731E1757E2@freebsd.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.
> >>
>


  reply	other threads:[~2021-05-19 22:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18 16:43 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALnP8ZZd5B-S_jDtCeqbVqZNg5snnEs1v+uiGFc06FkMSk=BdA@mail.gmail.com' \
    --to=mleitner@redhat.com \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=tuexen@freebsd.org \
    --subject='Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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