----- Forwarded message from ... ----- To: Zenaan Harkness <zen@freedbms.net> Date: Tue, 29 Oct 2019 13:10:13 +1100 Subject: Re: [zen@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@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@freedbms.net> -----

From: Zenaan Harkness <zen@freedbms.net> To: CypherPunks <cypherpunks@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 -----