LWN: Comments on "Netconf discussions, part 1" https://lwn.net/Articles/674943/ This is a special feed containing comments posted to the individual LWN article titled "Netconf discussions, part 1". en-us Fri, 10 Oct 2025 08:33:51 +0000 Fri, 10 Oct 2025 08:33:51 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net SCTP https://lwn.net/Articles/679072/ https://lwn.net/Articles/679072/ sirwm <div class="FormattedComment"> The telcom vendors need SCTP. Many demand that SCTP from the LINUX distribution be used. These companies demand the features that SCTP provides. rarely used ? of limited use ? where are you people getting your information ? Ask RedHat about all the bugs written against SCTP. If there were no users, no one would bother creating tickets...<br> </div> Mon, 07 Mar 2016 13:28:46 +0000 Netconf discussions, SCTP https://lwn.net/Articles/675279/ https://lwn.net/Articles/675279/ jhhaller <div class="FormattedComment"> SCTP usage is part of the 3GPP LTE standards (supported on the S1-MME interface). One would hope that the 5G standards will remove that usage, as it's utility for link redundancy is not terribly high, but it probably will remain for reasons of 4G/5G interworking and upgradability. Some products use the Linux SCTP stack, some roll their own (for performance or other reasons).<br> </div> Fri, 12 Feb 2016 00:07:32 +0000 Netconf discussions, part 1 https://lwn.net/Articles/675274/ https://lwn.net/Articles/675274/ dlang <div class="FormattedComment"> The biggest problem with dealing with wireless queues is finding devices that will let us get at them!<br> <p> far too much queueing is done inside the firmware blob where it can't be changed, or even monitored.<br> <p> We saw how BQL deployment drasically improved network throughput and handling on wired interfaces, we need something similar for wireless, but wireless has the added complication that the time needed to transmit a set of bits varies drastically from station to station, and also over time when talking to the same station.<br> <p> We need to be able to work inside what are currently firmware blobs to be able to measure what's happening and experiment with fixes.<br> <p> As far as MU-MIMO goes (the ability to transmit to multiple stations at the same time), the performance of the existing closed-source firmware is a great example of why we need this access. In every device I've seen a review for, turning on this feature produces a fantastic improvement in the transmitted throughput, up until about 12 devices, at which point the firmware gives up and abandons the protocol entirely, dropping throughput back to a single device.<br> </div> Thu, 11 Feb 2016 23:52:55 +0000 SCTP https://lwn.net/Articles/675192/ https://lwn.net/Articles/675192/ tshow <div class="FormattedComment"> By which I mean, I've a server running Linux and clients that are game consoles and phones. The stumbling block is not the Linux support.<br> </div> Thu, 11 Feb 2016 14:25:06 +0000 SCTP https://lwn.net/Articles/675186/ https://lwn.net/Articles/675186/ tshow <div class="FormattedComment"> I'd absolutely love to be able to use SCTP, but it's not supported where I need it, on game consoles and phones.<br> <p> </div> Thu, 11 Feb 2016 14:09:40 +0000