Secure Reliable Transport https://en.wikipedia.org/wiki/Secure_Reliable_Transport Secure Reliable Transport is an open source video transport protocol developed originally by Haivision. According to SRT Alliance, an organisation that promotes the technology, it optimises streaming performance across unpredictable networks, such as the Internet, by dynamically adapting to the real-time network conditions between transport endpoints. This helps minimise effects of jitter and bandwidth changes, while error-correction mechanisms help minimise packet loss. SRT supports end-to-end encryption with AES.[1] When performing retransmissions, SRT only attempts to retransmit packets for a limited amount of time based on the latency as configured by the application.[2] The reference implementation of the protocol was originally published under the Lesser General Public License version 2.1,[3] but was relicensed under the Mozilla Public License on 22 March 2018.[4] SRT is supported in the free software multimedia frameworks GStreamer, FFmpeg, and in VLC free software media player.[2][5] Notes: - low latency connections want no (or minimized) buffering - bulk fill traffic does not care about buffering, just wants everything to be (eventually) delivered - net/switch control packets want no buffering/ maximum priority So, buffering desirability is related to the traffic class - we could have a QoS field in each packet. An open question is MTU and packet size - do we have say 2 or three packet sizes corresponding to traffic classes, do we have a single packet size and if so, what size should that be - in the case we are sending net/switch control messages at high prio, average (encrypted) packet size containing such control msgs might be very small, say 20 bytes. Even if "net/switch" control msg packet size needs to be say 150 bytes to contain the largest such messages, do we want to burden such packets with "having to be a set size of ~MTU, say 1.5KiB? We need an ISP/backbone guru to talk to on some of these issues - to suggest what would work today, and what could work (if the IQNets userbase is sufficiently large, which it will be), from their perspective. I met some Telstra backbone guys some years back - the wholesale side of our old Australian Telecom network that was ripped from under the nation for a few silver coins, but no longer have their contact details. Example questions: Is ISP (and GT-1 etc) physical equipment, possibly able to honour QoS for rare but important net/switch control packets? Would such packets need to be a maximum size, say 150 bytes (or even less), rather than MTU bytes? Is such GT*, or perhaps rather, end user facing ISP equipment, able to handle users who might try to game such QoS offerings by say rate limiting such packets on a per end user node basis (to say, 2kbps or whatever...)? If we get a handle on these types of questions, IQNets might actually be very appealing to the GT* guys, to optimize everything with proactive, rather than reactive, traffic management. UTP goes a long way to handling bittorrent, but there seems to be a lot of opportunity for full stack (right up to apps) improvement here... ... and pushing this up the the stack makes sense if the lowest level guys can provide. If they can't provide today, then tomorrow's equipment will provide if the picture is compelling and widespread.