-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Projects Worth Doing
This is a list of projects that pass these tests.
- Improvements for users is clear
- Can be completed by a single developer
- No bikeshedding. Pion maintainers agree issue is worth solving.
- Fun/rewarding for developer. It's a project someone can be proud of
Pion currently only supports DTLS 1.2 implementing 1.3 has a bunch of improvements that would help out Pion users.
- Faster connect times (One less round trip during handshake)
- Less overhead (Record layer is smaller)
- Privacy (SeqNums encrypted )
- Security (Only AEAD ciphers)
Pion sends UDP packets one at a time. Doing this send syscall is the most expensive operation happening for most Pion users. For some platforms it is possible to batch the sending of packets. We can send multiple UDP packets at one time!
This can be implemented in a few different ways, but this would be a good way to start.
- Write a simple server that sends 4K video or maybe lots of data via DataChannel?
- Modify pion/ice to batch and send packets every ~20ms?
- See if that improves performance!
It's possible that sending on a timer doesn't actually help. We might have to introduce
an API that allows pion/sctp pion/rtp etc... to send multiple patckets in one call.
It would be better if we could do this with no API breakage though! It's possible Go already has a idiomatic solution to this .
SCTP uses a single sequence number when sending data. This means SCTP suffers from Head-of-line blocking. If you are trying to do high performance datachannels you are going to block on old packets that you actually don't care about!
SCTP has solved this with rfc8260. Implementing this in Pion would give a performance benefit to all DataChannel users.
Currently pion/sctp uses packet loss as the only input to perform Congestion
Control. If we used packet arrival times we would get more robust/faster
DataChannels!
Rack for SCTP is the best thing to read on the topic. It ends with a very exciting summary.
The RACK algorithm shows a significant
improvement over the dupthresh algorithm, especially for non-
saturated connections and in the event of tail loss. The benefits
are not limited to loss. RACK is also much more resilient
against packet reordering in the network.
Sign up for the Pion Discord for discussions and support
If you need commercial support/don't want to use public methods you can contact us at [email protected]