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.