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