SRT - Re: UDP based data xfer protocols

Tue Oct 29 00:17:27 PDT 2019

----- Forwarded message from ... -----

To: Zenaan Harkness <zen at freedbms.net>
Date: Tue, 29 Oct 2019 13:10:13 +1100
Subject: Re: [zen at freedbms.net: SRT - Re: UDP based data xfer protocols]

Hi Zen,

don't really understand your court action - but hey - good luck.

I just broadly read your docs about a tor replacement.

IMHO - the biggest issues for performance, latency, reliability etc :
- doesn't concern the ISP, it's usually your own outbound limit -
especially for QoS.
- secondly, your own inbound limit.
- then after your own limits, it's fair access to the whole network.
- not sure if you totally understand TCP - which most internet stuff uses -
especially TCP windows. It has a start small, go faster, until it fails
then back off a bit. eventually it tries to have a reasonable window size
based on the latency and bandwidth of equipment involved. the 'window' is
the tcp packet size, how many to have in flight, etc. If you have a big
bandwidth (say 100Mbps at both ends), and the latency is low, say sydney to
Melbourne, it's fairly easy for it to work out packet sizes to get to
100Mbps. But if it's further away, say Sydney to LA. It takes longer to
converge to 100Mbps, if at all. Any if there is some equipment in the
middle, or either end, that is lacking 100Mbps, it has to work that out.
- with a private / secure / tor arrangement, in the middle you may need
some 'fairness' - otherwise connections with 1Gbps or more will just swamp
the whole system.
- i think what I'm trying to say, there are bigger problem than ISPs
honouring QoS.

I'm currently using something called zero-teir. It's only routing for me,
and only private for me. But it works well, and has a nice routing network.
easy to run, and configure. you can have several 'networks'.  It is
peer-to-peer discovery , and/or routing through existing nodes.  It could
easily be used for a 'trading partners' scenario - where you add 'nodes'
that you trust. It might even be a reasonable backbone, to piggy back your
own private communications on. You can run on your own or public routers
(they call them moons). I run my own 'moon router' for increased
availability near my nodes.

zero-teir seems to have low latency, great reliability, great discovery,
great uptime, ease of use, good o/s support.

you can do cool things on zero-teir. Like have 1 exposed/internet node in a
location. and nodes in that location don't even need internet access, will
discover that node, and route through it.

openvpn is older, secure, and widely used. But it's sort of a pig to
configure and scale. AFAIK it's only 'hub and spoke' which is a total F'up
in my opinion.

Scott

On Tue, Oct 29, 2019 at 11:42 AM Zenaan Harkness <zen at freedbms.net> wrote:

> on the cypherpunks mailing list a few of us have begun to map
> out various design contraints for a replacement to the Tor network -
> that is, something which will (it is intended) meaningfully improve
> on various of the known flaws in Tor.
>
> Private communications is of course fundamental to our basic human
> rights to private and free speech, which we need if those not in
> power at any given time, are to have any hope of holding to account
> for their misdeeds, those in power.
>
> Presently, the "Example questions" I posed yesterday (underlined in
> the email below), are outside my personal realm of knowledge and
> experience, so I need to find someone I can communicate with who has
> such knowledge, so they and I can kick the can around on this topic.
>
> Kind regards,
> Zen

> ----- Forwarded message from Zenaan Harkness <zen at freedbms.net> -----
>
> From: Zenaan Harkness <zen at freedbms.net>
> To: CypherPunks <cypherpunks at lists.cpunks.org>
> Date: Mon, 28 Oct 2019 23:48:43 +1100
> Subject: SRT - Re: UDP based data xfer protocols
> List-Id: The Cypherpunks Mailing List <cypherpunks.lists.cpunks.org>
>
> 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.
>
>
> ----- End forwarded message -----
>

----- End forwarded message -----