Step 2:
Node A and middle node B, nego "headroom" links AB, and BN:
- A requests of B to "reserve excess headroom for real time b/w W, of intended duration ~T, beginning "asap".
- B checks its current link undertakings (bulk, r/t, total b/w vs b/w availability etc), and offers to A something like:
- I can ACK your request not before 13 minutes, (presumably due to current link contracts);
I will hold open this offer for you, for 10 seconds, i.e. I will not enter new link contracts before $NOW + 10s.
A consequential issue arising in relation to "network layer contracts", is one or another resource starvation attack: - if our protocols are sufficiently weak (attackable), then - stalker nodes S1, S2 ... Sn can "gang up" against node B - e.g., nodes Ss may repeatedly (say in random round robin fashion) make a certain resource request of node B, in order to starve either or both of node B, and node B's friend nodes, from that resource If node B naievely/ eagerly ACKs such contract requests, without suitable mitigation protocols then both B and B's friend nodes, will be starved of that resource. "Unconstrained eager contract agreement, is a resource starvation attack exposure point." Example resource starvation mitigation protocols: - headroom reservation, with the headroom available to preferred nodes only; watch out for information leakage here - local node and friend node preferencing; - time limiting contract ACKS, so that maximum latency "until next availability window" is reduced; but as usual, be very cautious about information leakage here Depending on protocols, we may steer strongly or weakly to different virtual network topologies, and the difference between these topos must be considered at some point: - strongly preferenced/ maintained F2F links, vs - weak F2F preferencing - information leakage every time a resource is "repurposed", unless there are protocol mitigations (primarily randomization of one form or another) - so randomized shifting between friend and anon nodes may bode well for global network flexibility, whilst maintaining reasonable preferred node resource availability, whilst hiding actual usage of said resources by said preferred nodes - ultimately we are balancing between various, sometimes competing, sometimes complementary, goals: - privacy - anonymity - latency - resource usage (are we on average actually making use of offered resources) - efficiency (what are the overheads to deliver the resource) - connectivity (to whom (which nodes) is a resource available) - availability (when is a resource available) By handling billions of nodes at core and not as an afterthought, we may be able to achieve desirable combinations of the above characteristics in relation to various resources. Again, network resources include: - b/w (bandwidth) - b/w over duration - latency - latency over duration - data storage - data storage over duration - link count - link count over duration Are we yet missing a basic "network level" resource? PS: when we use the term "latency" as a noun referring to a resource, we mean "desirable latency" which is usually low latency.