allow users to change the congestion control algorithm

[Lanius-collaris]

Description

Reference issue

Fixes #...
related to #439

[JoTurk]

Thank you, we'll first need to merge #450 and do any necessary refactors in assocs so we don't have to break the API later.

[Lanius-collaris]

@JoTurk
0c8bc26
Retransmitting before sending new data can reduce SACKs, should I open one more pull request?

[JoTurk]

@Lanius-collaris yes, that's true, retransmit should be ordered before new data (we do this just not fast-retransmit). I think it's also required by the spec, This should be fixed in a new PR, also we should reference the spec. and add a test.

[Lanius-collaris]

@philipch07
If you have time, please try this and give some suggestions.
These experiments should be useful:
https://github.com/108anup/frcc/tree/main/experiments

[JoTurk]

@Lanius-collaris Thank you for working on this, I think configuration CC and more customization is something we should add eventually, after interleaving and after RFC 9260 migration, But i don't think this is mergable in the current shape.

From a library prespactive this does many things:

1. expose CC abstraction.
2. Add FRCC.
3. change ACK/pacing behavior.
4. ALl the other sender-side behavior changes.

And all of these should be split to their own API, and should be standalone and scoped, And after discussion.

Also I'm worried about turning the library into callbacks/hooks javascriptish nightmare, long term i would rather us moving towards more explicit sans/io style instead of ad hoc hooks.

[JoTurk]

@Lanius-collaris I believe the way we should do this is to export more of SCTP internal protocol like dtls and let the advanced users implement SCTP as they wish, adding this interface is dangerous and hard because we can't really enforce the spec with custom CCs algorithms and the interface transition between async and sync and it's really hard to maintain and fix, I'm sorry but I think we'll have to close or reconsider this.