IQNets - low b/w end user nodes - maximise 'user experience'

[Zenaan Harkness]

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.