Turn Stream.WriteSCTP() and Write() a blocking call by default about sctp HOT 7 OPEN

@enobufs I'm wondering more and more if this should be the strong default. I'm still trying to understand if there's anything SCTP can do better to avoid the issues people see when too much data is sent over the network and we get stuck in RTX, but I wonder if this is the best avoidance solution in addition to whatever fixes may be inside the sctp impl.

from sctp.

Even after 5 years, I massively agree that the default should be to block when there is too much buffered data in-flight.

from sctp.

I still have the same feeling, even more strongly also!
When we do blocking write, I prefer ditching the 'buffered amount' flow control mechanism (it's for javascript and it's been the source of confusion for Go programmers!) from supporting both modes. (thoughts?)
Let us plan for pion/sctp v2.

from sctp.

Should we make it part of pion/webrtc@v4 ? We can start a v2 now!

from sctp.

Do we think a blocking write would be a write that has made it to inflight and that there's no longer a pending queue? That could simplify/remove some code.

and yeah let's do it as a v2! We ought to look at https://datatracker.ietf.org/doc/html/rfc9260 and understand what we are missing from the latest spec in addition to 4960. I believe there are some omissions that fit into v1/2 that could improve reliability and perf.

from sctp.

@enobufs has also had ideas for RACK.

This is a good chance to redo those parts that you have been debugging!

from sctp.

Do we think a blocking write would be a write that has made it to inflight and that there's no longer a pending queue? That could simplify/remove some code.

Exactly.

from sctp.