‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, October 17, 2019 10:31 PM, Punk <punks@tfwno.gf> wrote:
... ok, so that's actually one of, or the most fundamental requirement. The connection between user and 'network' HAS to have a fixed rate. Let's check the archive... ...
So that's it Jim. Users have to be connected 24/7 using a constant rate link. Today it can be more than 100 bytes/s
one idea is to use something akin to reliable multicast groups, where you gradually increase your bandwidth according to some defined strata of bandwidth, and affirmative control notification is required to increase your bandwidth (number of concurrent strata). this is not TCP friendly, but it would support multiple levels of bandwidth in such a system. this doesn't eliminate traffic analysis (like true link padding) but it does muddy the waters into partitions which are much larger than (1). another benefit would be to use that padding traffic with application layer awareness of bulk transport. e.g. ability to say "send this, but no rush..." vs. interactive traffic. last but not least, you could apply the padding traffic to key pre-distribution or opportunistic protocol maintenance. e.g. distributing routing and node identity information. (the "directory") best regards,