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.
