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.