From: Michael Tuexen <tuexen@freebsd.org>
To: Xin Long <lucien.xin@gmail.com>
Cc: "linux-sctp @ vger . kernel . org" <linux-sctp@vger.kernel.org>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Subject: Re: add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags
Date: Tue, 18 May 2021 19:38:27 +0200 [thread overview]
Message-ID: <81B0ED00-D281-445B-83C7-7BE65DC0FD8E@freebsd.org> (raw)
In-Reply-To: <CADvbK_dqs84c7Yr_eUuENe9Y9HQXwG3AXh-0EcKFD3mjPwfpQQ@mail.gmail.com>
> 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.
next prev parent reply other threads:[~2021-05-18 17:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 16:43 add SPP_PLPMTUD_ENABLE/DISABLE flag for spp_flags Xin Long
2021-05-18 17:38 ` Michael Tuexen [this message]
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
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=81B0ED00-D281-445B-83C7-7BE65DC0FD8E@freebsd.org \
--to=tuexen@freebsd.org \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=marcelo.leitner@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).