IQNets - low b/w end user nodes - maximise 'user experience'
Zenaan Harkness
zen at freedbms.net
Wed Dec 18 20:16:42 PST 2019
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.
More information about the cypherpunks
mailing list