commit 13a98368bf21a3fd7eb0ab1a95ace7875ae45004
parent 550e14a511480db0eddb7aa924148c0625fc3c79
Author: Julius Bünger <buenger@mytum.de>
Date: Mon, 26 Feb 2024 13:12:46 +0100
cong: add missing cong.rst
Diffstat:
1 file changed, 193 insertions(+), 0 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -0,0 +1,193 @@
+.. _CONG-Subsystem-Dev:
+
+.. index::
+ double: CONG; subsystem
+
+CONG
+====
+
+CONG (COre Next Generation) is the name of the project redesigns the CORE
+service. Here we document the design decisions and parts that are about to
+change.
+
+..
+ TODO Overview? Oder gibt's ein Inhaltsverzeichnis?
+
+.. _Peer-IDs:
+
+Peer IDs
+--------
+
+Peer ids stop to be unique for the lifetime of a peer, but change each time a
+peer's addresses change. This includes gaining or losing an address.
+
+..
+ TODO ^^^ gaining/losing makes sense?
+
+It is important to note that this design choice only increases the cost of
+network location tracking and does not fully prevent it. For this feature onion
+routing on top of CADET is envisioned.
+
+At this point it seems like one has to weigh privacy versus performance when it
+comes to this design decision.
+
+.. _Reasoning:
+
+Reasoning
+^^^^^^^^^
+
+..
+ - why this decision (and not others?)
+ - (scenarios to understand whether it makes sense)
+
+This change was introduced in order to stop tracking of more mobile peers.
+For example a more mobile peer (laptop) that logs into the network at different
+places can be easily tracked by everyone just by recording the different
+addresses that are tied to that peer id over time.
+
+..
+ TODO how much info can be gained by that? all an observing peer sees is
+
+
+.. _Implications:
+
+Implications
+^^^^^^^^^^^^
+
+Here we spell out the implications for different parts of the framework. This
+should help get a grasp of the implications of the change.
+
+.. _DHT:
+
+DHT
+"""
+
+The DHT uses the peer id such that it determines which buckets a peer is
+responsible for. So each time the peer id changes, the peer becomes responsible
+for different data.
+
+
+.. _Scope-of-Peer-ID-for-higher-Layers:
+
+Scope of Peer ID for higher Layers
+""""""""""""""""""""""""""""""""""
+
+When peer ids stop to be unique over time, the framework is in lack of a
+globally unique identifier. Higher layers may rely (have reliede) on the
+uniqueness of the ids. This means gnunet has to use other means for this
+purpose. The Reconnects_ section below is concerned with the specific impact on
+reconnects for different higher-layer services.
+
+
+.. _Reconnects:
+
+Reconnects
+""""""""""
+
+When addresses (and with those the peer id) of a peer change, all core
+connections need to be torn down and with them all higher-layer connections.
+This affects the layers above CADET as follows:
+
+TODO lookup rst lists!
+
+ - Revocation: Is not really affected as it is only connected to direct CADET
+ neighbors and makes no use of CADET's routing, only of its flow and
+ congestion control.
+ - File sharing: Only the non-anonymous filesharing uses CADET connections.
+ This is not significantly affected by a reconnect as it only looks up peer
+ and port in the DHT, so in the meanwhile it's looking for other peers. TODO
+ this is very unclear to me!
+ - Messenging: This is not affected too badly - for a reconnection with this
+ service GNS lookups are required.
+ - Conversation: The call would be interrupted until the new peer id of the
+ other has been found via GNS.
+
+TODO: question: is gns needed for a reconnect? couldn't the peer with the new
+id simply 'call back' the other peer?
+
+..
+ - disconnects -> cadet
+ - revocation (directly connected neighbor, don't use routing, only
+ congestion/flow control)
+ - file sharing (non-anonymous): lookup peer and cadet port in dht
+ (continue looking for other peers meanwhile)
+ - messenging/messenger: not too bad, continue the lookup of the peer
+ (gns)
+ - conversation
+
+
+.. _Details-on-how:
+
+Details on how
+^^^^^^^^^^^^^^
+
+..
+ - adress bundle (transport communicators implement decision?)
+ - how adresses are generated:
+ - sort, hash, derive peer id from hash
+
+
+.. _Open-questions:
+
+Open questions
+^^^^^^^^^^^^^^
+
+
+.. _Core's-Ownership-of-Peer-IDs:
+
+Core's Ownership of Peer IDs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Implications
+^^^^^^^^^^^^
+
+.. _Transport:
+
+Transport
+"""""""""
+
+..
+ - transport creates and signs hello (w peer id)
+
+..
+ Notes from the meeting:
+ - higher-layer roll-over
+ - problem in practice 'phone call not interrupted by change of
+ location'
+ - solved by gns entries? and re-connect?
+ - cadet search for peer id - search in dht and via gns
+ - caching-problem for gns
+ - no signaling for roll-over
+ - estimated reconnect within 15 minutes
+ - change of address/peerid results in unclear state (down? lost
+ connection, ....?)
+ - cadet needs to regularily check gns entries
+ - how signal the change of addresses?
+ - do we signal trear-down?
+ - scenario address change in internet cafe?
+ - choice between privacy and connectivity
+ - sense of changing ids for cadet?
+ - -> rendez-vous peer (more stable)
+ - tracking via gns?
+ - only for people who are connected/known (tracking might be
+ ok for this)
+ - requires pir for gns
+ - tracking impossible/hard for others
+
+
+.. _Protocol_002dVersioning:
+
+Protocol-Versioning
+-------------------
+
+TODO
+
+.. _libp2p-Underlay:
+
+libp2p Underlay
+---------------
+
+TODO
+
+..
+ TODO Look at the project milestones to check coverage
