On Mon, Oct 28, 2019 at 10:51:14PM +1100, Zenaan Harkness wrote:
A link between two peers B and C, may not naturally sustain the hoped for bandwidth.
Active link management, and whole-of-interfaces management, may be required to achieve required b/w and latency stability, e.g.:
- In the face of a node in a household with a single ADSL router shared by multiple co-tennants.
- In the face of links up/down shaped outside of our control (e.g. by an ISP/ any middle device in the p2p link's physical path)
It may be that we shall manifest Internet wide, RFC based, active QoS and traffic management - but that's in the longer term; in the short term, we must optimize for an end user node's present reality.
A user space TCP/IP stack provides for experimentation.
Today, congestion control, dynamic queues, and mechanisms to handle buffer bloat etc, impact b/w of links over time. How are low b/w links between peers affected over time? A node at some point shall determine its "generally available" bandwidth, which as previously noted, may catastrophically fall off a cliff when monthly quota is used up and ISP shaping kicks in, and similarly the inverse when the monthly rollover/anniversary day is passed. A node can hand out portions of its "generally available" bandwidth as contracted links of various classes. Some portion of generally available bandwidth could be considered, assumed, and/or determined empirically over time, by a node as "minimum generally available b/w". To deliver the link qualities we are trying to achieve here, we wish to figure out how to optimize for QoS classes: - we want to know traffic which is "bulk fill" class (bittorrent) - we want to know switch/net control traffic - this one's easy - such packets, or rather data embedded in std sized packets which may also carry data, always get priority local queueing on the local interface (they always get written out first) - but what about incoming net/switch control packets? - if we rely on existing TCP/IP stacks, we presumably must maintain at least 2 (UDP) incoming ports, if we want 2 classes of traffic - and net/switch control packets are the highest priority class, above all else, so if all else is "bulk fill" class, then that's the only two classes a node presently is handling - and always read from the high priority port first