Hi Xin,
I implemented RFC8899 for an SCTP simulation model.
Comments follow inline.
> Begin forwarded message:
>
> From: Xin Long <lucien.xin@xxxxxxxxx>
> Subject: Re: The new sysctl and socket option added for PLPMTUD (RFC8899)
> Date: 12. June 2021 at 19:32:02 CEST
> To: Michael Tuexen <tuexen@xxxxxxxxxxx>
> Cc: "linux-sctp @ vger . kernel . org" <linux-sctp@xxxxxxxxxxxxxxx>, Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx>
>
> On Fri, Jun 11, 2021 at 4:42 PM <tuexen@xxxxxxxxxxx> wrote:
>>
>>> On 11. Jun 2021, at 22:20, Xin Long <lucien.xin@xxxxxxxxx> wrote:
>>>
>>> Hi, Michael,
>>>
>>> In the linux implementation of RFC8899, we decided to introduce one
>>> sysctl and one socket option for users to set up the PLPMUTD probe:
>>>
>>> 1. sysctl -w net.sctp.plpmtud_probe_interval=1
>>>
>>> plpmtud_probe_interval - INTEGER
>>> The interval (in milliseconds) between PLPMTUD probe chunks. These
>>> chunks are sent at the specified interval with a variable size to
>>> probe the mtu of a given path between 2 associations. PLPMTUD will
>> I guess you mean "between 2 end points" instead of "between 2 associations".
>>
>> I'm not sure what it means:
>>
>> I assume, you have candidate 1400, 1420, 1460, 1480, and 1500.
>>
>> Assume you sent a probe packet for 1400. Aren't you sending the
>> probe packet for 1420 as soon as you get an ACK for the probe packet
>> of size 1400? Or are you waiting for plpmtud_probe_interval ms?
> It will wait for "plpmtud_probe_interval" ms in searching state, but in
> searching complete it will be "plpmtud_probe_interval * 30" ms.
Does this mean you always wait for plpmtud_probe_interval ms? Even if you receive an ack for a probe packet or a PTB?
In my implementation, I start with the next probe immediately when receiving an ack or PTB.
>
> The step we are using is 32, when it fails, we turn the step to 4. For example:
> 1400, 1432, 1464, 1496, 1528 (failed), 1500(1496 + 4), 1504(failed,
> 1500 is the PMTU).
What does failed mean? Does it mean that you have sent MAX_PROBES (=3?) probe packets and waited for each plpmtud_probe_interval ms without receiving a response?
If so, it might make sense to continue with smaller candidates earlier. For example, after one unanswered probe packet.
>
> Sorry, "sysctl -w net.sctp.plpmtud_probe_interval=1" won't work.
> As plpmtud_probe_interval is the probe interval TIME for the timer.
> Apart from 0, the minimal value is 5000ms.
>
> So it should be:
>
> plpmtud_probe_interval - INTEGER
> The time interval (in milliseconds) for sending PLPMTUD probe chunks.
> These chunks are sent at the specified interval with a variable size
> to probe the mtu of a given path between 2 endpoints. PLPMTUD will
> be disabled when 0 is set.
>
> Default: 0
What do you mean with probe chunks? You are sending probe *packets* containing a HEARTBEAT and a PAD chunk, right?
RFC8899 contains:
The PROBE_TIMER is configured to expire after a period longer than the maximum time to receive an acknowledgment to a probe packet.
So, how about plpmtud_probe_max_ack_time?
Also, I think more parameters would be helpful. For example,
plpmtud_enable - boolean to control whether to use PLPMTUD (it is more explicit than plpmtud_probe_interval=0 or plpmtud_probe_max_ack_time=0)
plpmtud_max_probes - controls the number of probe packets sent for one candidate.
plpmtud_raise_time - time to wait before probing for a larger PMTU in search complete (0 to disable it).
plpmtud_use_ptb - boolean to control whether to process an ICMP PTB.
Timo
>
> Thanks.
>>> be disabled when 0 is set.
>>>
>>> Default: 0
>>>
>>> 2. a socket option that can be used per socket, assoc or transport
>>>
>>> /* PLPMTUD Probe Interval socket option */
>>> struct sctp_probeinterval {
>>> sctp_assoc_t spi_assoc_id;
>>> struct sockaddr_storage spi_address;
>>> __u32 spi_interval;
>>> };
>>>
>>> #define SCTP_PLPMTUD_PROBE_INTERVAL 133
>>>
>>>
>>> The value above will enable/disable the PLPMUTD probe by setting up the probe
>>> interval for the timer. When it's 0, the timer will also stop and
>>> PLPMUTD is disabled.
>>> By this way, we don't need to introduce more options.
>> OK.
>>>
>>> We're expecting to keep consistent with BSD on this, pls check and
>>> share your thoughts.
>> Looks good to me.
>>
>> Best regards
>> Michael
>>>
>>> Thanks.
>>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
