node behaviour - kick vs "relegated to fill traffic" - Re: Nextgen G* Traffic Analysis Resistant Overlay Networks (re Tor

Zenaan Harkness zen at freedbms.net
Sun Oct 27 06:19:23 PDT 2019


Although we talk about "kick"ing a node for "bad behaviour", in my
mind being kicked actually means being "relegated to fill traffic";
in both directions.

The network behaviour achieved in such a mode could be no worse than
Tor as it is today; "fill class", "best effort class" or "idle class".

One of the keys though, is ensure the end user is aware of what has
happened, and so if relegated to "fill traffic status" has happened,
the end user should be informed of this, so there's no
misunderstanding, or rather, traffic for use cases which -require-
some class other than "fill traffic class", and need to not continue
xmit in such circumstances, is specified and handled correctly (may
be "drop immediately and notify source".

When B sends packets to A, one of the fields in the "please route
this packet for me" could be a class field:

  - if the link within which that packet exists has been relegated
    to "fill traffic" class, "important" packets might get dropped,
    rather than cached and forwarded - such protocols are important
    to specify clearly, so that fail mode behaviour is known ahead of
    time, and / or specifyable ahead of time

  - it may be that most clear net "regular" web surfing via overlay,
    may be classifiable as "fill class" - for marketing purpose we
    rename this to something like "high speed bursty maxi surfing,
    delivering the best effort class to your browser daily" - no
    point scaring the fauna away; regular web surfing may be the
    ideal fill traffic

  - a lower class that "regular web surfing" might be "bulk best
    effort" (e.g. for torrents, see utcp posted previously)
    - by commandeering ALL IP traffic outgoing from a node, we might
      be able to perform better for many app traffic classes than
      utcp/ bittorrent etc today, which seem to rely on back pressure
      heuristics to detect buffer bloat, and back off correspondingly
      etc - with eth device "effective total ownership" and traffic
      class concepts such as TCP_OVERLAY, we just might kick some
      arse - happy users, happy ISPs
    - next in line, bringing QoS to the OS desktop

  - various QoS is your realtime class(es)

There is evident overlap between networking and process scheduling
concepts.



More information about the cypherpunks mailing list