pipe-net

[Zenaan Harkness]

> On Mon, Oct 28, 2019 at 05:19:08PM -0300, Punk - Stasi 2.0 wrote:
> > 	http://www.weidai.com/pipenet.txt

(I won't focus on errors in this paper, e.g.:
  - the description of the return path packet encryption (dest to
    origin) appears in error - but that's not interesting afaics.
  - "Anonymity in this scheme is asymmetric - the caller is
    anonymous, but not the receiver" seems an incorrect assertion,
    since N0 is known to N1 at least, albeit N0's content may well
    not be known to N1, and N0's destination point may not be known
    to N1.
)

This design doc is most useful conceptually for pondering possible
elements of our network design, since it's an origin document,
usefully laying out some concepts at issue:

It introduces the onion concept (if not by name), where node N0
requests N1 to link to N2 on behalf of N0, and key establishment
between N0 and N2 is (presumably) hidden from N1:

  "4. Establish a key (K2) with N2 through N1."

It introduces link negotiation:

  "3. Request that N1 establish a link id (S2) with N2."

It also introduces the packet switching concept, where in at least
one version of such switching, N1 (or N2 etc) could randomize routing
on behalf of N0:

  "The second node shuffles the packets it receives during a time
   unit and forwards them in random order to others."

Exactly how this is achieved is not yet clear.  Possibles:

 A. N0 establishes with N1 (by usual request/ contract proto)
    multiple links from N1 to nodes N2, N3, N4 etc., and N0 also or
    thereafter requests of N1, randomized outgoing packet shuffling
    for N0's packets (sent from N0 to N1).

    - this leaves ultimate logical routing control in the hands of N0
    - latency escalation (over a multi hop route) should be estimable
      by N0
    - ultimate (effective) network topology may be simpler to reason
      about, control and analyze


 B. N0 links to N1, and simply hands off all routing decisions for
    all packets to N1.

    - This might be viable if N1 is a known friend node.

    - In this routing protocol, N0 still needs to nego QoS requests
      with N1, to establish what total volume (in and/ or out) and
      what b/w rates, N1 is willing to make available to N0, and for
      what durations.

    - We must always keep in mind that meat space 'known friends',
      may well be using hardware/ software which is compromised
      (unknown to the friend).


  - These protocols don't have to operate mutually exclusively to one
    another - they can be used in parallel, along with other routing
    protocols, such as strict N0 controlled end to end routes.


  - We must not mistake the feeling of control ("ACKed requests"),
    with actual control.

    When we say N0 ultimately makes and therefore "controls" all
    routing decisions/ routing types used, what we really mean is, N0
    "specifies" all routing types it is willing to use, within each
    of its respective "link establishment requests".


  - We of course must also always keep in mind that we are talking
    virtual links, not physical links, and also quite possibly
    adversarial peer nodes.

    In the virtual (let alone phys) networking space, a node N1 (at
    least for suitable QoS link requests if non adversarial) may of
    its own accord make "randomized" routing decisions or aka
    "routing decisions, for N0's packets, outside of any specific
    requests by N0", and such "N1 primary authority" decisions may be
    adversarial to N0, supportive of N0, or have some other basis.

    Of course, iqnets core does the right/ assumed best thing by
    default - we simply consider all possibilities which may be
    ultimately faced in any actual network.


Re randomized fan outs, here is a bit of a conundrum/ potential
opportunity - in the balance between various options available to us:

  - Does it make sense for N0 to leave certain routing decisions to
    another node in its route?

  - Is the "fan out + randomize" concept identifiably useful for
    certain use cases?

  - For say N2 to do a randomized fan out in on incoming packets from
    N0 (say via N1), N2 will have to buffer the incoming packets over
    time period units of T, so that it has > 1 packet to on- send in
    a randomized fashion;
    this naturally introduces latency - which of course is
    acceptable, even desirable, depending on use case - we're now
    conceptually heading into random latency/ high latency mix net
    design territory.


Latency

  - an important consideration which the above paper effectively
    raises is:

    - the latency effect on route establishment, and

    - the latency effect on packet traversal through established
      routes, 

    for different switching/ routing models.

    This consideration needs more thought, especially in relation to
    various networking (i.e. end user app) use cases.


--------------------------

Alert: incoming thought, must get it down before it flees my lonely
neurone.

Headroom, or rather resource, reservation requests:

  - N0 could make "headroom" reservation requests of another node.

  - Is this the same as simply a chaff filled link? No.

    A resource reservation request is an "in advance of being used"
    request for a node to reserve or keep aside some resource, on my
    behalf until I need to use that resource, according to params
    e.g. "reserve for T time period", resource magnitude X, etc

    E.g.:

    - bandwidth reservation (I want to d/l a 4GiB movie, I just don't
      have time right now, please reserve that for me, which I would
      like to use in the next 5 days)

    - low latency link reservation (I want you to always reserve at
      least 1 telephone call worth of low latency link, on my behalf,
      for when I want to make phone calls (and of course hand out the
      rest as you choose)

    - cache reservation, although without further thought, I prefer
      the undertaking/promise model

  - such reservation requests perhaps make most sense between meat
    space friends, but there's of course no reason to limit such
    reservation requests to any particular node type