v2 Plans

[edaniels]

@enobufs, I figured we could start talking here publicly about what we should do in v2.

Right now we know that ultimately we want:

• RACK
• TLP
• Blocking writes

The first two make sense to me and can likely be done without an official v2. Blocking writes however is a breaking change and I was curious if you had some ideas in your head on what a newer architecture would look like? I know you mentioned that you don't love the current state machine.

I figure we can start here and try to outline the general idea of what we should do. I don't think the plan has to be hyper specific but it would be good to be on the same page and be able to define units of work that don't result in just some massive PR to get to v2 (unless that is truly the best way!).

Also, anyone else interested in this project, if you have thoughts and opinions on how we achieve the above, please chime in!

[edaniels]

Also, for what it's worth, I don't think we're in any rush here, so no pressure to respond ASAP to this.

[enobufs]

I'd recommend to focus on just blocking writes for v2.
I am aware there are other desired API change such as Listen, Dial (to align with the standard SCTP API) but I think these are "nice to have" features imo and we can do it later. Also, yes RACK/TLP does not require API change.

Many users have been suffering from the async write and the blocking write is the most wanted feature atm. The streamlined goal with v2 make it more achievable to put it into pion/webrtc v4. (getting rid of pendingQueue out of the way for the future enhancement is also nice)

[edaniels]

That's fine with me. Do you have any vision for what you'd re-architect to achieve blocking writes? I could "just" go down a proof of concept route to achieve and see what changes fall out. What do you think?

[enobufs]

I see (or hope) not much re-architing required here. sctp.Stream is already looks like net.Conn. We have two goroutines: writeLoop and readLoop, which wouldn't change. Read operation is already blocking, so it is Stream.WriteSCTP() (<-- I'd remove this method btw..) and underlying call into Association needs to be modified. I'd say we can just use Association's mutex to block the write operation (Association.sendPayloadData()). A challenge I can see from top of my head is because we have many streams competing over the shared Association, we'd need to figure out how to control the deadlines (e.g. SetDeadline, SetWriteDeadline). We'd need a small/short-lived timer routine for each blocking call...

This is my quick thought (I may be wrong). I think it is good idea for you to just go ahead try it out ;)

[edaniels]

I'll give it a go once some of my paid work lets up :D

[sirzooro]

Please also add fix for #239. It is useful for apps which sends lots of data via DataChannel, and handle network contentions by closing old data channel and opening new one. Now unsent/unacked chunks piles up in inflight queue, increasing memory and CPU usage what is not desirable.

[erik-moqvist]

@edaniels @enobufs Would be awesome if RACK is implemented soon. =)

I've done some SCTP testing over networks where packets are not received in the same order as they are transmitted, and the throughput is generally quite bad when that happens. As I understand it RACK, a time based algorithm, generally outperforms a counting nacks algorithm in networks with frequent packet reordering.