IQNets: p2p link negotiation - bandwidth management
Zenaan Harkness
zen at freedbms.net
Mon Oct 28 05:13:47 PDT 2019
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
More information about the cypherpunks
mailing list