IQNets - low b/w end user nodes - maximise 'user experience'
End user nodes which have low or relatively low total bandwidth BW, Node End-user Low Bandwidth => NELB might usefully provide only small or "marginal" b/w links, and link contracts with reduced time T. Where the end user 'experience' arising from his available b/w is already reduced/low/frustrating, any overlay which treats that end user as anything but an "mostly end user only" node, will likely be switched off/ disabled/ uninstalled, by said end user. So for a "compelling user experience", at least with NELBs, by default we ought limit both time duration T and bandwidth BW, for all link contracts handed out to incoming requests. Low T means "problematic" (from end user experience point of view) link contracts will time out "relatively soon". Low BW, as a percentage of total NELB BW, should minimize "obtrusive slowdowns due to the overlay net", again, from the end user perspective. Some aggregate numbers of global Internet users, e.g. "how many Internet users, globally, onramp at X kbps b/w?" Presumably there are still millions who have sub 256kbps? In any case, with the limit case, at least for certain groups of users, being groups of such low b/w links, a useful overlay net must usefully use "many micro connections". We can at some point test and establish useful minimum T and minimum BW for T. To optimize for such lithe links (rather, link contracts), we need to minimize "overlay network switch contract nego" latency. So various previously listed concepts are essential at the core of the overlay net - seamless utilization of many "micro" links, link aggregation, seamless handling of links that drop out, possibly fan-out (single high BW to many low BW) and fan-in hops, etc.
On Fri, Dec 13, 2019 at 12:55:13PM +1100, Zenaan Harkness wrote:
Node End-user Low Bandwidth => NELB
So for a "compelling user experience", at least with NELBs, by default we ought limit both time duration T and bandwidth BW, for all link contracts handed out to incoming requests.
Low T means "problematic" (from end user experience point of view) link contracts will time out "relatively soon".
Low BW, as a percentage of total NELB BW, should minimize "obtrusive slowdowns due to the overlay net", again, from the end user perspective.
The limit case is an early 1990s modem link or slower, e.g. 14.4kbps or less than 2KiB/s. With a UDP packet between 0.5 and 1.5KiB, we might be talking about 1 packet per second. The types of comms activity suitable for such a network are limited, as some will recall - basic text based web pages, SMTP/POP, etc. In this limit case, an overlay network as today's users would think of that, is not practical (since neither is "normal Internet surfing by today's standards"), BUT, IQNets ought actually optimize such networks - with user (at the UI/GUI) insight into the types of traffic he wants to xfer, and design for certain high latency + low b/w text comms, an IQNet node may be quite a bit more practically useful than a plain W98 TCP stack. 1.5KiB/s ~= 126MiB per day, or about 3.5GiB/month. Could we implement a useful high latency, low b/w text messaging overlay network in 3.5GiB/month? Of course we could - which was likely the point of the early cypherpunks email mixnet experiments etc. The Packet Anon Oh packet, crypt packet, tell me, what be your meme? This secret you hide, a hint may I glean? "Some text for another, 'tis not you I tease," "So forward me quickly, through your friends if you please!" "In chaff I must hide, tasty wheat for the ride, "Wait no longer, I linger, such importance inside!" Oh packet! Crypt packet .. go on and be free, To quietly, stealthily, target your creed! "Why thank, dear kind Sir, you good will be true, "For free speech, anon speech, good causes anew!" "Now I shall depart, you may have the last laugh," "We be daŋkə schön, muffas! 'Member, give from yo heart..."
On Fri, Dec 13, 2019 at 03:35:53PM +1100, Zenaan Harkness wrote:
On Fri, Dec 13, 2019 at 12:55:13PM +1100, Zenaan Harkness wrote:
Node End-user Low Bandwidth => NELB
So for a "compelling user experience", at least with NELBs, by default we ought limit both time duration T and bandwidth BW, for all link contracts handed out to incoming requests.
Low T means "problematic" (from end user experience point of view) link contracts will time out "relatively soon".
Low BW, as a percentage of total NELB BW, should minimize "obtrusive slowdowns due to the overlay net", again, from the end user perspective.
The limit case is an early 1990s modem link or slower, e.g. 14.4kbps or less than 2KiB/s.
With a UDP packet between 0.5 and 1.5KiB, we might be talking about 1 packet per second.
The types of comms activity suitable for such a network are limited, as some will recall - basic text based web pages, SMTP/POP, etc.
In this limit case, an overlay network as today's users would think of that, is not practical (since neither is "normal Internet surfing by today's standards"),
BUT, IQNets ought actually optimize such networks - with user (at the UI/GUI) insight into the types of traffic he wants to xfer, and design for certain high latency + low b/w text comms, an IQNet node may be quite a bit more practically useful than a plain W98 TCP stack.
1.5KiB/s ~= 126MiB per day, or about 3.5GiB/month.
Could we implement a useful high latency, low b/w text messaging overlay network in 3.5GiB/month?
Of course we could - which was likely the point of the early cypherpunks email mixnet experiments etc.
The Packet Anon
Oh packet, crypt packet, tell me, what be your meme? This secret you hide, a hint may I glean?
"Some text for another, 'tis not you I tease," "So forward me quickly, through your friends if you please!"
"In chaff I must hide, tasty wheat for the ride, "Wait no longer, I linger, such importance inside!"
Oh packet! Crypt packet .. go on and be free, To quietly, stealthily, target your creed!
"Why thank, dear kind Sir, you good will be true, "For free speech, anon speech, good causes anew!"
"Now I shall depart, you may have the last laugh," "We be daŋkə schön, muffas! 'Member, give from yo heart..."
A note to those interested in "free speech" overlay nets, the IQNets project (to collate some ideas regarding a possible new overlay net - as an improvement to current Tor and I2P status quo) exists in ideas and a few notes only at the moment, all of which can be found here: https://github.com/zenaan/iqnets Last update was some months back, and then just now (generally copy off emails to a "must review" tmp folder, finally got to them today) - see iqnets/doc/*.txt : - tin foil chat info, - wireless congestion control links, - one way blog discussion - ("atomic ccdex" fmradio link I did not include, this proj is about overlay nets not DCs, and for now I have no idea what ccdex means, so perhaps if someone comments that it's somehow quite relevant to the implementation of an overlay net, it can get added in), - ZKP/ zero knowledge proofs - there may well be gold nuggets under this rainbow, - obstor, - "obscurity is a time buffer" (thank you Spirit of Nikopol :), - p2p reputation too, which is likely foundational for any robust overlay net - Note, still have some 'plain' iqnets emails etc to comb, on my todo list ... (I personally have two unrelated court cases which appear to shall continue engage the bulk of my attention this year). There are other projects around which may be more active.
- ("atomic ccdex" fmradio link I did not include, this proj is about overlay nets not DCs, and for now I have no idea what ccdex means, so perhaps if someone comments that it's somehow quite relevant to the implementation of an overlay net, it can get added in),
CCDEX must relate to DEX, distributed/decentralized exchange for digital currencies, so may be CCDEX is just "Crypto Currency Decentralized EXchange" - but then why use CCDEX when we already have the term "DEX" .. not sure. https://en.bitcoinwiki.org/wiki/DEXes Anyway, incentivization may well involve DCs - in present average human consciousness, money seems a motivation turbocharger. Any DC that is not inherently 'fair' in its basic operation will be eclipsed by a "more fair" DC. Some will wish to avoid the "pollution" of financial motivation in their street nets/N2N phys buildouts etc, and that too is just fine. In any case, DCs in the context of IQNets falls under incentivization of some sort.
On Fri, Dec 13, 2019 at 12:55:13PM +1100, Zenaan Harkness wrote:
End user nodes which have low or relatively low total bandwidth BW,
Node End-user Low Bandwidth => NELB
might usefully provide only small or "marginal" b/w links, and link contracts with reduced time T.
Where the end user 'experience' arising from his available b/w is already reduced/low/frustrating, any overlay which treats that end user as anything but an "mostly end user only" node, will likely be switched off/ disabled/ uninstalled, by said end user.
So for a "compelling user experience", at least with NELBs, by default we ought limit both time duration T and bandwidth BW, for all link contracts handed out to incoming requests.
Low T means "problematic" (from end user experience point of view) link contracts will time out "relatively soon".
Low BW, as a percentage of total NELB BW, should minimize "obtrusive slowdowns due to the overlay net", again, from the end user perspective.
Some aggregate numbers of global Internet users, e.g. "how many Internet users, globally, onramp at X kbps b/w?"
Presumably there are still millions who have sub 256kbps?
In any case, with the limit case, at least for certain groups of users, being groups of such low b/w links, a useful overlay net must usefully use "many micro connections".
We can at some point test and establish useful minimum T and minimum BW for T.
To optimize for such lithe links (rather, link contracts), we need to minimize "overlay network switch contract nego" latency.
So various previously listed concepts are essential at the core of the overlay net - seamless utilization of many "micro" links, link aggregation, seamless handling of links that drop out, possibly fan-out (single high BW to many low BW) and fan-in hops, etc.
NELB nodes (i.e. in the 14.4kbps class), give rise to consideration of their primary use case being low b/w messaging systems. If a node may transfer a maximum of only 1pps (packet per second), consider a messaging layer - 1 packet per minute - fixed size packets - 1.4KiB packets Some random nomenclature: - WD: node "sync window" duration, is 1 minute = 60s - WS: window wall clock start time, nego'd with peer - WE = WS + 60 - PTD: estimated/avg packet transmission duration - PTDe: packet transmission duration error - PTS: packet transmission start time - PTE: packet transmission end time - Wi(PTS) = 60 - PTD - PTDe.max : window for possible values of PTS Consider possible values for PTS, within each window WD: - PTS = PTS.min = 0 - PTS = PTS.max = Wi(PTS) - PTS = rand(0,PTS.max) - PTS = nego fixed PTS with peer(s) - PTS = some algorithm (e.g. pseudo random, or nego'ed etc) PTS might be nego'd on one side only, say between peers A and B, or also in consultation with a third peer C, or with more than just a third peer if we are creating a fan-out link/route. The considerations for different values of PTS must include the various network/ flow on effects - think dominoes of one node affecting the next node etc.
participants (1)
-
Zenaan Harkness