proposal: x/net/sctp: new package

[higebu]

Background

This proposal will make easy to develop SCTP based applications such as HSS or MME in cellular networks.

I'd like to add this proposal to core library, because the one-to-one style SCTP interface on Linux is very similar to TCP interface. If we make an another package or add this to golang.org/x/net, it will make
large copy of code from net and internal/poll package.

Proposal

Add one-to-one style SCTP support to net package.

• Support sctp/sctp4/sctp6 in net.Listen and net.Dial.
• Add 3 functions and 3 structs to net packages.
  • structs
    • SCTPAddr
    • SCTPConn
    • SCTPListener
  • functions
    • func DialSCTP(string, *SCTPAddr, *SCTPAddr) (*SCTPConn, error)
    • func ListenSCTP(string, *SCTPAddr) (*SCTPListener, error)
    • func ResolveSCTPAddr(string, string) (*SCTPAddr, error)

This proposal supports only one-to-one style interface with SOCK_STREAM.

[gopherbot]

Change https://golang.org/cl/69410 mentions this issue: net: initial SCTP support

[LionNatsu]

BTW, one-to-one style SCTP is good as an alternative of TCP, but should we implement multi-stream and multi-homing as well? They are very useful for some scenario in LAN.

[bradfitz]

Even with any necessary code duplication, I think this should be in x/net/* and not in the standard library. SCTP is too fringe for the standard library.

See also: https://golang.org/doc/faq#x_in_std

[higebu]

@LionNatsu See #9334. I think we need to resolve this issue for that.

[higebu]

@bradfitz OK. I'll try to implement it into x/net.

[rsc]

Given that the Linux kernel is actually doing the SCTP implementation and this is just a new socket enumeration, it seems like a solution to #15021 should happen first, and then this can be completely
out-of-standard-library changes. A tiny amount of new code in x/net would not be a big deal. The pending CL has lots of code in the standard library as well, which we'd like to avoid.

[rsc]

Putting on hold until #15021 is done.

[mikioh]

I believe that #15021 is not necessary for this issue. Go 1.12 and above fix #24331 and anyone who wants to implement minor protocols (like SCTP) can achieve their goal without vendoring/tweaking/reimplementing the runtime-integrated network poller.

[mikioh]

This proposal supports only one-to-one style interface with SOCK_STREAM.

Well, I still don't see any good reason why this "one-to-one mapping-only SCTP" implementation should stay in the x/net repository. Just skimmed godoc.org and found https://godoc.org/github.com/ishidawataru/sctp; I guess that's enough for people who need to work on mobile radio-area/core networks.

If we really need an SCTP package, it might be better to have a package that follows RFC 4960bis (currently working group draft at IETF tsv-wg), supports both latest FreeBSD and Linux SCTP implementations (the past few years Linux implementation rushing to catch up the latest features) and has well-considered API surfaces; for example, TLS-over-SCTP w/ non-full handshake? no thanks, focusing on flexible associations? yup, but CMT and various flow/congestion-control algorithms should be pluggable.

[mikioh]

I believe that #15021 is not necessary for this issue

and there's another roadblock: #17244

[vivekmanni]

Syscall "Deprecated: this package is locked down. Callers should use the corresponding package in the "" repository instead. "
I was trying to use "golang.org/x/sys/unix" to setsockopt for my SCTP socket to set the number of streams. But unfortunately i dont see any option to use setsockopt for structure
type SCTPInitMsg struct {
NumOStreams uint16;
MaxInStreams uint16;
MaxAttempts uint16;
MaxInitTimeOut uint16;
};
Can any one suggest.

[linouxis9]

Any reasons why this proposal is still on hold?

[ianlancetaylor]

I will take this off hold but I'm not sure what the proposal actually is today. Would somebody like to investigate what would be needed to implement this?