- From: benny daon via GitHub <sysbot+gh@w3.org>
- Date: Sat, 13 Mar 2021 22:16:21 +0000
- To: public-webrtc-logs@w3.org
Hi @tuexen! The more I think about this issues, the more I realize settings RTOMax is a hack. I came up with it after reading pion/webrtc code and realizing it will be easy to add it to the settings of pion/webrtc. But here we're talking about the standard and its client implementation so a hack is not a good idea. Exposing RTO.Min, RTO.Max & RTO.Initial is a much better idea as it gives the the user more control. It will help me but it doesn't deal with the root cause of the problem and won't help many other users who share my pain. I'm sure there are other users using other WebRTC apps who feel my pain. If you're one of the unlucky ones, using a thin congested pipe, SCTP serves you poorly as retransmissions are very slow. The Retransmission computation and management SCTP uses were designed it the age when there was no real time communication - all traffic was file transfer. The WAN was a mesh of analog modems who's rate measured in bauds. The design goal of the RTO was to minimize the risk of modem overflow as they crashed often so exponential back off was a great idea. IMO, we should refactor SCTP retransmission to focus on fast recovery and stop worrying about the modem's buffer. Guess I'll now head over to the Transport Area Working Group and see where the task force stand. -- GitHub Notification of comment by daonb Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/71#issuecomment-798794013 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 13 March 2021 22:16:23 UTC