openssh unix dev - Jul 2021 - [SUSPECTED SPAM] SCTP support

I was encountering some TCP head-of-line blocking issues while using 
rsync over SSH to transfer some large files, and thought, hmm, SCTP is 
supposed to be able to solve this issue even if you don't use multiple 
channels or roaming.

On my gentoo servers, there is a useflag for SCTP and it just builds 
openssh with this patch: 
https://dev.gentoo.org/~chutzpah/dist/openssh/openssh-8.6p1-sctp-1.2.patch.xz 
- it seems to work just fine when I use it.? What are the odds we could 
integrate this or something like this?

I think the last time it came up on this list was here: 
https://marc.info/?l=openssh-unix-dev&m=146071329711439&w=2

--Falcon Momot
--AS398960

Falcon Darkstar Momot wrote:
>
https://dev.gentoo.org/~chutzpah/dist/openssh/openssh-8.6p1-sctp-1.2.patch.xz
> - it seems to work just fine when I use it.? What are the odds we could 
> integrate this or something like this?
I'm no authority but if someone wants to make a push for SCP in
upstream I think it would be wise to strip the patch down a bit,
initially only add SCTP, so remove the multiple listen bits.

Since the patch introduces a new transport concept tied to the socket
protocol maybe it also makes sense to store the protocol (IPPROTO_*)
in the options.

Then the -z option handling is inconsistent in the patch and also its
existence is conditional on build-time detection, which isn't great.
I think Mike's idea in one bug is the right way to go; programs always
understand the option but error out if the protocol isn't supported.

Also, the patch doesn't add -z to all programs; in particular not to sftp.

Finally, I suppose that the configure detection and

+#ifdef SCTP
+#include <netinet/sctp.h>
+#endif

are way too simplistic for the many platforms supported by OpenSSH-portable.


So someone would need to put a bit of work in...


//Peter