On Wed, Oct 23, 2019 at 05:15:57AM -0400, grarpamp 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.
Assuming "fixed rate" means "always filled to said rate" not "fillable up to said rate"... then that makes every users node look nicely busy.
Ack. "Chaff fill" has become overloaded. Let's try Link Metrics Normalization or LMN (or something better if someone speaks up soon): 1. packets per time unit normalization 2. packets transmission latency/jitter normalization 3. packet size normalization (this one's easy)
And if the rate is the same for all users, then every user looks the same.
Ideal operating mode. Practical (as in acceptable to users) operation probably requires as coderman suggested earlier, to allow steady stepping upwards/ downwards over time (by config only of course), to provide for the impatient bittorrent and youtuber crowd. There is no bw cap that will be accepted by all, probably not even by a majority.
However all nodes in the net need to be always filled to some rates.
Ack. I imagine a network ping (to friend/ connected nodes) on say a 10 minute interval, which from memory was only about 2.1MiB per month, would be an acceptable base load for everyone, and that many will accept higher base load than this.
Otherwise adversary vampire can just watch the nodes end user is connected to, or perturb the users packet stream, or wait until user unluckily routes across quiet middle nodes, etc.
Ack. Gov stalkers gonna stalk. One limit case to consider is all direct (first hop) p2p/f2f links are always and only ever, 1KiB/s (say). You want more bw, you add more separate links, and the disappearing act is handled by stepping up, and maintaining that rate for some period of time (presumably longer than actually needed), before eventually stepping down (removing links). And the point, in relation to "unluckily route across quiet (stalking) middle node" - some application of multi-path: - 10 trusted friends to whom I hop in to the net - 1 dark net server supporting multi path, from which I download the latest Adobe Photoshop cr24c/7 - 10 separate routes to 10 separate "darknet server access point nodes" - if 1 link gets killed in the middle, my corresponding friend node keeps chaff filling to my node regardless, and I can attempt to create with him, a new route; - also, the other 9 links continue to hum along
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")
If pad fill can be used to carry something, better than to waste it.