SRT - Re: UDP based data xfer protocols

[Zenaan Harkness]

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.